Responses in-line with [NAN] 发件人: Benjamin Schwartz <i...@bemasc.net> 发送时间: 2023年3月24日 17:23 收件人: gengnan <geng...@huawei.com> 抄送: Michael Richardson <mcr+i...@sandelman.ca>; secdispatch <secdispa...@ietf.org>; ipsec@ietf.org 主题: Re: [IPsec] RISAV proposal at SECDISPATCH
On Fri, Mar 24, 2023 at 3:11 AM gengnan <geng...@huawei.com<mailto:geng...@huawei.com>> 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. [NAN]: Suppose AS X and AS Y are risav-enabled and use the tunnel mode. There are two AS paths: AS X-AS 1-AS 2-AS Y and AS X-AS 1-AS 3-AS Y, where AS 1, AS 2, and AS 3 are intermediate ASes. In the scenario, it is not much effective for AS 1 to balance the traffic from AS X and AS Y based on source/destination IP blocks, because the packets in the traffic possibly have the same source and dest IP addresses. This may be one of the effects on the TE task of intermediate ASes. 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. [NAN]: IMO, the requirements for the ACS-to-router communication can be described, which could be helpful for the people who really plan to deploy risav.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
