[saag] Re: [nasr] Re: Initial thoughts on NASR
刘鹏辉 <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
My two cents, add a little bit more... if NASR assumes that the current security foundation already exists, and its goal is to add technical descriptions of specified routing paths on top of the current security foundation, then it is suggested that the goal of NASR should be focused on the standardized definition in the red parts involved in below figure. At 2025-03-18 11:44:13, "刘鹏辉" <[email protected]> wrote: Hi, all From the previous discussion, I'm not sure if my understanding is completely correct. The key situation now is to confirm whether NASR is intended for management security or technical security? So when setting standards, the wording or goals need to be adjusted appropriately. If we discuss dependency technology too much, there will be many problems. In other words, NASR assumes that the current security foundation already exists, and its goal is to add technical descriptions of specified routing paths on top of the current security foundation？ BR, Penghui At 2025-03-18 10:28:56, "Toerless Eckert" <[email protected]> wrote: >On Tue, Mar 18, 2025 at 01:02:01AM +0000, Liuchunchi(Peter) wrote: >> Hi Eric, >> >> Yes, thank you, I believe new and sophisticated attacks/vulnerabilities are being discovered all the time. Again, we are not boiling the ocean here— NASR does not magically fix everything and promise there will be no zero-day vulnerabilities against networks once-and-for-all. That is magic, not technology. >> >> What we ARE doing is when any known vulnerabilities are discovered, fixed and becomes a security patch, NASR can show to the concerning customer that look— your defense is verifiably deployed. >> >> Does that answer your question? >> >> Best, >> Peter >> >> 发件人： Meiling Chen<[email protected]<mailto:[email protected]>> >> 收件人： ekr<[email protected]<mailto:[email protected]>>;Liuchunchi(Peter)<[email protected]<mailto:[email protected]>> >> 抄送： [email protected]<mailto:[email protected]>;IETF SAAG<[email protected]<mailto:[email protected]>> >> 主题： Re: [nasr] Re: Initial thoughts on NASR >> 时间： 2025-03-18 00:14:35 >> >> Hi Eric, >> Please see inline. >> >> >> From: Eric Rescorla<mailto:[email protected]> >> Date: 2025-03-17 23:29 >> To: Liuchunchi(Peter)<mailto:[email protected]> >> CC: [email protected]<mailto:[email protected]>; IETF SAAG<mailto:[email protected]> >> Subject: [nasr] Re: Initial thoughts on NASR >> >> >> On Sat, Mar 15, 2025 at 8:24 PM Liuchunchi(Peter) <[email protected]<mailto:[email protected]>> wrote: >> Hi Eric, >> 2. Even if we do think there are secure network elements, traffic will often run over insecure channels and so we should design our protocols as if the network was totally insecure (this is what 3552 says) > >The problem is that the RFC seems to make a lot of transport protocol >security folks think that the corollary of this principle is that the >network does not need to be secure. And even worse, some may even assume >that the end-to-end security is under any less successful hacker attacks than >the network. > >So rfc3552 is right, but the corollary is the opposite: > >- Networks need to strive equally to become more secure >- Endpoints are under more attacks than infrastructure, because it > can be easier pinpointed to the target victims. > >At least that's my belief. Which is why i am very happy as an individual with >the IETF TLS strategy because i think i am not a dedicated target of attacks. >For specific customers of network equipment products (or connected to them), >it's quite the opposite. They are easily attacks of both endpoints and network >infrastructure being used. > >Cheers > Toerless > >> -Ekr >> >> >> And (one of) the point of NASR is to prioritize use of these devices, so to achieve visibility and forwarding security. >> >> >> >> We never suggest end-to-end layer encryption is not important and/or not used (sorry for not explicitly pointing it out in the architecture, I will add it, I assume it is a necessity everywhere). We suggest for compliance/green requirements, some visibility/verification of data flow on the network layer might be necessary, and that is where NASR comes in. >> >> >> > it's not clear why >> > controlling this risk requires controlling *routing* rather than >> > controlling which middleboxes are authorized. >> >> It is about visibility of network security attributes, and verifiability of compliance to such attributes (is the actual data flow on this path with pre-agreed security attributes). >> >> Peter >> >> From: Eric Rescorla <[email protected]<mailto:[email protected]>> >> Sent: 2025年3月15日 0:40 >> To: [email protected]<mailto:[email protected]>; IETF SAAG <[email protected]<mailto:[email protected]>> >> Subject: [nasr] Initial thoughts on NASR >> >> I've had an opportunity to review the NASR documents and it's left >> with me with some concerns about scope and threat/trust model. I'd >> like to start with the motivation at the top of >> draft-liu-nasr-architecture: >> >> Path-agnostic traffic signing and encryption has been the primary >> method to ensure data confidentiality, integrity and authenticity >> today. However, with the increasing amount of attacks, and >> vulnerabilities, new emerging threats are imposing requirements that >> go beyond the data security currently provided. Vulnerable factors >> include: >> >> * Unauthorized data duplication, caused by >> >> - Routing/forwarding detour to unintended devices or areas >> >> - Insecure network devices or unauthorized root access >> >> - Middlebox decryption/inspection >> >> * Capture-now-decrypt-later attacks, caused by >> >> - Exploitation of vulnerable cryptographic engineering >> >> - Post-Quantum attacks >> >> * Pattern or behavioral analysis, etc. >> >> >> I agree that these are real threats, but it's not clear to me that the >> proposed mechanisms is the way to address them. >> >> For the moment, I'd like to talk about the client/server and >> peer-to-peer use cases that are common in IETF protocols, such as >> HTTP, POP/IMAP, WebRTC, SSH, etc. [0] As stated in the text above, the >> standard approach to securing this kind of communication is to use >> some channel security mechanism that encrypts the traffic and >> authenticates one or more of the endpoints, as with TLS, IPsec, QUIC, >> SSH, etc. The basic assumption behind the design of these protocols >> protocol needs to provide security even when the attacker completely >> controls the network (see RFC 3552 S 3). >> >> My concern reading this list is that the implicit problem argument >> seems to be that these channel security mechanisms are not providing >> the security protections that they are supposed to provide and >> so therefore we need to instead provide a trusted path *between* >> the endpoints. For instance, consider the first bullet: >> >> * Unauthorized data duplication, caused by >> >> - Routing/forwarding detour to unintended devices or areas >> >> - Insecure network devices or unauthorized root access >> >> - Middlebox decryption/inspection >> >> If our channel security protocols are doing their job, then it >> shouldn't matter if the network devices have access to the protected >> traffic because it's not useful to them. Middlebox decryption is a >> slightly different case, but -- again, assuming our protocols are >> working correctly -- middleboxes should not be able to decrypt traffic >> without the knowledge of the endpoint, so it's not clear why >> controlling this risk requires controlling *routing* rather than >> controlling which middleboxes are authorized. >> >> Similar comments apply to the remainder of this list: the way we >> intend to protect against quantum computers is to add PQC to our >> protocols; if we want to protect against behavioral analysis we need >> our protocols to resist it. >> >> This is not to say that there is not some value in preventing >> attackers from having access to encrypted traffic, but I think this >> really needs to be viewed as a defense in depth measure -- and perhaps >> as a response to some policy requirements -- rather than as a primary >> security measure as is implied in this document: to the extent to >> which our protocols are vulnerable to the listed threats, then we need >> to address that by fixing the protocols, not by hoping we can >> secure the entire network. Even if our objective was to protect all >> the links, the strongest way to do that is to encrypt the traffic, >> rather than hoping you can physically secure every device and every >> kilometer of cable, which brings us back to needing strong >> cryptographic protocols. >> >> -Ekr >> >> >> >> [0] As a nit, these protocols usually do not "sign" traffic. > >> -- >> 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]