On Sun, Oct 23, 2022 at 9:08 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
>
> Ben Schwartz <bem...@google.com> 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>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
