Draft: draft-ietf-taps-transport-security

Commentary: Addresses and 
 = = DISCUSS = = I question the inclusion of CurveCP in the mix as per it does not seem to support IPv6 . At the bare minimum , the I - D should mention this restriction in section 3 . ( and I hope to be corrected about CurveCP IPv6 support ) . COMMENT : Please respond to the IoT - directorate review by Mohit : Please respond to the INT - DIR review by  : +    about GRE Generic comment about the intended transport : all protocols analyzed in this document are point to point ( no multicast ) , this should probably be mentioned in the introduction . -- Section 1 -- Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when " security protocol " is defined . -- Section 3 -- Use the wording of " record protocol " generically while the term " record protocol " is defined in section 2 as a blocked data transport ( like in TLS ) . Suggest the use of " data transfer protocol " ? An important property of such protocols is to be able to traverse a NAPT box ( that I hate ) ... I suggest to mention whether the analyzed protocols support NAT - traversal in this description section or even in the analysis parts as having a different view ( application and network layers seeing possibly different IP addresses so a potential impact on the API ) . 
 From Magnus :  and I have discussed this and the proposal is a clarifying change to the initial statement in Section 3 : OLD : This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network . NEW : This section contains brief transport and security descriptions of the various security protocols currently used to protect data being sent over a network . The purpose of this change to clarify that these descriptions are only concerning relevant aspects of transport and security . Are the WG and authors ok with the above change ? 
 From  : I think GRE ( the one I know more ) should be mentioned as existing somehow . ... even if the WG does n't want to add an analysis of GRE ! A suggested starting text blob proposal for GRE could be : Generic Routing Encapsulation [ RFC2784 ] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol . GRE tunnels do not by default provide security features . [ RFC2890 ] describes enhancements by which two fields , Key and Sequence Number , can be optionally carried in the GRE Header to implement security functions . [ RFC8086 ] specifies a method of encapsulating network protocol packets using GRE in UDP . GRE can be used in combination with IPsec ( see RFC2890 ) . 
 Just a note : We 're not addressing his comment on including NAT traversal as a feature , right ? I think a good explanation for this is that with TAPS we can do racing , e.g. , if a secure transport protocol does not work because of NAT , we might use the same protocol but tunneled over UDP . Thus the problem of NAT traversal can be orthogonal to what we describe in our draft . 
 Maybe change " of the various " to " of various " , since otherwise it can be read as suggesting these are all the security protocols used . 
 applied your suggested change ! 
 Yes , let 's just comment in our email response . 
 Major issues : The document header says that this document is about interfaces between security protocols and transport services . Yet , later on , I find that the document is also discussing the interfaces between security protocols and applications . Perhaps you could add ' applications ' to the title -'Interaction Between Applications , Security Protocols , and Transport Services ' Editorial issues : Instead of saying ' This protocol obsoletes TCP MD5 " signature " options ' , can we say ' TCP - AO obsoletes .... ' to avoid confusion of what is ' this ' Please expand ' and IPsec AH [ RFC4302 ] ' -IP Authentication Header Are you talking about cryptographic agility here ' security protocols : confidentiality , privacy protections , and agility . ' ? Consider changing ' interface surface exposed ' -interface exposed by ' . Otherwise it sounds too similar to attack surface exposed . Expand EAP and reference RFC3748 . - Perhaps you could say that Source Address Validation ( SAV ) to prevent DoS is relevant for protocols that use unreliable transport ? 
 Regarding the title change , I think we can not change this , as " Transport Services " is by definition the interaction between applications and transports ; we 're adding security to the mix . The first sentence of the abstract already mentions applications . 
 Should be covered by 
 Looks good so far , modulo one typo . I was wondering if we want to include " integrity protection " to our definition of Security Protocol , too , as  suggested . But that sentence says " such as " , so perhaps it 's fine if we do n't enumerate all possible features . Also ,  suggested we change our generic use of the term " record protocol " , as our definition in Section 2 clashes with it . Maybe we want to change the definition in Section 2 instead to match our use and remove the " Record " definition ? I do n't think we actually use " Record " as " Framed protocol messages " in the rest of the document , do we ? LGTM with a couple nits !
Mailing list commentary: Reviewer : Review result : Ready with Issues This document is a survey of network security protocols and their interaction with transport and application protocols . It is clearly written and easy to read . I have a minor comment on the contents of this draft . It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft . Some notable omissions include SSH , L2TP , and GRE . These seem like interesting omissions given their popularity in a number of deployment scenarios . Not a showstopper in my opinion , but interesting to note .
Reviewer : Mohit Sethi Review result : Ready with Nits This document provides a summary of common security protocols . It then discusses the interfaces that exist between applications and security protocols as well as security protocols and transport services . Major issues : The document header says that this document is about interfaces between security protocols and transport services . Yet , later on , I find that the document is also discussing the interfaces between security protocols and applications . Perhaps you could add ' applications ' to the title - > ' Interaction Between Applications , Security Protocols , and Transport Services ' Editorial issues : Instead of saying ' This protocol obsoletes TCP MD5 " signature " options ' , can we say ' TCP - AO obsoletes .... ' to avoid confusion of what is ' this ' - Please expand ' and IPsec AH [ RFC4302 ] ' - > IP Authentication Header - Are you talking about cryptographic agility here ' security protocols : confidentiality , privacy protections , and agility . ' ? - Consider changing ' interface surface exposed ' - > interface exposed by ' . Otherwise it sounds too similar to attack surface exposed . - Expand EAP and reference RFC3748 . - Perhaps you could say that Source Address Validation ( SAV ) to prevent DoS is relevant for protocols that use unreliable transport ?
Paragraph (version A):
usage.  In contrast, protocols such as ALTS ALTS are omitted since
they do not provide interfaces deemed unique.
Paragraph (version A):
Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH
RFC4302 are excluded from this survey.  TCP-AO adds authenticity
protections to long-lived TCP connections, e.g., replay protection
with per-packet Message Authentication Codes.  (This protocol
obsoletes TCP MD5 "signature" options specified in RFC2385.)  One
prime use case of TCP-AO is for protecting BGP connections.
Similarly, AH adds per-datagram authenticity and adds similar replay
protection.  Despite these improvements, neither protocol sees
general use and both lack critical properties important for emergent
transport security protocols: confidentiality, privacy protections,
and agility.  Such protocols are thus omitted from this survey.
Paragraph (version B):
usage.  In contrast, protocols such as SSH RFC4253, GRE RFC2890, L2TP
?RFC 5641, and ALTS ALTS are omitted since they do not provide
interfaces deemed unique.
Paragraph (version B):
Authentication-only protocols such as TCP-AO RFC5925 and IPsec
Authentication Header (AH) RFC4302 are excluded from this survey.
TCP-AO adds authentication to long-lived TCP connections, e.g.,
replay protection with per-packet Message Authentication Codes.
(TCP-AO obsoletes TCP MD5 "signature" options specified in RFC2385.)
One primary use case of TCP-AO is for protecting BGP connections.
Similarly, AH adds per-datagram authentication and integrity, along
with replay protection.  Despite these improvements, neither protocol
sees general use and both lack critical properties important for
emergent transport security protocols, such as confidentiality and
privacy protections.  Such protocols are thus omitted from this
survey.
Paragraph (version B):
This document only surveys point-to-point protocols; multicast
protocols are out of scope.
Paragraph (version A):
This section contains brief descriptions of the various security
protocols currently used to protect data being sent over a network.
These protocols are grouped based on where in the protocol stack they
are implemented, which influences which parts of a packet they
protect: Generic application payload, application payload for
specific application-layer protocols, both application payload and
transport headers, or entire IP packets.
Paragraph (version B):
This section contains brief transport and security descriptions of
the various security protocols currently used to protect data being
sent over a network.  These protocols are grouped based on where in
the protocol stack they are implemented, which influences which parts
of a packet they protect: Generic application payload, application
payload for specific application-layer protocols, both application
payload and transport headers, or entire IP packets.
Paragraph (version A):
This section describes the interface surface exposed by the security
protocols described above.  We partition these interfaces into pre-
connection (configuration), connection, and post-connection
interfaces, following conventions in I-D.ietf-taps-interface and I-
D.ietf-taps-arch.
Paragraph (version B):
This section describes the interface exposed by the security
protocols described above.  We partition these interfaces into pre-
connection (configuration), connection, and post-connection
interfaces, following conventions in I-D.ietf-taps-interface and I-
D.ietf-taps-arch.
Paragraph (version A):
Authentication Delegation (AD): The application provides access to
a separate module that will provide authentication, using EAP for
example.
Paragraph (version B):
Authentication Delegation (AD): The application provides access to
a separate module that will provide authentication, using
Extensible Authentication Protocol (EAP) RFC3748 for example.