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

Toerless Eckert <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <[email protected]>
Thanks Eric,

1) Wrt. to arch doc feedback in general:

Michael just said you may want to review the use-case document more and
comment on it rather than the archtiecture, whose correct details more
likely should be considered to be an actual TBD work result than a charter
decision input (hope i am representing his point correctly, but i think
it's a good way to not obsess about it too much, as much fun this discuss
part is and how much i think i showed i agreed with you wrt. to actual decryptability
in the face of best feasible crypto in all places).

On Sat, Mar 15, 2025 at 04:45:13PM -0700, Eric Rescorla wrote:
> The traffic analysis piece is more interesting I don't disagree that
> it's helpful to encrypt at the link layer, but I'm not really
> persuaded this is the kind of real-time *attestation* problem contemplated
> by NASR; how often are people going to refuse to send traffic at all
> if it's not link-layer encrypted?


1) Think of "people" = SCION software routers at the edge of a NASR enabled domain.
They are allowed to collect NASA attestation from that network, push topology
subset or ERO to get traffi across the paths with desired security properties.
Actual deliver over non-complaint paths in this case would in good setups be
an error triggering for example SCION overlay rerouting itself over another
"underlay" / SP path.

2) Another example: In early 2000th DSL SPs offered
"Teleworker VPN" for enterprises in the USA: ATM PVC between the teleworkers home
DSL line and the enterprises headend (via higher speed ATM link). When they
overdid squeezing money from the enterprises for this service, the enterprises did change over
to IPsec VPN instead. But then the enterprise also often changed the access policy for
the teleworker to in-company data because it could not trust anymore that the teleworkers
router would be connected at a particular physical location (teleworkers registered
home address known from the L2 DSL SP service records). 

I got so annoyed about that change in policies due to loss of location trust,
that i got myself at least a patent award out of it:
https://patents.google.com/patent/US20080028225A1/en?oq=US20080028225A1

Its a kind of one-off/single-hop NSAR with location info:
Teleworker attaches his enterprise provided teleworker router
to the "whatever ISP" via a "whatever L2 link" from that ISP. Then there is a
three way exchange between Enterprise headend, "whatever ISP" L2 termination device
(e.g.: DSLAM/MSAN/... etc.) and the teleworker router. In result, the enterprise headend
for the IPsec VPN to the teleworker router would know a physical location of the
teleworker router in an authenticated way from the "whatever ISP". And could
accordingly adjust the traffic access policies for the teleworker.

Should be easy to see how this could equally be done with even minimum deployent of NASR
technologies on the edge.

Actually, i stumbled into several customers later reporting about deployments of small
access routers into various rather insecure locations (ATM, Small outdoor sales booths)
which do have access to internal enterprise data. Those routers where easily stolen on friday
evening and attackers could then get to that enterprise data over the weekend. So i think
there is a lot of possible value for those type of deployments in the NASR building
blocks.

Just an example how even partial path deployments of NASR attestation can
be used various security purposes. 

Cheers
    toerles

> 
> > 3) Performance, latency, and resilience guarantees.
> >    For instance, if I buy two redundant paths, how can I know that they
> don't
> >    share a router or fiber bundle somewhere?
> 
> This is of course a real issue, but isn't it better solved with contractual
> mechanisms?
> 
> 
> -Ekr

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