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 12:28 PM Fernando Gont <[e-mail]> wrote:
>
> On 11/2/21 16:11, Tom Herbert wrote:
> > On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont <[e-mail]> wrote:
> >>
> >> On 11/2/21 15:18, Tom Herbert wrote:
> >> [...]
> >>>
> >>> 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.
> >>
> >> Then this is what an attacker would do:
> >> He/she would advertise on a HBH option something that looks sensible to
> >> the guy enforcing a network-based security policy, and then at transport
> >> would do what he/she needs to do. :-)
> >>
> >>
> >> e.g., HBH could advertise that my packets are directed to ports 80/443,
> >> while in transport they are actually directed to port, say, 22.
> >>
> > It's more likely that information in the HBH would be generic and
> > abstract, afterall the whole point of encrypting the transport header
> > is to hide information from the network that it doesn't require, not
> > to just blindly volunteer the same information somewhere else in the
> > packet. Port numbers, for instance, are not required for delivery and
> > in fact are prone to misinterpretation in the network (RFC7605)-- IMO
> > it makes no sense to put those in a HBH option.
> >
> > Regardless of HBH though, if the preponderence of transport headers
> > are encrytped then network security policiy that relies on the
> > information will need to change.
>
> The folks running networks might as well argue that if you want your
> protocol to be successfully deployed (or at all deployed), your protocol
> might need to change.
>
Perhaps, but in order to change the protocol to satisfy the
requirements of folks running networks, we'd need to know *what* the
requirements are. For instance, if someone were to say that networks
require more information than what is in the IP header to successfully
deliver packets, then I will immediately ask that they specify
*exactly* what information they need. Until/unless that is answered we
are left guessing as to what may or may not be acceptable in various
networks and the tussle continues.

> It's a tussle. ANd I see valid arguments on both sides.
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>