Hi Ben, In Tunnel Mode, if the source and destination addresses are replaced by contact IPs, there will be one (or several) huge aggregated “flow” between the two ASes. Does this pose a challenge to intermediate ASes that conduct Traffic Engineering?
Here are some other questions/comments after I having a look at the draft: 1. Contact IPs need to be registered in RPKI. Do new signed objects need to be defined? If so, feedback can be requested in the sidrops WG on new profile and new RTR PDU, etc. 2. Consider a scenario of MOAS: AS X with prefix P1 and AS Y with prefix P2 enable risav, and AS Z does not support risav. Prefix P2 are announced by both AS Y and AS Z (which is also authorized by ROA). If AS X sends packets to P2, how do the ASBRs of AS X do on the outgoing packets? The outgoing packets may go to AS Z instead of AS Y. On the basis of the above scenario, how does AS X validate incoming packets (src=P2, dst=P1) when AS Z also enables risav? 3. How do ACSes communicate with ASBRs? Best, Nan From: IPsec <[email protected]> On Behalf Of Benjamin Schwartz Sent: Thursday, March 23, 2023 5:19 AM To: Michael Richardson <[email protected]> Cc: secdispatch <[email protected]>; [email protected] Subject: Re: [IPsec] RISAV proposal at SECDISPATCH On Wed, Mar 15, 2023 at 11:09 AM Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: Benjamin Schwartz <[email protected]<mailto:[email protected]>> wrote: >> Benjamin Schwartz <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
