[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

[Jean-Michel Combes <[e-mail]>]

Hi,

IETF has already standardized protocols doing only  _assumptions_ (i.e., no
way to check the reality) on security rules regarding the boundary of the
domain where such protocols are deployed:
- SFC [RFC8300, section 8.1]
"In summary, packets originating outside the SFC-enabled domain MUST be
dropped if they contain an NSH. Similarly, packets exiting the SFC-enabled
domain MUST be dropped if they contain an NSH."
- RPL [RFC6554, section 5.1]
"As specified in this document, RPL routers MUST drop datagrams entering or
exiting a RPL routing domain that contain an SRH in the IPv6 Extension
headers."
- SRv6 [RFC8402, section 8.2]
"SR domain boundary routers MUST filter any external traffic destined to an
address within the SRGB of the trusted domain or the SRLB of the specific
boundary router. External traffic is any traffic received from an interface
connected to a node outside the domain of trust.
>From a network-protection standpoint, there is an assumed trust model such
that any node adding an SRH to the packet is assumed to be
allowed to do so. Therefore, by default, the explicit routing information
MUST NOT be leaked through the boundaries of the administered domain.
Segment Routing extensions that have been defined in various protocols,
leverage the security mechanisms of these protocols such as encryption,
authentication, filtering, etc."

Can NASR help to transform such _assumptions_ into _proofs_ and, so, to
"achieve" (for the security part) the IETF works done on these protocols?

BTW, this is just a list of protocols I am aware of ... maybe others exist
with the same _assumptions_ ...

Thanks in advance for your replies.

Best regards,

JMC.

Le mar. 8 oct. 2024 à 12:31, Liuchunchi(Peter) <liuchunchi=
[e-mail]> a écrit :

> just got back from a national holiday, sorry about the delays
>
> using filtering policies to control the dissemination border of security
> sensitive content is very good to have (and maybe is what we wanted in the
> first place), but as michael and luigi mentioned, the inability to
> completely eliminate L2 stealth nodes makes the work less exciting. But
> what we can do is, based on basic RATS methods, under certain trust
> assumptions, create a protocol to produce auditable forwarding evidence,
> which proves the device trustworthiness, execution logs, link security
> methods used, etc (exact items may be what we have to decide) when certain
> flow or packets are forwarded. In this way, it appears the more
> cost-efficient choice (for now, the first step) might be operation-centric
> forwarding auditing of above information, compact proof creation and
> visualization. This works as a tool that just objectively verifies and
> audits forwarding. Just thinking :P
>
> > -----Original Message-----
> > From: Toerless Eckert <[e-mail]>
> > Sent: Saturday, October 5, 2024 1:12 AM
> > To: Michael Richardson <[e-mail]>
> > Cc: Liuchunchi(Peter) <[e-mail]>; =?us-
> > ascii?B?PT91dGYtOD9CPzVZaVk2Ym1QNkw2Sj89?=
> > <[e-mail]>; Meiling Chen <[e-mail]>;
> > [e-mail]
> > Subject: Re: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China
> > Mobile-ietf120
> >
> > On Thu, Oct 03, 2024 at 05:26:23PM -0400, Michael Richardson wrote:
> > >
> > > Toerless Eckert <[e-mail]> wrote:
> > >     > But avoidance of copying of traffic by undesired third parties
> if course a
> > core
> > >     > benefit that NASR can provide. And those prior examples can
> provide
> > examples of
> > >     > the attack vectors why that is undesirable. Even with todays
> easily
> > available
> > >     > end-to-end encryption.
> > >
> > > NASR can not provide any kind of avoidance of copying!
> >
> > I meant indirectly by being a way to ensure traffic paths that are
> expected to
> > make copying & decryption hard...impossible.... or possible by the
> "right"
> > people ;-)
> >
> > > (To do that you'd need quantum entangled links of the kind the QIRG is
> > > contemplating)
> >
> > Nice point actually. I remember Huawei was in the past a big fan of
> quantum
> > entangled links (last data point 2018). Cryptographers of course are
> always
> > dismissive (somewhat of a competition). And the visit in Yokohama to the
> > quantum research lab on friday was all about allowing entanglement to
> > actually go across longer paths.
> >
> > So i would certainly like to consider the continuuom of different
> methods to
> > protect links and nodes as part of a NASR architecture.
> >
> > Of course, i would foremost point to the added crypto value of hop-by-hop
> > encryption as opposed to only end-to-end encrypion, because of the higher
> > cost of crypto attacks - especially when you combine it with load
> distribution
> > across different paths.
> >
> > > What NASR can do is provide assurance that when you have such links,
> that:
> > > a) there are no stealth routers in the path.
> >
> > Depending on the technologies we emply in NAS, your could still have a
> > stealth L2 device though. Which by the way is a common way how firewalls
> > operate.
> >
> > > b) that the two sides of each QIRG link are operating nominally.
> >
> > Right.
> >
> > Cheers
> >     Toerless
> >
> > >     > But maybe much simpler: nation state actors have the means to
> extract
> > and even decrypt
> > >     > end-to-end traffic. But if they can not see the traffic because
> it does not
> > run across
> > >     > the paths desired by them, because they pass their network taps
> - then
> > >     > they can't do that.
> > >
> > > yes.
> > >
> > > --
> > > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> > >            Sandelman Software Works Inc, Ottawa and Worldwide
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > ---
> > [e-mail]
> --
> nasr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>