On Fri, Mar 24, 2023 at 3:11 AM gengnan <[email protected]> wrote:
> 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? > In a sense, yes. Tunnel Mode makes it easier for the endpoint ASes to limit how much information is revealed to the intermediate ASes. If you know of a particular kind of traffic engineering by intermediate ASes that the endpoint ASes might want to encourage, I'd be interested to hear about it. Perhaps we can find a way to support it. > 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. > Yes, the RISAVAnnouncement Signed Object is defined in Section 3. 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? > Interesting, I wasn't aware that Multiple-Origin AS ROAs were allowed in the RPKI. In this case, I believe AS Y should exclude P2 from RISAV. It can do this by choosing its IKEv2 Traffic Selector (TSi) to exclude this range, and narrowing any proposed IKEv2 TSr. (More aggressive configurations are possible if Z is actually forwarding P2 to Y, or if Z never originated packets from P2.) We can add a note to the draft about this. 3. How do ACSes communicate with ASBRs? > In my view, this is an "implementation detail" within a single AS, and is out of scope for the draft. Personally, I imagine the ACS being an anycast service implemented across all the ASBRs, using a distributed database. >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
