[nasr] Re: Summary of Discussions So far---Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up

[Meiling Chen <[e-mail]>]

Thanks Luigi for your careful check!

Best,
Meiling
 
From: Luigi IANNONE
Date: 2025-05-20 16:01
To: Meiling Chen; Michael Richardson; Watson Ladd; [e-mail]; IETF SAAG
Subject: RE: [nasr] Summary of Discussions So far---Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up
There is a typo in the link. The right link is: https://wiki.ietf.org/en/group/nasr ;-)
 
Ciao
 
L.
 
 
From: Meiling Chen <[e-mail]> 
Sent: Tuesday, May 20, 2025 9:51 AM
To: Michael Richardson <[e-mail]>; Watson Ladd <[e-mail]>; [e-mail]; IETF SAAG <[e-mail]>
Subject: [nasr] Summary of Discussions So far---Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up
 
Hi all,
 
Thank you all for your comments to help NASR clarify technical issues!
I have reviewed all the discussion emails, and record the Q/A on WIKI, please point it out if there is anything I’ve missed.
the Q/A url: https://wiki.ietf.org/e/en/group/nasr , Welcome everyone to add questions and answers.


Q1: Why is not end-to-end protection sufficient and why should we care about where the traffic goes through?
 
Q2: Why this is important to assure at the network layer?
 
Q3: List actual concrete examples of existing regulations.
 
Q4: List the technical requirements in detail.
 
Q5: NASR being a possible way to address pervasive traffic monitoring threats?
 
Q6: Proof of transit does not imply that the packet didn’t exit the path. 
---->PoNT is out of scope. the motivation is to prove that the data packet is forwarded according to the agreed route.
 
Q7: There is work about proof of transit that has been done in SFC, what is needed to highlight what is not there (in routing, RATS, SFC PoT) which NASR will provide.
---->NASR is the joint use of attestation techncology and proof of transit.
 
Q8: What about lawful interceptions?
---->Trustworthiness as defined in RATS can attest that a router does what is supposed to do, including lawful interception if it is what it is supposed to do.
 
Q9: There is work from RATS, like RFC 9684, that can be used in NASR. Why an independent effort? Why not putting this work in an existing WG?
---->RATS is the building block to create path attestation, whose usage is then verified with proof of transit. These two things together look out of the scope of RATS. NASR does not want to replace RFC 9684, but rather leverage it.
 
Q10: What is exactly the definition of a path in NASR? BGP session? Tunnel? physical links?
---->A document in PANRG has a good definition of what a path is.
 
Q11: Trustworthiness and traffic engineering are already addressed in different places, so what is new in NASR? 
---->The possibility for the customers to verify that the traffic has been engineered in the way they asked. How to do it is the gap NASR wants to fill.
 
Q12: Candidate solutions from problems exist in other venues (Routing security / SFC)
---->True, but they do not address the combination (forwarding).
 
Q13: Proposed work may result in fragmentation of the Internet, including and excluding poeople?
---->No. That is the wrong terminology to use. NASR is about path complaint to a set of claims. Is a specific service in a limited domain not a general service for the Internet.
 
Q14: Clarification of requirements whether the requirement is to detect nodes along the path that do not support NASR?
---->No. Only have proof that traffic went through a set of nodes that support NASR.
 
Q15: Bringing the work to RATS would not work. RATS is already bloated and bringing all this work there is not possible.
 
Q16: PoT has cryptographic cost.
---->Implementation on SRv6 shows that the cost is very limited.
---->Path Tracing in SRv6 networks(https://datatracker.ietf.org/doc/draft-filsfils-ippm-path-tracing/02/), PT provides efficient, HW friendly solution,it has been designed for linerate hardware implementation in the base pipeline. And it works sufficiently for a basic POT functionality.
 
Q17: Remark about the scope of implementation: Internet or limited domain?
---->limited domain implemented at the operator level.
---->SRv6 Path Verification(https://datatracker.ietf.org/doc/draft-yang-spring-srv6-verification/), proposes a path verification mechanism for SRv6, the implementation of verification relies on enhancing HMAC.
 
Q18: Need to verify every configuration (binary / configuration files / routers) in order to determine the properties of the path?
---->This is not how remote attestation works. There is no configuration shared, the configuration is attested through trusted third party. You share hash values that attest the the property. RFC9334/ RFC9683/ RFC9684 for more detailed informations about how to evaluate and verify.
 
Q19: Why not doing this in the SFC WG?
---->Piece can be done in other WG, but from a global perspective wold be better to have a WG.
 
Q20: For reliability, what about having multiple paths? Can it be a scalability issue? 
----Yes, the attribute of multiple path is included.
 
Q21: Is it pratical to mechanically verify that a configuration is acceptable
----Yes. but not RATS and not SEC area question, OPS area question.
 
Q22: Is it possible to determine that the configuration/policy of a device is acceptable in a fashion that does not expose that configuration/policy to a counterparty
----the party allowed to receive information about the router such as the configuration must be trusted to handle that information in a required responsible fashion, but not RATS and not SEC area question, OPS area question. RFC8994 can help.
 
Q23: about device management, what is NASR doing that RANCID doesn't? Why need transit proofs if never exiting a domain?
----Traditional tools such as RANCID cannot ensure the authenticity of data provided by network devices and may be unreliable due to device tampering; For organizations that require auditing or certification, it is necessary to ensure that the system data obtained is authentic and verifiable, including the legality and security of critical data flows.
 
Q24：it is difficult/impossible to derive from the configuration a specific behavior
----Example: evaluate from config that specific traffic not derailed from a path that is easily determined from the config and operational state.
 
Q25：The semantic correlation verification between configuration and routing behavior has not been resolved yet
----Simplified routing platform, functional control, Restconf and Orchestration can solve the problem, some operators have done, and Michael is working on a PoC.
 
Best,
Meiling
 
From: Michael Richardson
Date: 2025-04-20 01:03
To: Watson Ladd; [e-mail]; IETF SAAG
Subject: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up
 
Watson Ladd <[e-mail]> wrote:
    > However, the properties being claimed are nontrivial semantic claims
    > dependent on the configuration and the software that uses this
    > configuration to route packets. There's a big gap here, and I don't
    > believe it has been solved. To the extent that NASR needs these to be
    > solved to provide certain things, it won't be able to provide them,
    > and I think that undermines a lot of the presented rationale.
 
Some router vendors, and some operational people seem to think it can be
solved.  One possible answer is that routing platforms will be *simplified*
until they can be reasoned about.  I think that there are lots of economic
reasons why they will go this way.
 
1. SRv6 is essentially replacing all sorts of specialized forwarding engines
   (MPLS, ATM, metro-ethernet, IPv4) with a single mechanism.
 
2. There may be a thousand knobs that, if turned on, might do something
   bad. (Or might be innoculous).  But, it could be, yes, hard to reason
   about their interation. Turing completeness, halting problem, etc..
   What matters if that they aren't turned on though.
 
3. RESTCONF and Orchestration means that forwarding platforms do not need to
   be directly manipulated by human operators.  Is this true across the
   entire industry today?  No.  Is it true among some operators? Yes.
 
Anyway, I'm working on a PoC.
 
--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
 
 
 
 
 
 
_______________________________________________
saag mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]