Re: [tsvwg] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt

Hi Dan,

Thanks for the comments.

On Tue, Oct 3, 2023 at 3:46 PM Dan Wing <[email protected]> wrote:
>
> On Sep 29, 2023, at 9:36 AM, Tom Herbert <[email protected]> wrote:
>
>
> On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie
> <[email protected]> wrote:
>
>
> OK, I see where you are coming from and it makes sense.  Hopefully that will become clear when the IANA Considerations section gets completed.
>
> Just out of curiosity, how would key distribution and updating work for the encryption?
>
>
> Herbie,
>
> That's a very good question, and probably one of the more interesting
> sub-problems of host networking that we'll have to solve! That is: How
> do we implement distributed security with potentially multiple nodes
> performing decryption of the data in the high performance datapath?
>
>
>
> Great document.  Thanks for gathering all the information in one place.

Thanks!

>
>
> The key distribution solution (or obfuscation distribution solution) will likely require softening the third bullet of https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig-00#section-6,
>
>    *  Host to network signaling MUST be be stateless within the network.
>       In particular intermediate nodes MUST NOT be required to create
>       and maintain state for transport layer connections.

I think that refers more to the data plane, not necessarily the control plane.


>
>
> To avoid that state the network element would have to dictate the keys (or the obfuscation) using some spiffy algorithm of its own design.  But another requirement nearly prohibits the network from dictating keys (or obfuscation), because the endpoint doesn't necessarily know when a different path is chosen by the network and getting two disparate networks to cooperate on keying (or obfuscation) seems hard.  It reads:
>
>    *  Host to network signaling MUST work in a multi-homed and multi-
>       path environments.  For instance, if two packets are sent for a
>       flow that are annotated with the same a host to network signal,
>       the signal can be properly processed even if there are no common
>       on-path nodes for the two packets.

Yes, but I would assume that different paths usually means different
paths in the same network. Like maybe a mobile device moving from one
base station of a provider to the next. If the device crosses into a
limited domain, then maybe it needs to get a new signal.

>
>
>
> Regarding TCP being the predominant transport protocol:  sure, but QUIC is giving TCP a run for its money, so to speak.  The popularity of TCP is not detrimental to UDP proposals which seek to differentiate certain UDP packets within the same flow.  TCP can't prioritize packets within the same flow because of in-order delivery.

Sure, I will replace 'the' with 'a' :-)

>
>
> The last bullet of https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig-00#section-5.3 says
>
>    *  The flow label is expected to be unchanged for the duration of a
>       flow so there is no means to change service parameters mid-flow or
>       per packet.
>
> which seems at conflict with IPv6's automatic flow labels you had previously brought to my attention (https://ripe82.ripe.net/presentations/20-azimov.ripe82.pdf).

The requirement stems from the fact that some stateful firewalls
expect consistent routing of all packets in a flow so we had to turn
off flow label modulation as the default. In a limited domain, it
would be okay to change flow labels mid-flow. In fact, there seems to
be a renewed interest in Random Packet Spraying, one of the goals of
Ultra Ethernet, and randomly setting the flow label on each packet of
a flow would be a pretty easy way to accomplish that if network nodes
use the flow label in ECMP-- of course, I wouldn't want to do that
when sending on the Internet :-)

Tom

>
> -d
>

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area