I would argue rather strongly that the two mechanisms are complementary. I see security mechanisms as additive especially when we are dealing with something that can have such dire security consequences if it goes wrong.
As such - neither myself nor the co-authors believe that these mechanisms contradict and both should stand. While I agree that deploying a new ethertype isn’t easy - there are operators out there who we have spoken to who do want this - and this is one optional way if deploying srv6 - so individuals who choose to deploy without this mechanism may continue to do so. That being said, I would argue that if we wish to see the technology widely deployed, it serves everyone to see that operators have the option to run it in the mode they see fit, especially considering that this option should not require hardware level changes (ethertype rewrite is common across platforms - for many technologies) New draft coming in the next few minutes to address other comments Thanks Andrew Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Sent: Friday, March 31, 2023 8:18:20 PM To: Krzysztof Szarkowicz <kszarkow...@juniper.net>; Kireeti Kompella <kireeti.i...@gmail.com> Cc: Adrian Farrel <adr...@olddog.co.uk>; Andrew Alston - IETF <andrew-i...@liquid.tech>; int-area@ietf.org <int-area@ietf.org>; spr...@ietf.org <spr...@ietf.org>; Dr. Tony Przygienda <tonysi...@gmail.com> Subject: RE: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt On second thought, if we had the new ethertype, we wouldn’t need the new /16! They serve the same function Ron From: Ron Bonica Sent: Friday, March 31, 2023 1:05 PM To: Krzysztof Szarkowicz <kszarkowicz=40juniper....@dmarc.ietf.org>; Kireeti Kompella <kireeti.i...@gmail.com> Cc: Adrian Farrel <adr...@olddog.co.uk>; Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org>; int-area@ietf.org; spr...@ietf.org; Dr. Tony Przygienda <tonysi...@gmail.com> Subject: RE: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt +1 If we allocate a /16 for SRv6 USIDs, as proposed in https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt<https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt>, we can allow that prefix only when the new ethertype is used. Ron From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Krzysztof Szarkowicz Sent: Wednesday, March 29, 2023 5:30 AM To: Kireeti Kompella <kireeti.i...@gmail.com<mailto:kireeti.i...@gmail.com>> Cc: Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>; Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org<mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>; int-area@ietf.org<mailto:int-area@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; Dr. Tony Przygienda <tonysi...@gmail.com<mailto:tonysi...@gmail.com>> Subject: Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt [External Email. Be cautious of content] SRv6 packet might have SRH, but might not have SRH. Especially with uSID, you can craft a decent SR-TE SRv6 packet without SRH. So I think, Kireetis’ comments should apply to all SRv6 packets (with/without SRH). — Krzysztof On 2023 -Mar-29, at 17:57, Tony Przygienda <tonysi...@gmail.com<mailto: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. 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<mailto:kireeti.i...@gmail.com>> wrote: On Mar 28, 2023, at 11:24, Adrian Farrel <adr...@olddog.co.uk<mailto: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 spr...@ietf.org<mailto:spr...@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!GGgCymh1gmvxc7ibG9cWpBOm73ewlZbNJjAA4xw8KNZFBMd9ROvcdT5tCSooD-OCMYFWheicbBfDrzfTkoY7bGn7W65rg0E$> _______________________________________________ spring mailing list spr...@ietf.org<mailto:spr...@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring> Juniper Business Use Only Internal All Employees
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
