+1
If we allocate a /16 for SRv6 USIDs, as proposed in
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 <[email protected]> On Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, March 29, 2023 5:30 AM
To: Kireeti Kompella <[email protected]>
Cc: Adrian Farrel <[email protected]>; Andrew Alston - IETF
<[email protected]>; [email protected]; [email protected];
Dr. Tony Przygienda <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> wrote:
On Mar 28, 2023, at 11:24, Adrian Farrel
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
