Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

[Ben Schwartz <[e-mail]>]

On Fri, Oct 21, 2022 at 3:43 PM Michael Richardson <[e-mail]>
wrote:

>
> Ben Schwartz <bemasc=[e-mail]> 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.

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:

* 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.

There are some interesting
> opportunities for privacy and defeating traffic analysis by adding an IP
> header.  The IPTFS work (now in the RFC-editors Q
> https://www.rfc-editor.org/current_queue.php#draft-ietf-ipsecme-iptfs )
> also offers some interesting opportunities.
>

Thanks for mentioning IPTFS.  I'll try to understand it...

    > This is an early stage proposal with a lot of open questions (many of
>     > which are noted in the draft), but the core idea is simple: use RPKI
> to
>     > bootstrap an authenticated IPsec association between the source and
>     > destination ASes of Internet traffic, so that inauthentic packets can
>     > be discarded before they reach their destination.
>
> But, what about: https://www.rfc-editor.org/rfc/rfc9255.html
> It seems like you are trying to use RPKI for something which the RPKI
> people
> don't want you do to.  (I mostly disagree, btw)
>

I actually think RISAV uses RPKI for exactly the thing that RFC 9255 wants:
directing IP packets to the corresponding AS number.

I see from the content in section 2.2 that you have an EE cert for the ACS.
> I'm a bit unclear about whether step 1 is already the RPKI, or some new
> process.
>

Yes, it's from the RPKI.

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.

Since AS A/B may
> interconnect in many places, on many continents, they need many tunnels.
>

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.

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.


> I think that this invokes the entire MED debate in BGP4, which I'm really
> out-to-date on, but AFAIK, isn't solved.  Maybe adding IKEv2 provides
> opportunities to make better policy decisions.
>
> There are shades of RFC4322 in these ideas, but not the same.
>

More homework...

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.  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.

}4.1.  Transport Mode
> }
> }   To avoid conflict with other uses of IPsec, RISAV defines its own
> }   variant of the IPsec Authentication Header (AH).  The RISAV-AH header
> }   format is shown in Figure 2.
>
> This is really dumb. Don't do this.
> There are only conflicts because you think you are insert the header.
> You can't and you shouldn't.  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".


> 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.


> }7.3.  MTU
> }
> }      TODO: Figure out what to say about MTU, PMTUD, etc.  Perhaps an
> }      MTU probe is required after setup?  Or on an ongoing basis?
>
> The answer is probably to do IPTFS, but that is in conflict with using AH.
>

OK, will review IPTFS.