Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Robert Raszuk <[e-mail]>]

Hi Brian,

Yes I am quite aware of lack of assurance from transit nodes for EHs.

But one could construct useful SRv6 packets without using SRH too.

On new ethertype I fully second your "good luck" wishes.

Cheers,
R.



On Thu, Mar 30, 2023, 10:26 Brian E Carpenter <[e-mail]>
wrote:

> Robert,
>
> On 30-Mar-23 01:10, Robert Raszuk wrote:
> > Nope, that is completely not what I have in mind,
> >
> > Please remember that transit nodes are not SRv6 aware in closed or open
> domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink
>
> Only if the SRv6-carrying IPv6 packet is encapsulated inside a normal IPv6
> packet. Otherwise, as we know from RFC 7872 and ongoing work, the Internet
> is not transparent to IPv6 packets carrying "unknown" extension headers.
>
> Since that situation has been blocked for many years (and the equivalent
> operational situation for unknown IPv4 options has been blocked for many
> more years), I think the fact that SRv6 semantics are local within a trust
> boundary is unlikely to change.
>
> (As for deploying a new Ethertype on every switch and router in the world,
> well, good luck with that, since it will be as hard as deploying IPv6,
> which we have still only achieved to 42.95% according to Google's graph for
> March 25.)
>
> Regards
>     Brian
>
> > to my MEC or private DC where services are being properly demuxed based
> on the SID/uSID.
> >
> > If you close this date plane option by new ethertype my car is
> disconnected,
> >
> > So I am not sure who is  "incredibly naive" here or perhaps to put it a
> bit more politely who does not understand the power of new technology.
> >
> > Regards,
> > R.
> >
> >
> > On Wed, Mar 29, 2023 at 5:02 AM Mark Smith <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <[e-mail]
> <mailto:[e-mail]>> wrote:
> >      >
> >      > Guys,
> >      >
> >      > What you are really saying here is that the concept of using
> network programmability should be killed and we should get stuck for
> decades to come with closed domains only innovation.
> >      >
> >      > I find it quite disturbing especially as we are talking about
> Internet Engineering Task Force produced standards here.
> >      >
> >      > Yes it has been derailed {not to say hijacked} into
> standardization of private extensions for various protocols which are
> limited to closed domains as the technology of new forwarding paradigm
> called MPLS simply by design was not applicable to be deployed in the open
> Internet. But that should not mean we should get stuck with this till new
> generation understands mistakes made and moves forward,
> >      >
> >      > It is obvious that those who invested heavily in MPLS will fight
> to protect it no matter what. But new technologies and services are being
> deployed over SRv6 using native IPv6 dataplane. Examples are mobile nodes
> which move from network to network.
> >      >
> >      > Is this closed domain - no by any means. Is it working today -
> yes pretty well.
> >      >
> >      > So proposing a new ethertype for SRv6 today seems to be
> comparable to putting a stick into the wheels of a cool bicycle starting to
> gain speed.
> >      >
> >
> >     If you believe one network operator is going to let another network
> >     operator program the first network operator's network, then I think
> >     you're incredibly naive about how the multi-party Internet is
> operated
> >     and the security and availability concerns network operators have.
> >
> >
> >
> >      > Respectfully to all td-srv6 authors and cheerleaders,
> >      > Robert
> >      >
> >      >
> >      > On Wed, Mar 29, 2023 at 1:58 AM Tony Przygienda <
> [e-mail] <mailto:[e-mail]>> 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 <
> [e-mail] <mailto:[e-mail]>> wrote:
> >      >>>
> >      >>> On Mar 28, 2023, at 11:24, Adrian Farrel <[e-mail]
> <mailto:[e-mail]>> 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
> >      >>> [e-mail] <mailto:[e-mail]>
> >      >>> https://www.ietf.org/mailman/listinfo/spring <
> https://www.ietf.org/mailman/listinfo/spring>
> >      >>
> >      >> _______________________________________________
> >      >> spring mailing list
> >      >> [e-mail] <mailto:[e-mail]>
> >      >> https://www.ietf.org/mailman/listinfo/spring <
> https://www.ietf.org/mailman/listinfo/spring>
> >      >
> >      > _______________________________________________
> >      > spring mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/spring <
> https://www.ietf.org/mailman/listinfo/spring>
> >
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
>