Hi Dan, Thanks for the comments.
On Tue, Oct 3, 2023 at 3:46 PM Dan Wing <danw...@gmail.com> wrote: > > On Sep 29, 2023, at 9:36 AM, Tom Herbert > <tom=40herbertland....@dmarc.ietf.org> wrote: > > > On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie > <Herbie.Robinson=40stratus....@dmarc.ietf.org> 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 Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
