On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson <[email protected]> wrote:
>
> {some of my emails have written "ABSR" rather than "ASBR". Oops}
>
> Ben Schwartz <[email protected]> wrote:
> > On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson <
> [email protected]>
> > wrote:
>
> >>
> >> Michael Richardson <[email protected]> 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.)
Since transport mode will not fit into 1500 bytes, and will violate RFC8200,
> why even bother? :-)
>
> >> Even if you have the slimest possible pseudo-AH header, it will
> take at
> >> least
> >> a dozen bytes for the authentication data, which means at least
> 1520 byte
> >> packets or so. None of them support >1500.
> >>
>
> > That's fine. We don't need 1500+24 bytes. We just need 1280+24
> bytes, (or
> > 1280+73 in tunnel mode), so that the end-to-end MTU is
> IPv6-compliant.
>
> Yes, but what if someone sends a 1500 byte packet?
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.
> 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.
> I think I roughly understand the IP-TFS idea. I think that IP-TFS
> would be
> > preferable if it is easy to deploy, but I worry that it's not
> practical,
> > for two reasons:
>
> > 1. Scalability and efficiency. Compared to RISAV, IP-TFS would
> require
>
> > * a much larger number of IKEv2 handshakes (one for each pair of
> > communicating routers, vs. 1 for the whole AS pair)
>
> 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.
> 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.
This is more interesting in RISAV tunnel mode, which might have some
strange interactions with Extended Sequence Numbers. I do wish we had an
ESP with 8-byte sequence numbers...
> * a larger amount of connection state (to hold all the different SAs)
> > * a much larger amount of IP buffer memory (for fragment reassembly)
>
> How many fragments you have to reassembly is somewhat configurable.
>
> > * a somewhat larger amount of MTU overhead
>
> 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.
> 2. Routing interference and configuration
>
> > RISAV-AH doesn't alter packet routing at all. The source and dest
> IPs are
> > unchanged, so packets flow along exactly the same paths as they would
> > without RISAV.
>
> Yes, it does that by violating RFC8200.
> Please ask for 6man time for this.
>
It looks like 6man has a full agenda already (
https://datatracker.ietf.org/meeting/115/materials/agenda-115-6man-03.html)
but perhaps we can ask the 6man list for advice.
...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
