[secdir] 答复: Secdir last call review of draft-ietf-6man-segment-routing-header-22

["Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]>]

Hi Darren,
Thanks for the response.
No more issues from my side.

B.R.
Frank

-----邮件原件-----
发件人: Darren Dukes (ddukes) [mailto:[e-mail]] 
发送时间: 2019年8月21日 23:35
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: 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 <[e-mail]> 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