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

[Yutaka OIWA <[e-mail]>]

Hmm, it seems interesting
I am preparing requirements for “requirements“ spec as a draft update and like to see whether one of these existing ones will meet the req or not.
Also I would be going to design proof representation as well.
I hope we can talk in Dublin for next directions and steps.


--
Yutaka OIWA <[e-mail]> on mobile
________________________________
差出人: Jean-Michel Combes <[e-mail]>
送信日時: Wednesday, October 9, 2024 1:03:24 PM
宛先: Liuchunchi(Peter) <liuchunchi=[e-mail]>
CC: Toerless Eckert <[e-mail]>; Michael Richardson <[e-mail]>; 刘鹏辉 <[e-mail]>; Meiling Chen <[e-mail]>; [e-mail] <[e-mail]>; Luigi IANNONE <[e-mail]>
件名: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

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]<mailto:[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]<mailto:[e-mail]>>
> Sent: Saturday, October 5, 2024 1:12 AM
> To: Michael Richardson <[e-mail]<mailto:[e-mail]>>
> Cc: Liuchunchi(Peter) <[e-mail]<mailto:[e-mail]>>; =?us-
> ascii?B?PT91dGYtOD9CPzVZaVk2Ym1QNkw2Sj89?=
> <[e-mail]<mailto:[e-mail]>>; Meiling Chen <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
> >
>
>
>
> --
> ---
> [e-mail]<mailto:[e-mail]>
--
nasr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>