On Tue, Mar 14, 2023 at 11:39 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > TL;DR> Important work needing New WG in Routing Area. > > Hi, I thought I had read previous versions of RISAV... maybe under a > different draft name. Yes, it was previously draft-xu-risav. (The replacement is marked in the Datatracker.) > I find this version much better than I saw before. > Thanks! We did try to incorporate your feedback. ... > The concerns that I have about this document is that the IPsec/AH parts of > it > are rather simple. The IPv6 header insertion and MTU parts of this > document > are, I think very controversial given the SR6 experience: SR6 was said to > be > always within an AS, and that any leaks would be a bug. But, the ENTIRE > point of RISAV is to communicate between ASs. > Yes, that's definitely a concern in Transport Mode. (See this thread in 6man: https://mailarchive.ietf.org/arch/msg/ipv6/78Frr7aQR0sT7yKKkFXucv2tL-8/). Note that Tunnel Mode does not have this problem. I also think that there is a lot of BGP-like TE that is missing from this > proposal. Although I run a BGP AS with multiple uplinks, I don't know all > the latest stuff about MED and how to deal with situations where two ISPs > connect in multiple places. > Section 6.2 incidentally describes how one might do quite a bit of traffic engineering using existing IKEv2 options. We'll need more input to know if it's sufficient. 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. The other concern that I have with RISAV is that it seems unreasonable that > an AS have only a single ACS. Maybe this can be accomplished via an > anycast > situation, Yes, personally I imagine implementing the ACS as an anycast service. > which to me implies some kind of MOBIKE-like situation where the > anycast IKEv2 respond answers with it's topologically useful IP. > Section 9.2 suggests using IKEv2 Redirect (RFC 5685). Please let us know if you see a better way. > I can imagine a situation where the ACS together, pick an appropriate pair > of > ASBRs to form a tunnel between them. > > Should a global ISP should be hairpinning traffic across the Pacific when > it > secures traffic between two AsiaPacific entities? > Obviously not, and RISAV intends to avoid that. While this could be dispatched to IPSECME, I don't think that is the right > choice. I think that we might need a new WG in the routing area with a > SecAD > owning it. > I like the idea of a new WG, especially since IPSECME seems quite busy. However, I do think the various multi-SA/multi-sender drafts in IPSECME (esp. [1][2]) should be in the same WG as RISAV, as it depends heavily on that capability. --Ben Schwartz [1] https://datatracker.ietf.org/doc/html/draft-mrossberg-ipsecme-multiple-sequence-counters-00 [2] https://datatracker.ietf.org/doc/html/draft-ponchon-ipsecme-anti-replay-subspaces-00
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
