I suppose you could try to add a "we're exempt from 8200" paragraph and see what happens.
You could also just say that ASBRs are presumed to be communicating within a well-managed environment, are often zero or one hops away from one another, and that this environment MUST accommodate the larger MTU for tunnel-mode IPsec encapsulation. On Thu, Oct 20, 2022 at 7:47 AM Ben Schwartz <bem...@google.com> wrote: > The RISAV-AH header is inserted as the packet exits the source AS, and > removed as the packet enters the destination AS. Thus, it has the same net > effect as an ESP tunnel, and IMHO should not be viewed as a violation of > RFC 8200. > > Where this gets interesting is ICMP responses from intermediary routers > (e.g. traceroute, PMTUD). I'm not sure what to do about this, but I guess > it's probably not worse than what would happen with an ESP tunnel... > > On Thu, Oct 20, 2022 at 10:41 AM Erik Kline <ek.i...@gmail.com> wrote: > >> I don't understand how "transport mode" can work for non-originated >> packets; for IPv6, inserting random headers along the path would violate >> 8200. >> >> On Thu, Oct 20, 2022 at 7:23 AM Ben Schwartz <bemasc= >> 40google....@dmarc.ietf.org> wrote: >> >>> Hello IPSEC, >>> >>> We've just put out an extensively revised version of our RISAV proposal >>> (the I stands for IPsec). We'd like to start getting feedback from the >>> IPsec experts. We're also hoping to present this idea and solicit feedback >>> at IETF 115. >>> >>> This is an early stage proposal with a lot of open questions (many of >>> which are noted in the draft), but the core idea is simple: use RPKI to >>> bootstrap an authenticated IPsec association between the source and >>> destination ASes of Internet traffic, so that inauthentic packets can be >>> discarded before they reach their destination. >>> >>> --Ben Schwartz >>> >>> ---------- Forwarded message --------- >>> >>> A new version of I-D, draft-xu-risav-02.txt >>> has been successfully submitted by Benjamin Schwartz and posted to the >>> IETF repository. >>> >>> Name: draft-xu-risav >>> Revision: 02 >>> Title: An RPKI and IPsec-based AS-to-AS Approach for Source >>> Address Validation >>> Document date: 2022-10-20 >>> Group: Individual Submission >>> Pages: 17 >>> URL: https://www.ietf.org/archive/id/draft-xu-risav-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-xu-risav/ >>> Html: https://www.ietf.org/archive/id/draft-xu-risav-02.html >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-xu-risav >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-xu-risav-02 >>> >>> Abstract: >>> This document presents RISAV, a protocol for establishing and using >>> IPsec security between Autonomous Systems (ASes) using the RPKI >>> identity system. In this protocol, the originating AS adds >>> authenticating information to each outgoing packet at its Border >>> Routers (ASBRs), and the receiving AS verifies and strips this >>> information at its ASBRs. Packets that fail validation are dropped >>> by the ASBR. RISAV achieves Source Address Validation among all >>> participating ASes. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
