{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?
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?
> 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.
> 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.
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.
> * 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.
> 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.
> RISAV in tunnel mode changes the destination IP to one IP for the whole
> receiving AS, but that IP can be anycast across all ASBRs, so routing
> should be similar to non-RISAV routing, and configuration is
> straightforward.
> IP-TFS requires each sending ASBR to pick a specific receiving ASBR. This
> creates a form of "source routing" that bypasses much of the usual BGP
> pathfinding.
I don't see how anything else is going to work, unless you create something
that isn't IPsec. I encourage you to do that.
> Recreating the baseline routing paths could be difficult or
> impossible, and might require O(N^2) active tunnels, for a pair of ASes
> with N ASBRs each. The simple RISAVAnnouncement that goes in the RPKI
> database would have to be replaced by a much larger configuration object
> that enumerates all the ASBRs and explains who should use which one.
> You mentioned earlier that this form of "source routing" might be
desirable
> in some use cases. That's an intriguing idea, but I would like for ASes
to
> be able to activate RISAV with a minimum of additional complexity,
> maintenance, and risk.
Geoff Houston has a presentation about this.
--
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
