On Tue, Nov 1, 2022 at 5:53 AM Michael Richardson
wrote:
>
> Ben Schwartz 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
