Ben Schwartz <bem...@google.com> wrote:
> On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson <mcr+i...@sandelman.ca>
> wrote:
>>
>> {some of my emails have written "ABSR" rather than "ASBR". Oops}
>>
>> Ben Schwartz <bem...@google.com> wrote:
>> > On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson <
>> mcr+i...@sandelman.ca>
>> > wrote:
>>
>> >>
>> >> Michael Richardson <mcr+i...@sandelman.ca> wrote:
>> >> > Based upon conversations on the list, this proposal might not even
>> >> be IPsec.
>> >> > At least, it's not proto=50(ESP)/51(AH), as they are asking for a
>> new
>> >> > extension header type.
>> >>
>>
>> > 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?
How will replay windows and key management work?
> 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.
>> 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 see why you conclude this.
>> IP-TFS would be the tunnel between the ABSRs.
>> There would be one IKEv2 handshake per-pair of ABSRs, I think.
>>
> Yes. That means O(N^2) handshakes between each pair of ASes with N ASBRs,
> vs. just 1 (between the ACSes) for RISAV.
It's a nice idea, but I don't see how it's gonna work.
>> I guess your diagram has these ACS devices which are going to do IKEv2,
>> but I
>> don't really see how that's going to work at higher line speeds. One
chews
>> through keys very fast, as other drafts in the WG are trying to deal
with.
>>
> 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?
>> For the gain that you don't cause users TCP connections to fail.
>>
> I think you might be hinting at the fact that TCP generally relies on MSS
> clamping, not PMTUD. For RISAV, one approach would be to apply MSS
> clamping at the ASBR before RISAV is added, based on a path MTU estimate
> for this SA.
No, TCP has been forced by NAT44 already screwing with headers and PPPoE to
do MSS clamping to get around lack of working PMTUD.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
