First, I would say that it39s much worthwhile to seriously evaluate the
security risk associated with SRv6 although it looks pretty cool to some fans:)
Second, besides the proposal of allocating a new Ethertype for SRv6, how about
adopting the underlay/overlay network model to reduce the attack risk
associated with SRv6, that39s to say, any untrusted traffic entering the
boundary of the trust domain would be processed as overlay traffic, more
specifically, the untrusted traffic would be encapsulated with an IPv6 tunnel
(with an SRH inside) and the SRH contained in the untrusted traffic would be
neglected. In other word, any （underlay）IPv6 addresses within the trusted
domain are unreachable to the untrusted (overlay) traffic.
Best regards,
Xiaohu
----邮件原文----发件人：Tony Przygienda <tonysi...@gmail.com>收件人：Joel Halpern
<j...@joelhalpern.com>抄 送: Muthu Arul Mozhi Perumal
<muthu.a...@gmail.com>,spring <spring@ietf.org>,int-area
<int-a...@ietf.org>发送时间：2023-03-30 16:00:44主题：Re: [Int-area] [spring] FW: New
Version Notification fordraft-raviolli-intarea-trusted-domain-srv6-00.txt+1 Joel
AFAIS it39s 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 it39s 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.
That39s 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 we39re 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
39router-srh-processing-firewall39 discussion ...
-- tony
On Thu, Mar 30, 2023 at 1:29PM 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 neighbor39s interface, right?
Regards,
Muthu
On Wed, Mar 29, 2023 at 5:40PM 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:02AM 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 operator39s network, then I think
you39re 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:58AM Tony Przygienda
<tonysi...@gmail.com> wrote: >>
>> Though I would like to cheer for Kireeti39s 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-it39s-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
were performed with drafts whose authors39 list length
sometimes rivaled pages of content -) I think this
ship has sailed and that39s 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, no39one 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:33PM 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. >>>
>>> tldr >>> >>> 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
