[saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follo w-Up

Hi Eric,
Please see inline.
 
From: Eric Rescorla
Date: 2025-05-26 11:15
To: Meiling Chen
CC: Luigi IANNONE; Watson Ladd; Henk Birkholz; Liuchunchi; Toerless Eckert; [email protected]; IETF SAAG; Luigi Iannone
Subject: Re: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up


On Sun, May 25, 2025 at 7:23 PM Meiling Chen <[email protected]> wrote:
Hi Eric,

* This traffic was sent over an encrypted link
* All traffic to address X will be sent over an encrypted link
[Meiling] What does an encrypted link refer to, who established the link, and who negotiated encryption with whom?

I don't understand your question. I'm referring to the proposal by Diego that NASR would allow you to ensure the use of MACSEC.
[Meiling] When designing NASR, I considered MACSEC as a security capability, this is an option(If the costomer selected), and does not mean that NASR supports MACSEC by default.


* This traffic is not being sent to a spanning port or otherwise available for monitoring
[Meiling] Traffic is forwarded according to expected nodes and ports, and will not sent to a spanning port. 

Expected by the counterparty, correct?
[Meiling] Right.
 
As for monitoring, it depends on the customer's choice, NASR just to ensure that there will be no monitoring without the user's consent.

Right, and so one such claim is that there is no monitoring.
[Meiling]Strictly speaking, NASR only handles traffic and does not forward it to unknown nodes or ports, and monitoring is not within its scope.

In any case, these all seem like fairly nontrivial properties to guarantee, so I think it's relevant to see some evidence that it's actually practical to mechanically determine whether a given router configuration provides them.
[Meiling] In fact, I think there is a misunderstanding or too high expectations for NASR, for example, do we need to check every configuration if someone claim to support MACSEC functionality?(I'm not sure if this is necessary), 

-Ekr


Meiling
 
From: Eric Rescorla
Date: 2025-05-24 00:32
To: Luigi IANNONE
CC: Watson Ladd; Meiling Chen; Henk Birkholz; Liuchunchi; Toerless Eckert; [email protected]; IETF SAAG; Luigi Iannone
Subject: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up


On Thu, May 22, 2025 at 12:52 AM Luigi IANNONE <[email protected]> wrote:
Hi Watson,

> 
> Correct. Some claims are easy to verify. Most aren't. Statements that "the
> router supports X" aren't really interesting. Statements that "this
> configuration will never pass your traffic over a bad link" are, but are a lot
> harder to show.
> 
> >

[LI] Agreed. This is a very claim hard show/attest. 
Note however that this is not what NASR is trying to do. 
NASR is more about router has feature X, Y, and Z which is what I want, and that traffic goes through the selected routers that support X, Y and Z.
NASR is not about proving that traffic does not go somewhere else (proof of non-transit is out of scope). 

As I understood the presentations, you wanted to make claims like:

* This traffic was sent over an encrypted link
* All traffic to address X will be sent over an encrypted link
* This traffic is not being sent to a spanning port or otherwise available for monitoring

Correct?

-Ekr



-Ekr


Ciao

L.

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]