[nasr] Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up

[Meiling Chen <[e-mail]>]

Hi Eric,

Your reply has left me very confused, please see inline.










 



发件人: Eric Rescorla

时间: 2025/05/29(星期四)11:00

收件人: Liuchunchi(Peter);

抄送人: Meiling Chen;Luigi IANNONE;Toerless Eckert;nasr;IETF SAAG;Luigi Iannone;

主题: Re: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up









On Wed, May 28, 2025 at 7:32 PM Liuchunchi(Peter) <[e-mail]> wrote:
      

 

 

Okay I think there is some minor confusion here…  

  

 1. The router in question would forward/has forwarded specific
 traffic classes on specific links and not others. 

 [LI] Nope. NASR is not about forwarding on specific links. It is about being able to proof that traffic went through a certain set of devices that fulfil a set of claims (or requirements if you wish…). 

 2. That specific traffic classes would be/had been encrypted
 using MACSEC. 

[LI] Nope. (as I state in a previous mail) this is orthogonal to NASR. Whether you want to use it is not part of the NASR problem statement. 

  

  

“A five tuple flow X use encrypted links“ IS a claim at device level. It is attestable by aggregating the evidences (configurations of all devices on path) and be inspected by the verifier. 




Well, that's precisely the question I think needs to be examined.

To take your example, suppose that we have elements A and B which have
an IPsec tunnel between them, and we want to know that all traffic
with a given 5-tuple will therefore be protected on that link. How do
we go about doing that by looking at the configuration directives?

[Meiling] I'm a little curious why we've been stuck in the quagmire of end-to-end security.

From A to B, as long as both A and B support IPsec, it is sufficient. When establishing a IPsec tunnel between A and B, there is no concern for the status of each node along the way, only mutual communication is required.

I guess the question you raised is how to ensure the security status of each node(exlude A and B) in the forwarding path after IPsec has established a secure tunnel, So when checking the configuration directives, are they for A and B, or for forwarding nodes along the path?





The obvious place to start is by looking at the IPsec configuration to
see which traffic should be sent over the tunnel.



This is necessary but not sufficient. For instance, suppose that IPsec
is configured to use AH not ESP, so it's not encrypted? So, we need to
examine which IPsec modes are in use and which transport ciphers they
use.

[Meiling] The end-to-end security negotiation is not directly related to the network, IPsec is configued to use AH or ESP is decided by Customers, and usually deployed on user owned nodes, right? 

Similarly, IKE might be configured with some kind of insecure key
establishment mode, so we need to look at the IKE key establishment
configuration. Further, we need to look at IKE authentication. Does it
use PKI or a shared key? Is that shared key actually being handled
securely, or is it a short password everyone knows?
[Meiling]So do you mean to monitor the SA and Auth interactions of the entire IKE?

This may well not be an exhaustive list, because I haven't thought
about all the ways things can be misconfigured, even for a
comparatively trivial property like this.

-Ekr












  

 

 

 

From: Meiling Chen <[e-mail]> 
 Sent: Thursday, May 29, 2025 9:27 AM
 To: Luigi IANNONE <[e-mail]>; Eric Rescorla <[e-mail]>
 Cc: Toerless Eckert <[e-mail]>; nasr <[e-mail]>; IETF SAAG <[e-mail]>; Luigi Iannone <[e-mail]>
 Subject: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up   

  

 

Hi,  

 

  

 

I think Luigi's reply is completely in line with the original intention.  

 

   

 

Best,  

 

Meiling  

 

     

 

   

 

 

发件人: Luigi IANNONE  

 

时间: 2025/05/27(星期二)15:46  

 

收件人: Eric Rescorla;Meiling  Chen;  

 

抄送人: Watson Ladd;Henk  Birkholz;Liuchunchi;Toerless  Eckert;nasr;IETF  SAAG;Luigi Iannone;  

 

主题: RE: Re: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up    

 

HI, 

  

I think there is a bit of a  misunderstanding …  

  

 

 

 


 The BOF presented a number of problems that allegedly NASR was trying
 to solve, including that:
 
 1. The router in question would forward/has forwarded specific
 traffic classes on specific links and not others. 

[LI] Nope. NASR is not about forwarding on specific links. It is about being able to proof that traffic went through a certain set of devices that fulfil a set of claims (or requirements  if you wish…). 

Attesting that the set of devices fulfils the requirements is done by extending the RATS technology.  

Proving that the traffic did go through those devices is done a proof of transit technology for which there are a couple of early ideas documented.  


 2. That specific traffic classes would be/had been encrypted
 using MACSEC. 

[LI] Nope. (as I state in a previous mail) this is orthogonal to NASR. Whether you want to use it is not part of the NASR problem statement.
 
 NASR represents one specific proposal for addressing these problems,
 which is to attest to the code and configuration running on specific
 network elements. So, yes, a system like NASR needs to establish
 that the code and configuration guarantees these properties in
 order to address the stated problem.  

[LI] You do not need that level of granularity.  

It's certainly not sufficient
 to demonstrate that the device simply supports MACSEC, because
 it might be disabled.
 
 If you think there is some other set of problems that need to be
 solved, and that these don't need to be then I think you need to state
 that more clearly. 

[LI] Agreed. We certainly need to do more work in clarifying the problem and possible solution space. 

The ongoing exchange in very helpful in this sense. 

Thanks 

Ciao 

L.  

  


 
 -Ekr