Draft: draft-ietf-taps-arch

Commentary: This addresses two issues related to protocol stack equivalence : TCP and UDP can now be equivalent if the application does not care about message boundaries ( see mailing list discussion in July 2019 ) Security protocol and parameters need to be equivalent , not " features " which implied abstract security features . Basically , equivalent stacks are all stacks that satisfy whatever the application requested . If you want to race different security protocols ( like TLS 1.2 and 1.3 ) , your application has to specify that it considers these protocol equivalent . Question to authors : Should the SHOULD in 3 . become a MUST ? 
 Regarding the SHOULD , I 'd rather leave it as a SHOULD for now , to give some wiggle room to implementations . 
 Under " Protocol Stack Equivalence " , for example , text like needs to change to conform to the rework of the security document . This is related to . 
 Yes , I think this is part of the " protocol stack equivalence " issue . As is assigned to me , I 'll just self - assign this one and close both once this is done . 
 Fixed by 
 Per the architecture draft , only protocol stacks that are equivalent can be safely raced . What is the expected behavior if selection properties are set in such a way that the resulting candidate set includes protocol stacks that are not equivalent ? Would the selection properties simply be treated as invalid ? 
 To me " equivalent " relates to either candidate would provide the set of functions needed . At the risk I do n't answer your question : My take is that one can always define policy and API properties that produce a useless outcome . It 's not the job of a TAPS system to validate these ( although someone may like to try that as a separate sanity checking tool ) ; in just the same way that someone can write code that does n't implement an algorithm . The goal is rather that if this specifies " sensible " properties and policy you get the required outcome . You may get no connection or something unexpected if the request is not well - founded . 
 Right , so if an application chooses to provide properties that allow both TCP and UDP the implementation would race those two which would result in a default win for UDP , is that correct ? 
 I agree , and I 'd say the answer to your question is yes . Of course , later you may find that UDP does n't really work on the path for the given port , and then it would be great to have an open TCP connection available to fall back to . 
 I guess we should define " equivalent protocol stacks " a little less rigorous in the architecture document . For an application that does not care about message boundaries , and reliable transport and has its own congestion control , protocol stacks with TCP and UDP may indeed be equivalent with respect to the application 's requirements . This would require to rewrite 1 . of the enumeration in Section 4.2.3 which could use a second look anyway , because it mixes up application requirements in sense of interface behaviour and application protocols that directly depend on specific transport protocols beneath , which is what PR is all about . 
 See also mailing list discussion in July 2019 . 
 We also need to say here what " equivalence " means for security . Right now , Security Considerations says " As described above in Section 4.2.3 , if a Transport Services system races between two different   , both MUST use the same security protocols and options . " I think if we consider equivalence as " you can use whatever stack that satisfies the things that the application requested " , this should also apply to security . Now that the application has to explicitly select a security protocol , I think it should also be allowed for the application to say that multiple security protocols are fine . Like , allow applications to say " Use TLS 1.3 if available , but if not , TLS 1.2 is also fine " ( instead of failing ) . 
 Fixed by 
 Nice !
Paragraph (version A):
Both stacks MUST offer the same interface to the application for
connection establishment and data transmission.  For example, if
one Protocol Stack has UDP as the top-level interface to the
application, then it is not equivalent to a Protocol Stack that
runs TCP as the top-level interface.  Among other differences, the
UDP stack would allow an application to read out message
boundaries based on datagrams sent from the remote system, whereas
TCP does not preserve message boundaries on its own.
Paragraph (version B):
Both stacks MUST offer the interface requested by the application
for connection establishment and data transmission.  For example,
if an application requires preservation of message boundaries, a
Protocol Stack that runs UDP as the top-level interface to the
application is not equivalent to a Protocol Stack that runs TCP as
the top-level interface.  A UDP stack would allow an application
to read out message boundaries based on datagrams sent from the
remote system, whereas TCP does not preserve message boundaries on
its own, but needs a framing protocol on top to determine message
boundaries.
Paragraph (version A):
Both stacks MUST offer the same security properties.  The
inclusion of transport security protocols I-D.ietf-taps-transport-
security in a Protocol Stack adds additional restrictions to
Protocol Stack equivalence.  Security features and properties,
such as cryptographic algorithms, peer authentication, and
identity privacy vary across security protocols, and across
versions of security protocols.  Protocol equivalence ought not to
be assumed for different protocols or protocol versions, even if
they offer similar application configuration options.  To ensure
that security protocols are not incorrectly swapped, Transport
Services systems SHOULD only automatically generate equivalent
Protocol Stacks when the transport security protocols within the
stacks are identical.  Specifically, a transport system would
consider protocols identical only if they are of the same type and
version.  For example, the same version of TLS running over two
different transport protocol stacks are considered equivalent,
whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent.
Paragraph (version B):
Both stacks MUST offer security protocols and parameters as
requested by the application I-D.ietf-taps-transport-security.
Security features and properties, such as cryptographic
algorithms, peer authentication, and identity privacy vary across
security protocols, and across versions of security protocols.
Protocol equivalence ought not to be assumed for different
protocols or protocol versions, even if they offer similar
application configuration options.  To ensure that security
protocols are not incorrectly swapped, Transport Services systems
SHOULD only automatically generate equivalent Protocol Stacks when
the transport security protocols within the stacks are identical.
Specifically, a transport system would consider protocols
identical only if they are of the same type and version.  For
example, the same version of TLS running over two different
transport protocol stacks are considered equivalent, whereas TLS
Transport Services systems MAY allow applications to indicate that
they consider two different transport protocols equivalent, e.g.,
to allow fallback to TLS 1.2 if TLS 1.3 is not available.