Last Call Review of draft-ietf-6man-segment-routing-header-22
review-ietf-6man-segment-routing-header-22-secdir-lc-xia-2019-08-14-00
| Request | Review of | draft-ietf-6man-segment-routing-header |
|---|---|---|
| Requested revision | No specific revision (document currently at 26) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2019-08-20 | |
| Requested | 2019-08-06 | |
| Authors | Clarence Filsfils , Darren Dukes , Stefano Previdi , John Leddy , Satoru Matsushima , Daniel Voyer | |
| Draft last updated | 2019-08-14 | |
| Completed reviews |
Secdir Last Call review of -22
by
Liang Xia
(diff)
Genart Last Call review of -22 by Roni Even (diff) Tsvart Last Call review of -22 by Dr. Joseph D. Touch (diff) Opsdir Last Call review of -22 by Will (Shucheng) LIU (diff) |
|
| Assignment | Reviewer | Liang Xia |
| State | Completed | |
| Review |
review-ietf-6man-segment-routing-header-22-secdir-lc-xia-2019-08-14
|
|
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/smmpXMczpdpRPaSEWs0v3auDH8Y | |
| Reviewed revision | 22 (document currently at 26) | |
| Result | Has Issues | |
| Completed | 2019-08-14 |
review-ietf-6man-segment-routing-header-22-secdir-lc-xia-2019-08-14-00
Some nits: 1. title of Section 4.3.2: /FIB Entry is a Local Interface/FIB Entry Is A Local Interface 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 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 4. Section 2.1.2: "Alignment requirement: 8n". What is 8n? For better readability, can you give a more clear clarification text? 5. Section 4.1: /HMAC TLV may be set according to Section 7./HMAC TLV may be set according to Section 2.1.2./? 6. Section 4.3: have a "*" before every item of "A FIB entry..." ? 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.