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

[Ben Schwartz <[e-mail]>]

On Sun, Oct 23, 2022 at 9:08 AM Michael Richardson <[e-mail]>
wrote:

>
> Ben Schwartz <[e-mail]> wrote:
>
....

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

They're in the outer IP header, unchanged, so it really is just 24 bytes.

...

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

I think we can set this aside until we've ironed out the technical wrinkles.

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

Looks like that's RFC 4555.  More homework...

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

Yeah, the draft mentions the replay problem in Section 4.2, but I had
forgotten about the nonce reuse problem.  Unfortunately, it looks like
changing the "associated data" for AEAD is not sufficient to isolate the
nonce.  A custom key derivation (hashing the secret together with the
source IP) seems like it would work though.

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

How big a deal is a new cipher mode? It doesn't sound so bad.


> You have, btw, just re-invented SKIP.  And maybe that's what you actually
> want, btw.
>

Oh, wow.  SKIP (https://datatracker.ietf.org/doc/draft-ietf-ipsec-skip/ for
those following along) looks like exactly the "proposed extensions"
mentioned in Section 5.2 and Section 5.3 of RISAV, so it's definitely
relevant.  Too bad it doesn't exist...

<snip>