[saag] Re: [nasr] Re: Initial thoughts on NASR

"Meiling Chen" <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <[email protected]>
Hi Eric,
I'm trying to make an explanation to your questions,
please see inline.

Best,
Meiling
 
From: Eric Rescorla
Date: 2025-03-16 07:48
To: Toerless Eckert
CC: nasr; IETF SAAG; draft-liu-nasr-architecture
Subject: [nasr] Re: Initial thoughts on NASR


On Fri, Mar 14, 2025 at 6:24 PM Toerless Eckert <[email protected]> wrote:
Thanks, Eric

1. If you have some suggestion different from what i was writing in my first
repsonse as to how to improve the text of the architecture, that would be
highly welcome.

Well, I'm reacting to the text in the architecture, and I would remove most of
the pieces I identified. If you want to propose specific new text, I'm happy to
take a look.


2. Wrt. the complexity of requiring NASR on every hop and that being a pain.
>From where i stand, it actually can also be (hopefully) a significant simplification
to replace more complex encryption based approaches.


Explanatin for 2.:

One of the side-result of NASR i am hoping for is that the per-hop modified NASR header
providing authenticated proof-of-transit of the prior hop will actually be a lot
easier to support in high-speed forwarding plane then a full-blown per-hop encryption
of traffic with e.g.: IPsec/DTLS/QUIC/MACsec (or other). Even MACsec is NOT becoming
more ubiquitous from what i see in NIC chips.

I'm confused. In your previous message, you alluded to link layer encryption as protection
against traffic analysis attacks. Proof-of-transit is not an adequate substitute in cases where
the link isn't encrypted, because then you need to be able to guarantee the security of
hundreds of kilometers of fiber or copper.

[Meiling] I completely agree with your viewpoint "Proof-of-transit is not an adequate substitute in cases where
the link isn't encrypted,", I think this is a misconception. Encryption and NASR have never been in opposition, 
what we want to ensure is that even in an encrypted state, encrypted data is difficult for attackers to obtain. 
After all, no one wants to open the door to attackers.

-Ekr

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.