Ben Schwartz <bem...@google.com> wrote:
>> Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote: > We've just
>> put out an extensively revised version of our RISAV proposal > (the I
>> stands for IPsec). We'd like to start getting feedback from the >
>> IPsec experts. We're also hoping to present this idea and solicit >
>> feedback at IETF 115.
>>
>> Thanks. The question of what kind of tunnel or transport is a deep
>> one, and whether or not to encapsulate the traffic within an IP header
>> has significant architecture discussion. Despite the experience of
>> SR6 pushing through, I'm not convinced that 6man will buy your use
>> case.
> I'm aware that AH is not well-loved. Certainly ESP (which is also
> allowed) is easier to understand.
Well, AH's use case was never VPNs, and the other uses of AH just did not
occur, and then NAT44 took over and made them all impossible.
So, it's not that people hate AH, it's that, as you say, it hasn't received
the love that it deservers.
We also mis-specified it. We said that if the SPI# is not one you recognize,
that the packet should be dropped, which is entirely wrong if the packet is
multicast, and if something has lost state. We should have said that if the
SPI# was not recognized, that it was as if the AH header wasn't even present,
just skip it.
It's because of this that we couldn't use AH for SEND.
So, SEND has other things that kept it from happening, and in the end, we
could have actually fixed the AH specification and it's been 15 years and the
changes could have fully deployed now.
> The real motivation to support AH in this draft comes down to MTU
> overhead. Going from 24 bytes of MTU loss to 73 bytes seems
> potentially significant, especially because:
Where will you put the original src/dst IPs?
24 bytes is the AH overhead only. The v6 src/dst requires 32 bytes,
at which point you might as well just have an IPIP header at 44 bytes.
> * The traffic volumes involved are potentially very large (ideally a
> majority of "backbone" traffic) * We don't have a way to measure MTU,
> leading to the risk that the inner MTU could be <1280 (if the transit
> link has very small MTU, which I believe is rare). The larger the MTU
> loss, the more of a concern this is.
PLPMTU is a really good thing, if only someone would turn it on by default.
That would allow MTUs to rise significantly, but nobody listens to me.
> Thanks for mentioning IPTFS. I'll try to understand it...
it slices, it dices, it obfuscates.
> I actually think RISAV uses RPKI for exactly the thing that RFC 9255
> wants: directing IP packets to the corresponding AS number.
I'm not convinced it will fly.
I agree with you, but I feel like I'm in the rough.
>> It seems that one would want many ACS systems. If successful, all of
>> the
>> traffic between AS A and B would go through, and that could easily
>> exceed the bandwidth of a single system (or a single cluster).
> Yes, I believe the ACS can probably be implemented as a global anycast,
> so long as route flapping doesn't make IKEv2 impossible.
Yes, it would, but I'd implement it as IKEv2 init to anycast, followed by
immediate mobileIKE to the non-anycast address of the ACS.
> Maybe not. A single shared secret between the two networks, known to
> all their border routers, ought to be enough to encrypt and decrypt
> each packet, and the packets can be routed however they are routed.
No, that does't work because of replay, and because of AEAD and GCM modes
where replay == loss of key.
> The draft notes some interesting questions about how sequence numbers
> work in this situation. The best solution I came up with was to put
> the source IP into the "Additional Data" of the AEAD (or equivalent),
> but this seems like it would need a new IKEv2 extension.
yes, that's an entirely new cipher mode.
You have, btw, just re-invented SKIP. And maybe that's what you actually
want, btw.
>> Also, if universally successful, does this suddenly change how the DFZ
>> looks? Does it have to carry all of the routes to all of the places,
>> or only the routes to the ACS/ASBR? Can you drop all IPv4 and just
>> encapsulate to IPv6? Is there a win in simplifying silicon here?
>>
> If RISAV in tunnel mode were adopted universally, it would definitely
> simplify routing. That seems like a pretty silly hypothetical though
Always plan for success.
> The whole point of RISAV is that it's highly incrementally deployable.
> Even if just two random ASes in the whole world turn it on, it should
> work for them without any help from anyone else.
Yes, if every single deployment has a direct ROI, the that supports the fax
effect and more incremental deployment.
Further, if I can do Traffic Engineering of my links by directing floes by AS
to specific ACS which have specific tunnels, then we wind up with a kind of
inter-AS MPLS/SR6/ATM solution.
That would also be a major win for many.
>> You really should create a tunnel with AH.
>>
> Wait, what's a tunnel with AH? I've heard of "ESP without encryption",
> but I've never heard of "AH but it's a tunnel".
tunnel: IP AH IP ULP.
vs
transport: IP AH ULP
>> AH has the advantage that everyone knows it's AH, so skipping the
>> outer header and the AH means you can find the inner IP and do
>> auditing or flow analysis on it. Since you have to modify hardware to
>> do something, you might as well do this.
>>
> I don't know what you're advising, but my main question is about the
> MTU overhead.
With ESP, you can't know what's inside the ESP.
Even if it's ESP-NULL, nobody can count on that, so processing has to stop
with the ESP.
By fluke, back in the early 1990s, cisco routers uses the 5-tuple as part of
a cache to speed up forwarding. This turned into netflow (aka openflow), and
operator/ISPs since them have rejected any forwarding engine that can not
produce the same kind of statistics. They really want to know how much
traffic is port-80 vs port-25... Of course QUIC screws that all up.
Many routing fabrics have internal mirror "ports" that actually do the 5-tuple
accounting that is desired. Those devices can be told to skip the AH header
to find the ULP in order to do the accounting.
--
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
