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

["Darren Dukes (ddukes)" <[e-mail]>]

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