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

Can't help but stepping in:

	> - If you try to derail the traffic as an operator by manually hacking routing config,
	>  e.g.: sending it out an unsecure link, observe there, reinject back into path -
	>  it will fail packet-by-packet NASR attestation and the user will immediately recognize
	>  this - and could stop the traffic.

Yes, whoever or whatever causes the routing derail, the point is NASR can detect, verify and even audit this abnormality. But usually the operator do not try to derail the traffic-- they have no incentives to do so. The more usual case is management plane infiltration from an external attacker and derail the traffic away, and the operators wants to detect this incident as fast as possible. Meiling can add to that as an operator. 

	> NASR could hence ensure the whole path (e.g.: across a single SP country wide network) was such hop-by-hop protected. No single link gaps.

yes. 


-----Original Message-----
From: Toerless Eckert <[email protected]> 
Sent: 2025年3月17日 7:48
To: Stephen Farrell <[email protected]>
Cc: Meiling Chen <[email protected]>; Michael Richardson <[email protected]>; Christian Huitema <[email protected]>; IETF SAAG <[email protected]>; [email protected]
Subject: [nasr] Re: [saag] Re: Re: Initial thoughts on NASR

Stephen, *

I would definitely like to see that NASR defines exactly those attestation attributes that would allow to ensure that the target paths have exactly that hop-by-hop encryption - with specific security properties - ideally PQ and "IP-TFS" style (no pattern observability).

And getting that level of security into actual products is IMHO primarily a matter of using NIC chips with MacSec support and MacSec stuffing - although arguably that isn't so much of an issue on a hop-by-hop encryption (as you've already lost the flow header information).
Getting PQ for MacSec is IMHO a simple control plane software issue.

NASR could hence ensure the whole path (e.g.: across a single SP country wide network) was such hop-by-hop protected. No single link gaps.

Yes, the operator of routers can theoretically observe traffic or traffic patterns through the routers.

Practically speaking that is already either difficult or at least very easy to prohibit through implementation - and attest to to that property via RATS/NASR.

- If you try to derail the traffic as an operator by manually hacking routing config,
  e.g.: sending it out an unsecure link, observe there, reinject back into path -
  it will fail packet-by-packet NASR attestation and the user will immediately recognize
  this - and could stop the traffic.

- If you hope to be able to create a packet copy in the router towards some observation
  interface, the operator accessible options for that typically are called "SPAN", and
  only available on some routers - and of course a key part of a NASR feature would be
  to prohibit configuration of such SPAN feature for any traffic with NASR header - and
  attest to that property as well.


Cheers
    Toerless

On Sun, Mar 16, 2025 at 01:17:03PM +0000, Stephen Farrell wrote:
> 
> 
> On 16/03/2025 04:01, Meiling Chen wrote:
> > [Meiling] Indeed, ciphertext can appear elsewhere and be recorded, 
> > but I think the ciphertext being known by N people is different from 
> > being known by one person, right? Which type of risk is higher is 
> > obvious.
> 
> As I understand the NASR proposal, it's still N: if the PQ protection 
> is applied at some hops/layer(s) below the classic encryption, then 
> all of the relevant hops see the classic ciphertext, as well anyone 
> with visibility at a "gap" between lower layer PQ-capable entities.
> 
> This mechanism as a mitigation of record-now-decrypt-later is bogus.
> 
> S




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


-- 
---
[email protected]

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