Re: [tsvwg] [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

[Tom Herbert <[e-mail]>]

On Thu, Feb 11, 2021 at 10:58 AM Fernando Gont <[e-mail]> wrote:
>
> On 11/2/21 06:50, Gorry Fairhurst wrote:
> [....]
> >>
> >> Some very specific comments on some parts:
> >>
> >> * Section 5.1:
> >>
> >>      For example, an
> >>      endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide
> >>      explicit transport layer information that can be observed and
> >> used by
> >>      network devices on the path.
> >>
> >> This is not as easy as it sounds. If you convey this information in
> >> multiple places (e.g. the transport protocol itself (that you cannot
> >> see), and e.g. IPv6 options, then the two might not much -- and devices
> >> could e.g. enforce a security policy on contents (e.g., the info in the
> >> IPv6 options), that the destination endpoint might possibly e.g. ignore.
> >
> > This sounds similar to the case of explicitly exposing other
> > information.
>
> Yes. ANything where you have two copies of the same information, and
> different parties are likely to act on different copies, is prone to the
> same thing.
>
Fernando,

When the transport layer is encrypted, network devices would only see
the plaintext EH and that is only what that is what they can act on.
At the destination, we could try to rectify transport information in
HBH with decrypted plaintext transport headers, but I suspect that
wouldn't typically be done. The HBH information is only operationally
useful to the network, not the transport endpoints that have access to
the transport header. The only point of the end host comparing the
data would be to enforce the network's security policy, but it's not
common that end hosts actually know what the network security policies
are.

Tom

> (I guess, unless you can enforce that the two match, and have a strong
> requirement that all parties check that, and otherwise drop the packet
> -- something that in practice, many don't)
>
>
>
> > In this case, the network will make decisions on what it
> > sees or infers - without knowledge of the contents of the encrypted part
> > Would you like to propose some text to help explain this?
>
> I'd be happy to. I'll craft text and come back to you on this one.
>
>
>
>
> >> * Section 5.1:
> >>
> >>      Protocol methods can be designed to
> >>      probe to discover whether the specific option(s) can be used along
> >>      the current path, enabling use on arbitrary paths.
> >>
> >> This might be a problem of "English as a second language", but the above
> >> text sounds to me like you can enable use of this feature on arbitrary
> >> paths.... where's I'd probably argue that what you can do is to
> >> *disable* the feature on paths where the feature cannot be used, such
> >> that you may still communicate (albeit without using the aforementioned
> >> feature).
> >>
> >> Another simpler fix might be s/arbitrary/specific/
> >
> > The whole para currently reads:
> >
> >     An arbitrary path can include one or more network devices that drop
> >     packets that include a specific header or option used for this
> >     purpose (see [RFC7872]).  This could impact the proper functioning of
> >     the protocols using the path.  Protocol methods can be designed to
> >     probe to discover whether the specific option(s) can be used along
> >     the current path, enabling use on arbitrary paths.
> >
> > I think this last sentence can indeed be improved, and I suggest
> > something like:
> >
> >     Protocol methods can be designed to
> >     probe to discover whether the specific option(s) can be used along
> >     the current path, enabling or disabling their use on the path.
> >
> > Is that better?
>
> That's perfect, and indeed addressed my comment.
>
> Thanks!
>
> Regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>