+1 Joel
AFAIS it's same effort to upgrade something to process SRH or to process
new ethertype properly. And in a sense upgrade to something that drops
ether type SRv6 if it's not supposed to be processed is no upgrade today,
routers as per today will pretty much do it automatically creating a TD
boundary for free. That's the jest of the draft. And as Joel pointed out
sending SRv6 through open internet v6 routers is peeling stickers off the
standards anyway so strictly speaking per standard anything that shows up
from the "wide, wild, free Internet" that looks like IPv6 but tries to be
SRv6 is pretty much an attack ;-)
Inside the trusted domain one could not use the ether type but forward on
pseudo-IPv6-address since we're in the "limited domain" (as Muthu ponders)
but then anything that can send out a v6 packet to any destination (as e.g.
completely benign, non-raw user space socket) can start SRv6 attacks (at
least without SRH) as we know and the burden of "how do we stop it from
leaving the TD without ether type" gets us back into the whole
'router-srh-processing-firewall' discussion ...
-- tony
On Thu, Mar 30, 2023 at 1:29 PM Joel Halpern <j...@joelhalpern.com> wrote:
> Not quite, but close.
>
> Routers which are not upgraded, and receive packets with the new
> ethertype, will drop them. Which theoretically is fine for routers which
> are not intended to be on SRv6 paths. Practically, since you want to be
> able to run the paths where you need them, you probably do need to upgrade
> all routers to accept and propagate the new ethertype if you want to use
> this solution. For some operators, that is a show stopper and they will
> not use this capabilities. For others, it is quite deployable, and even
> helpful in keeping control of what servicces are offered where.
>
> Yours,
>
> Joel
> On 3/29/2023 12:00 PM, Muthu Arul Mozhi Perumal wrote:
>
> So, using the new ethertype inside a (closed/open) domain would require
> all IPv6 routers inside the domain to support SRv6 or at least support the
> new ethertype to check if any IPv6 packet containing an SRH was received
> with this ethertype? If an IPv6 router supports neither, then one cannot
> enable this feature on any of its neighbor's interface, right?
>
> Regards,
> Muthu
>
> On Wed, Mar 29, 2023 at 5:40 PM Robert Raszuk <rob...@raszuk.net> 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 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 <markzzzsm...@gmail.com>
>> wrote:
>>
>>> On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <rob...@raszuk.net> 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 <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> 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
>>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
> _______________________________________________
> Int-area mailing
> listInt-area@ietf.orghttps://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> 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
