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

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.

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.

Of course, this hope is because RFC8994 (ACP), which does rely on per-hop encryption
to provides protection for the network infrastructure itself, including protection
against forwarding of any injected traffic (to exploit weaknesses anywhere). And this
lack of per-hop encryption is the biggest impediment to adoption for rfc8994.

The next closest thing to the ACP approach would be protect the network infrastructure
(protocols etc.) by exactly the end-to-end encryption of all network management/control
traffic plus the per-hop transit authentication/verification. Of course, this would be
ANIMA picking up the NASR forwarding plane work and re-using it (and not the full NASR
attestation/orchestration layer in the backend). But thats one of the reasons why i am
interested in NASR.

And i have started to write up that approch of ACP without per-hop encryption,
relying instead only on end-to-end encryption. That draft does not yet tackle
those additional security aspects such as NASR PoT or how to make stupid old
not-yet-end-to-end encrypted network management/control traffic automatically run
on top of end-to-end encrypted tunnels, but those are longer term goals what i would
like this to evolve into. Short term this work is meant to encourage developing
and standardizing new network automation management/control software on top of automated
key-management end-to-end encryption. draft-eckert-anima-acp-free-ani-00.

Cheers
    Toerless


On Fri, Mar 14, 2025 at 01:02:40PM -0700, Eric Rescorla wrote:
> On Fri, Mar 14, 2025 at 12:17 PM Toerless Eckert <[email protected]> wrote:
> 
> > Thanks, Eric
> >
> >
> > Regulatory or subscriber requirements against the path used by traffic
> >
> >   - Permissible countries/regions of transit (EU, USA&friend, ...)
> >   - Permissible network equipment vendors or operators (e.g.: trust in
> > integrity)
> >   - required certifications of network equipment on path
> >     (including any type of software version or bug-fix attesttions)
> >   - "Greenness" of path equipment / path power-sources
> >
> > Reasons for the attestation of any of these path properties may include
> >   - political or commercial policies
> >   - marketing/value goals ("greenness")
> >   - reliability expectation
> >   - confidentiality expectations
> >
> 
> Sure. I alluded to this in my message "as a response to some policy
> requirements"
> 
> 
> Now, as to the specific concerns re. confidentiality.
> >
> > I remember even back in ?2010 or the like that DPI implementations in
> > routers for
> > encrypted traffic where able to analyze traffic patterns without
> > decryption to
> > determine wide range of session details. Including back then different
> > type of video conferences of otherwise all-encrypted RTF sessions purely by
> > simple traffic-train pattern analysis. A couple years laters, researchers
> > did the same thing and thought it was new. And now its revived with the
> > term
> > AI.
> >
> 
> Yes, I'm of course aware that protocols are vulnerable to traffic analysis
> attacks,
> and I agree that this is a setting in which lower layer encryption is
> helpful in
> that it helps conceal patterns in individual flows by aggregating them with
> other flows. It's not a complete solution as the various distinguishing
> attacks on Tor show, and I think we clearly need some anti-traffic analysis
> techniques that live at the end-to-end layer but I agree that lower layer
> encryption is valuable.
> 
> However, as I said in my original email, I have two concerns with the
> presentation
> in this document:
> 
> - The list of reasons that this document offers for why it is needed goes
>   far beyond traffic analysis, including a number of issues (e.g., PQ),
> where
>   I don't think the reasoning above holds.
> 
> - The fix being offered here is effectively to individually secure every
> link in the
>   network, which is plainly very challenging. Coupled with the point above,
>   it leaves the impression that the proponents think we should *not* address
>   issues at the end-to-end layer but instead try to secure the entire
> network
>   fabric. I think this is backwards: we should do as much as possible at the
>   end-to-end (or close to it) level so you don't have to trust the network
> fabric,
>   even as we *also* harden the network fabric.
> 
> -Ekr
> 
> However, the
> 
> 
> 
> 
> > So... No! end-to-end encryption ala TLS is not sufficient alone, or else
> > all of
> > the above would not exist. But many of the aforementioned mechanisms from
> > other
> > market segments do not fly equally well in the context of commercial use
> > cases,
> > so NASR is also for the confidentiality argument a very interesting new
> > option that
> > we as the IETF should be happy to experiment with, and maybe it will turn
> > out to be
> > a great addition to the world of security mechanisms.
> >
> >

> -- 
> nasr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]


-- 
---
[email protected]

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