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. 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. 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. 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. 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). -d
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
