On 30-Mar-23 21:00, Tony Przygienda wrote:
+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 ...
Well yes. We tried to make this a bit more concrete in
https://www.rfc-editor.org/rfc/rfc8799.html#name-functional-requirements-of-
Relying on human-based configuration seems prone to errors and loopholes.
Brian
-- tony
On Thu, Mar 30, 2023 at 1:29 PM Joel Halpern <j...@joelhalpern.com
<mailto: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
<mailto: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
<mailto:markzzzsm...@gmail.com>> wrote:
On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <rob...@raszuk.net
<mailto: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
<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
>>> spring@ietf.org <mailto:spring@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org <mailto:spring@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@ietf.org>
> https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
Int-area mailing list
int-a...@ietf.org <mailto:int-a...@ietf.org>
https://www.ietf.org/mailman/listinfo/int-area
<https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
Int-area mailing list
int-a...@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
