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

[刘鹏辉 <[e-mail]>]

Hi Luigi,




Toerless etc said there may be stealth L2 device in-between routing as discussed in early emails...

I mean If NASR is more on forwarding, not routing, then we will have a lot to discuss, such as forwarding content by more non-network external interfaces for multifunctional network devices.




> "Hello NASRers,

> 
>One of the topic that we can tackle on the mailing list and finalize during the interim is about the scope of NASR in particular about “Routing vs Forwarding”.
> 
> During the BoF, several persons pointed out that we are not clear on whether NASR is about:
> 
1) Fowarding: being able to audit a path and obtain a proof of transit. Building the path being out of scope.
> 
>2)  Routing: This is forawarding + Building the path by distributing trust and  reachability information.
> 
>In my personal opinion I see NASR more on the forwarding side, hence focusing on the auditing tools.
> 
>Extending routing solution to distribute relevant information for NASR to work can be done in the future and not necessarily in the NASR WG but as an extension of other protocols, hence in  > their respective WGs.
> 
>Anyone to share more thoughts on this point?  
> 
>L.
>--

>nasr mailing list -- [e-mail]"







At 2024-10-10 17:37:22, "Luigi IANNONE" <luigi.iannone=[e-mail]> wrote:

Hi Penghui,

 

As for renaming the group, IMO we need first to clearly define the scope and target and then we can check if NASR is still a meaningful name. 

 

As for the external device interface, can you elaborate a bit your point? It is not clear to me what you mean.

 

Thanks

 

Ciao

 

L.

 

 

From:刘鹏辉 <[e-mail]>
Sent: Thursday, 10 October 2024 04:18
To: Jean-Michel Combes <[e-mail]>
Cc: Liuchunchi(Peter) <liuchunchi=[e-mail]>; Toerless Eckert <[e-mail]>; Michael Richardson <[e-mail]>; Meiling Chen <[e-mail]>; [e-mail]; Luigi IANNONE <[e-mail]>
Subject: Re:[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

 

Hi,

 

If NASR is more on forwarding, not only routing, the naming of NASR may need to rename?

BTW, wether we need to consider external device interface forwarding security? just like in DVB CI-PLUS, USB,CI, HDMI, AV, spdif etc, Many network devices nowadays are multifunctional machines.

 

BR,

 

Penghui liu

 

 

At 2024-10-09 19:03:24, "Jean-Michel Combes" <[e-mail]> wrote:

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]