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>
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

Reply via email to