Last Call Review of draft-ietf-lisp-crypto-07
review-ietf-lisp-crypto-07-secdir-lc-lonvick-2016-09-29-00
| Request | Review of | draft-ietf-lisp-crypto |
|---|---|---|
| Requested revision | No specific revision (document currently at 10) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-10-04 | |
| Requested | 2016-09-22 | |
| Authors | Dino Farinacci , Brian Weis | |
| Draft last updated | 2016-09-29 | |
| Completed reviews |
Genart Last Call review of -09
by
Pete Resnick
(diff)
Secdir Last Call review of -07 by Chris M. Lonvick (diff) Opsdir Last Call review of -07 by Susan Hares (diff) Rtgdir Early review of -06 by Danny R. McPherson (diff) |
|
| Assignment | Reviewer | Chris M. Lonvick |
| State | Completed | |
| Review |
review-ietf-lisp-crypto-07-secdir-lc-lonvick-2016-09-29
|
|
| Reviewed revision | 07 (document currently at 10) | |
| Result | Has Nits | |
| Completed | 2016-09-29 |
review-ietf-lisp-crypto-07-secdir-lc-lonvick-2016-09-29-00
Hi Dino, Brian, and All,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
The document is acceptable for an Experimental RFC.
I don't follow LISP so I'm not sure if there is an actual mechanism
for a device receiving a map request packet to decline an offered
cipher suite. If there is, I didn't see it explained in the draft.
You should address this in a future draft. This will be needed for
when new cipher suites are added and a receiving device does not
have the capability to handle the new cipher suite, or the case
where an old cipher suite has been administratively disabled; like
if it's been compromised and shouldn't be used. There are several
ways to do this.
There are a few nits in the draft you may want to take care of.
First, Section 6 talks about setting the R bit to 0.
Current:
The 'R' bit is not used for this use-case of the Security Type LCAF
but is reserved for [
LISP-DDT
] security. Therefore, the R bit is
transmitted as 0 and ignored on receipt.
Proposed:
The 'R' bit is not used for this use-case of the Security Type
LCAF but is
reserved for [
LISP-DDT
]
security. Therefore, the R bit SHOULD be transmitted
as 0 and MUST be ignored on receipt.
A few other things I found:
s/assymmetric/asymmetric/
s/Soon as an ETR or RTR/As soon as an ETR or RTR/
s/followed by key-id 2, an finally key-id 3/followed by key-id 2,
and finally key-id 3/
Best regards,
Chris