Hi Darren, Thanks for the response. No more issues from my side. B.R. Frank -----邮件原件----- 发件人: Darren Dukes (ddukes) [mailto:ddukes@xxxxxxxxx] 发送时间: 2019年8月21日 23:35 收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@xxxxxxxxxx> 抄送: secdir@xxxxxxxx; draft-ietf-6man-segment-routing-header.all@xxxxxxxx; ipv6@xxxxxxxx; ietf@xxxxxxxx 主题: Re: Secdir last call review of draft-ietf-6man-segment-routing-header-22 Thank you for the review. Please see inline. > On Aug 14, 2019, at 11:39 PM, Liang Xia via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Liang Xia > Review result: Has Issues > > Some nits: > 1. title of Section 4.3.2: /FIB Entry is a Local Interface/FIB Entry > Is A Local Interface OK > 2. title of Section 5.2: /SR Domain as a single system with delegation > among components/SR Domain as A Single System with Delegation among > Components OK > 3. Section 2.1.1: /There are two types of padding TLVs, pad1 and padN, > the following applies to both/There are two types of Padding TLVs, > pad1 and padN, the following applies to both Ack, we’ll use Padding TLV capitalized as a name. > 4. Section 2.1.2: "Alignment > requirement: 8n". What is 8n? For better readability, can you give a > more clear clarification text? Section 2.1 describes what an alignment requirement is and how it is documented, referencing RFC8200. "All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per [RFC8200]. The SR Source nodes use the xn+y alignment requirements of TLVs and padding TLVs when constructing an SRH.” Does this address your concern? > 5. Section 4.1: /HMAC TLV may be set according to Section 7./HMAC TLV > may be set according to Section 2.1.2./? Thanks, I’ve fixed the XML xref for the next revision. > 6. Section 4.3: have a "*" > before every item of "A FIB entry…” > ? > Sure, I expect that would make it more obvious they are individual line items. > 1 issue: > The Security Considerations Section mainly clarifies the security > protection based on the strict SR Domain boundary protection paradigm, > and the considerations of some identified attacks. They are valuable, > but maybe not complete in scope. I noticed 2 SR related security > consideration drafts > (draft-perkins-sr-security-00 and > draft-li-spring-srv6-security-consideration-00), which are trying to > summarize all the possible vulnerabilities in SR network. I personally > suggests the authors to review them and consider how to reference or > incorporate the valuable considerations from them. Thank you for this suggestion, I’ve analyzed both the referenced documents: draft-li-spring-srv6-security-consideration-01 concludes that there is no packet falsification, identity spoofing, packet replay, DOS/DDOS threat within an SR Domain. It defines a security design following that documented in draft-ietf-6man-segment-routing-header-22. I see nothing to add from this draft. draft-perkins-sr-security-00 discusses a set of deployment scenarios, and SIDs that are not documented in draft-ietf-6man-segment-routing-header-22, and are therefore out of scope for draft-ietf-6man-segment-routing-header to consider. However the discussions started with draft-perkins-sr-security-00 should continue in the context of the SPRING WG, as per its charter, for the technologies and documents it produces using the SRH. Would this address your concern? Darren
