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

Eric Rescorla <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <CABcZeBNSBzCeM08K7gCd4DeWgTDe9d252eYh+UjXj7nuHjL1pQ@mail.gmail.com>
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.

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