On Wed, 29 Mar 2023 at 19:58, Tony Przygienda <tonysi...@gmail.com> wrote: > > Though I would like to cheer for Kireeti's 2. as well I think the point of > SHOULD is more realistic (for now) as Joel points out ... > > As to ethertype, I think grown-ups in the room were since long time drily > observing that a new IP version would have been appropriate after enough > contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4 > were performed with drafts whose authors' list length sometimes rivaled > pages of content ;-) I think this ship has sailed and that's why after some > discussions with Andrew we went the ether type route as more realistic. > Additionally, yes, lots encaps (not encodings) carrying SRv6 should get new > codepoints if we are really serious about trusted domains here. >
I'm for this idea in general, the fail open of SRv6 and in particular EH insertion for SRv6 scares me as an operator if I were to receive unremoved SRHs over the Internet. One perspective on what the IP layer is doing is that it is an abstract layer 2 that abstracts away the different layer 2 addressing and frame formats. See "2.1.3.1. Internet Protocol" of RFC6272 which discusses this perspective. If a different ethertype is allocated for "SR over IPv6" then I'm wondering if the IPv6 abstraction layer could be removed, avoiding the IPv6 40 octet header overhead. Could the SRH be carried directly after the Ethernet header, similar to how MPLS labels are? In other words, could this different ethertype proposal really be to allocate an ethertype specifically the SRH, rather than to a variant of IPv6 that is only ever carrying an SRH? Regards, Mark. > And folks who went the MPLS curve know that none of this is new, same curve > was walked roughly (though smoother, no'one was tempted to "hide label stack > in extension headers" ;-) and it would go a long way if deploying secure SRv6 > becomes as simple as *not* switching on "address family srv6" on an interface > until needed and then relying on BGP-LU (oops ;-) to build according lookup > FIBs for SRv6 instead of going in direction of routers becoming massive > wildcard matching and routing header processing firewalls ... > > --- tony > > > > On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella <kireeti.i...@gmail.com> > wrote: >> >> On Mar 28, 2023, at 11:24, Adrian Farrel <adr...@olddog.co.uk> wrote: >> >> [Spring cc’ed because, well, you know, SR. I wonder whether 6man and 6ops >> should care as well.] >> >> >> SPRING cc’ed because, you know, replying to Adrian’s email. Agree that 6man >> and 6ops [sh|w]ould be interested. >> >> tl;dr >> >> I think this is a good initiative and worth discussion. Thanks >> >> for the draft. >> >> >> Agree. In particular: >> 1. There is an acknowledged security problem. Might be worth summarizing, as >> it is central to this draft, but an example is in rfc 8402/section 8. >> Section 3 of this draft (“The SRv6 Security Problem”) doesn’t actually >> describe the security problem; Section 5 does, briefly. >> >> 2. The solution (using a new EtherType, SRv6-ET) is a good one. It’s sad >> that this wasn’t done from the get-go, as the solution is a bit “evil >> bit”-ish. I’d prefer to see ALL SRv6 packets (i.e., those containing SRH) >> use SRv6-ET. Boundary routers SHOULD drop packets with SRv6-ET that cross >> the boundary in either direction; all routers MUST drop packets with SRH >> that don’t have SRv6-ET. Yeah, difficult, but the added security is worth it. >> >> 3. Ease of secure deployment is a major consideration; this draft is a big >> step in that direction. >> >> 4. As Adrian said, several nits. Will send separately to authors. >> >> Kireeti >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
