[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]