Re: [IPv6] Fwd: New Version Notification for draft-xu-ipsecme-risav-00.txt

[Benjamin Schwartz <[e-mail]>]

On Fri, Mar 10, 2023 at 1:40 AM Mark Smith <[e-mail]> wrote:

> Hi Ben,
>
> On Fri, 10 Mar 2023 at 01:37, Benjamin Schwartz <[e-mail]> wrote:
> >
> > Hi 6MAN,
> >
> > I wanted to let you know about RISAV, our early-stage draft currently
> being discussed in IPSECME.  The draft essentially proposes a global
> configuration mechanism for network-to-network IPsec between ASes.  Each
> IPsec association is "edge-to-edge", independent of any intermediate ASes
> such as transit providers, and is authenticated to the RPKI.
> >
> > The proposal instructs certain intermediate nodes (the AS Border Routers
> of the source and destination ASes) to modify packets (adding and removing
> IPsec protection).  As explained in Section 10.1 [1], we believe that this
> is logically compliant with existing IPv6 standards, but we would
> appreciate more input from 6MAN on any problems that might arise from the
> proposed arrangement, or improvements we should consider.
> >
>
> "In-Flight IPv6 Extension Header Insertion Considered Harmful"
>

Thanks for the reference.  There's a clear parallel between RISAV (in
Transport Mode) and SRH.  However, I don't think most of the concerns
raised there apply to RISAV.

In RISAV, there is only one AS (the source) that can apply RISAV, and only
one that can remove it (the recipient).  It can only be applied once a
shared secret is negotiated between these ASes (via IKEv2), so leaks seem
less likely than in SRH.  Recipient ASes that get unexpected RISAV AH
headers are instructed to strip them out, so even in weird failure modes,
any leaks should not be detectable by the endpoint systems.

IETF 106 slide deck  -
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-in-flight-ipv6-extension-header-insertion-considered-harmful-00
> ID:
> https://datatracker.ietf.org/doc/html/draft-smith-6man-in-flight-eh-insertion-harmful-01
>
> I'm a bit intrigued to know how people are going to do cost effective
> and high speed EH chain processing past the fixed IPv6 header in
> literally every packet being forwarded, looking for EHs it is to
> process, when that network device doesn't hold the Destination Address
> of the packet.


> It seems to me that it would be a much easier thing to do if the
> network device that is to process EHs is only looking for packets with
> its own DA, which is what an outer tunnel header provides. Sure, the
> tunnel header is network overhead, however it allows the decision as
> to whether or not to try to process EHs in the packet as simple as
> whether or not the packet's DA is local to the device or not i.e. a
> FIB lookup.
>

In case it's not clear, the RISAV draft proposes _two_ modes: Transport
Mode (AH, header insertion) and Tunnel Mode (ESP, encapsulation).  It
sounds like you want Tunnel Mode.  Currently, we say that Transport Mode is
"mandatory to implement" and Tunnel Mode is optional, but we could
certainly reverse that or make them both optional.

As for the "CPU" efficiency of Transport Mode, I believe it's no worse than
Tunnel Mode:
- We can require that the RISAV AH header is the first header, so
everything is at fixed offsets.  (Thanks for pointing out the importance of
this!)
- For either mode, the sender and recipient ASBRs need to perform an IPsec
Security Association Database lookup on the source and destination IP
addresses of essentially every packet.  (This is similar to a RIB query for
IP->ASN mapping.)  In Tunnel Mode, this is required because the sender
needs to know which packets to encapsulate and into which tunnels, and the
receiver needs to reject (drop) any packets that should be in a tunnel but
are not.

In my view, the main question is: do the MTU savings of AH over ESP justify
the additional complexity?  Given the goal of deploying RISAV for all
traffic between many ASes, I think we may need to be very sensitive to MTU
loss and overhead.  (Otherwise I would prefer Tunnel Mode, for the sake of
confidentiality.)

In the limit of full deployment (aspirational!), we are talking about the
difference between a ~2% increase in global backbone traffic and a ~5%
increase.