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

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

Hi Peter,

Thanks for your reply and, especially, your pointer.

Best regards,

JMC.

Le jeu. 10 oct. 2024 à 09:04, Liuchunchi(Peter) <[e-mail]> a
écrit :

> Hi Jean-Michel,
>
>
>
> This is an interesting question and directly relates to data leakage
> problem. Preventing SRv6 packet leak from trusted domains are required by
> RFC8402, as you listed, but each individual forwarding decision still
> depends on the border device. Having 100% guarantee/proof of no-leakage is
> like proof-of-non-transit, very hard to achieve. But on one hand, having a
> full audit record about “where did this border device A forwarded this
> packet/flow X” definitely helps. On the other hand, I think its
> SPRING/SRv6OPS’s day job to consider developing methods to more securely
> filter them. Two techniques can complement each other. Some related work in
> the INTAREA ongoing:
> https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/
> if it helps
>
>
>
> Peter
>
>
>
> *From:* Luigi IANNONE <luigi.iannone=[e-mail]>
> *Sent:* Wednesday, October 9, 2024 8:46 PM
> *To:* Jean-Michel Combes <[e-mail]>; Liuchunchi(Peter)
> <[e-mail]>
> *Cc:* Toerless Eckert <[e-mail]>; Michael Richardson <
> [e-mail]>; 刘鹏辉 <[e-mail]>; Meiling Chen <
> [e-mail]>; [e-mail]
> *Subject:* RE: [nasr] Re: 回复: Re: Secure Routing Path Consideration-
> China Mobile-ietf120
>
>
>
> Hi Jean-Michel,
>
>
>
> *From:* Jean-Michel Combes <[e-mail]>
> *Sent:* Wednesday, 9 October 2024 13:03
> *To:* Liuchunchi(Peter) <liuchunchi=[e-mail]>
> *Cc:* Toerless Eckert <[e-mail]>; Michael Richardson <
> [e-mail]>; 刘鹏辉 <[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,
>
>
>
> 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?
>
>
>
> *[LI] Interesting use case. I would say that the “auditing” part of NASR
> can some how used for that purpose. **😉*
>
>
>
> *Ciao*
>
>
>
> *L.*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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]
>
>