On Tue, Nov 1, 2022 at 5:53 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Ben Schwartz <bem...@google.com> wrote: > > On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson < > mcr+i...@sandelman.ca> > > wrote: > ... > >> > Nit: RISAV in tunnel mode uses proto=50. Only transport mode > >> requests a > >> > new protocol number. > >> > >> And you'll add an outer IP header from ASBR to ASBR? > >> > > > Not quite. The outer IP header is from ASBR to "contact IP". > (There is > > only one "contact IP" per AS.) > > So you propose to synchronize the SPI space across the entire AS? > Yes, SAs are negotiated between the control servers. Each control server then "broadcasts" the SA (including SPI) to all ASBRs in that AS. > How will replay windows and key management work? > Base keys are negotiated by IKEv2 as usual. Each sending ASBR has its own sequence number space, so I think we will need a key derivation like "ASBR key = HKDF(base key, source IP)", negotiated by a new IKEv2 option. If a receiving ASBR gets a packet from a new source IP, it derives the ASBR key, processes the packet, and opens a new replay context (if the ICV is valid). This arrangement has the nice property that when a recipient runs out of memory or loses state (e.g. due to a reboot), it can gracefully degrade to a behavior where packets are validated and flowing but replay protection is lost. Also, if an ASBR runs out of sequence numbers, it can keep running with a new source IP (essentially rolling over the high bits of the sequence number into the low bits of the IPv6 source address). > Here's one possibility: > > > 1. The ASBR generates a 1524 byte packet. > > 2. It sends it (assuming the link MTU is big enough...) > > 3. Later, it receives a PTB reply. > > 4. It lowers its MTU estimate for this SA. > > 5. In transport mode, it strips the RISAV header off the ICMP echo > payload > > and forwards the PTB to the original sender. > > Yeah, so this basically doesn't work reliably in the remote access space, > even after > 25 years of doing IPsec. ISPs that do this will lose customers. > It sounds like you're saying that 1500 is the actual minimum required link MTU, not 1280. Perhaps you could write an RFC... >> If you think we need 1500 bytes of end-to-end MTU, I would be > >> interested to > >> > hear why. > >> > >> Because every single network/service/etc. that doesn't support that > gets > >> into horrible MTU trouble. > >> I wish that wasn't true. I've pushed hard for PLPMTU to be turned > on by > >> default, but it's not happening. > >> > > > In 2014, a study from the QUIC team at Google found that 64% of > Chrome > > users had a path MTU to Google of <1500 bytes ( > > https://dl.acm.org/doi/pdf/10.1145/3098822.3098842, Figure 12). It > sure > > seems like anything that assumes a 1500 byte MTU is already going to > be > > broken frequently. > > Yeah, yet, PMTU is still filtered by major banks and enterprises, and it's > still a disaster. Could google turn on PLPLMTU? > I don't know much about that. My impression is that for TCP, this is generally handled by MSS clamping (whether the IETF likes it or not), and QUIC uses a very simple form of DPLPMTUD. ... > > RISAV-AH doesn't have sequence numbers or replay protection, so you > just > > repeat the handshake when you feel like it. > > So, again, are you doing IPsec or not? > IKEv2 can currently negotiate several protocols: - AH - ESP - IPsec over UDP (RFC 3948) - IPsec over TCP (RFC 8229) RISAV-AH would be another option. RISAV in tunnel mode proposes to use the standard ESP format, but with a slightly modified key schedule. I don't particularly care whether we say these things are "IPsec" or "IPsec-based" or "an IPsec variant" or "inspired by IPsec".
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec