On Sun, Oct 23, 2022 at 9:50 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Ben Schwartz <bem...@google.com> 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. > > No, that's not legal or practical. > I'm not too worried about the "legalities". We write the rules! Even assuming that you can insert an AH header (which I think you can > legally > do in IPv4, but not in IPv6), then you have to use a SPI# allocated by > destination ASBR, so you have to put the dstip= ASBR. > No, the SPI# is allocated by AS pair, so the SPI scope is unambiguous (to the recipient) from the source IP. (There is no sequence number or replay defense.) Really, you need to change the srcip= as well, because otherwise, ICMPs go > to > the wrong place. > ICMPs go to the source IP, which is what we want. The only trick is that you need to apply RFC 5508-style transparent ICMP rewriting, to strip out the echoed RISAV-AH header. (Conveniently, this operation is entirely stateless.) If you want do something else, then it's relly not IPsec. > It's IPsec, but not as we know it. It's a "transparent variant of IPsec transport mode", or something like that. ... > >> 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. > > It's not that big deal, but I assume you'd like to use commodity off the > shelf hardware. > I'm pretty sure this doesn't actually affect that. I think we would do something like "ESP Key = HKDF(IKEv2 DH key, source IP)", and then ESP mode would run pretty much as usual. My main question was how to negotiate this in the IKEv2 handshake. In terms of performance, my bigger concern is that sending and receiving a RISAV packet requires an IP->ASN mapping lookup. Hopefully ASBRs are good at that... ...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
