On Wed, Mar 15, 2023 at 11:09 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Benjamin Schwartz <i...@bemasc.net> wrote: > >> Benjamin Schwartz <i...@bemasc.net> wrote: > In Transport Mode, the > >> thought is mainly to _avoid_ traffic > engineering, and instead be > >> able to deploy RISAV with confidence that > your existing TE will > not > >> be altered. > >> > >> I thought you replaced the destination address with that of the > ASBR? > >> > > > In Tunnel Mode (ESP), the source and destination addresses are > > replaced. (By default, they are "contact IPs", i.e. ACS addresses, > but > > ASBR addresses can be substituted using IKEv2 Active Session > Redirect.) > > In Transport Mode (AH), they are unmodified. > > > My understanding is that this is how ESP and AH are conventionally > > used. > > Yes/no. > > If the destination address of the packet is still the real destination, and > not the ASBR, then the packet isn't for the ASBR, and won't get processed > by > it. > I believe site-to-site IPsec tunnels almost always involve processing packets whose destination IP says they're for someone other than the IPsec terminator machine. What's new here is only which direction that promiscuity operates. So, either your transport mode has to change the destination address on the > packet, and recover/store the real one somewhere (much like SR6 does), or, > it's really some kind of L2 function going on here, and not really IPsec at > all. > Even in tunnel mode, the _outbound_ ASBR is still processing (i.e. encapsulating) packets whose destination IP is not the ASBR's. RISAV is a new spin on these ideas, but I don't think this part is as novel as you're implying.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
