Re: [saag] [tsvwg] 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

[Sebastian Moeller <[e-mail]>]

Hi Tom,

More below inline, prefixed with [SM].


On 11 February 2021 20:43:19 CET, Tom Herbert <[e-mail]> wrote:
>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.

[SM] While I only run my own home network, and hence only marginally qualify network operator at best, I do use per-flow queueing, currently based on a 5-tupel, ot dst/src IP addresses, protocol, and dst/src port. That works amazingly well, so if possible I would like to be able to keep getting access to a stable representation of the port numbers, but I do not care whether these stable representations are veridical or hashed, and I don't care about an occasional hash collision.
Since I am vaguely familiar with game theory, I would very much like to be able to access the same field as used by the protocol itself (as anything that can be gamed for an undeserved advantage, will be gamed). That is something like IPv6's flowlabel is less ideal than the real port numbers.

Best Regards
        Sebadtian


 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
>>
>>
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.