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

On Mon, May 26, 2025 at 1:47 AM Meiling Chen <[email protected]>
wrote:

> Hi Eric,
> Please see inline.
>
>
> *From:* Eric Rescorla <[email protected]>
> *Date:* 2025-05-26 11:15
> *To:* Meiling Chen <[email protected]>
> *CC:* Luigi IANNONE <[email protected]>; Watson Ladd
> <[email protected]>; Henk Birkholz <[email protected]>;
> Liuchunchi <[email protected]>; Toerless Eckert
> <[email protected]>; [email protected]; IETF SAAG <[email protected]>; Luigi Iannone
> <[email protected]>
> *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),
>
>
I don't really understand your response here.

If you look at RFC 5434, we start by asking about the problem
statement, not the technology:

there is a problem that needs solving, and the IETF is the
right group to attempt solving it.

And then later whether there is a viable approach to solving
the problem:

it is believed that the WG has a reasonable probability of
having success (i.e., in completing the deliverables in its
charter in a timely fashion).

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.
2. That specific traffic classes would be/had been encrypted
using MACSEC.

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. 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.

-Ekr

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