Last Call Review of draft-ietf-sidr-origin-validation-signaling-09
review-ietf-sidr-origin-validation-signaling-09-secdir-lc-kivinen-2016-11-24-00
Request | Review of | draft-ietf-sidr-origin-validation-signaling |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-12-07 | |
Requested | 2016-11-17 | |
Authors | Prodosh Mohapatra , Keyur Patel , John Scudder , David Ward , Randy Bush | |
I-D last updated | 2016-11-24 | |
Completed reviews |
Genart Last Call review of -09
by Ralph Droms
(diff)
Secdir Last Call review of -09 by Tero Kivinen (diff) Secdir Last Call review of -10 by Tero Kivinen (diff) Genart Telechat review of -10 by Ralph Droms (diff) |
|
Assignment | Reviewer | Tero Kivinen |
State | Completed | |
Request | Last Call review on draft-ietf-sidr-origin-validation-signaling by Security Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 11) | |
Result | Has issues | |
Completed | 2016-11-24 |
review-ietf-sidr-origin-validation-signaling-09-secdir-lc-kivinen-2016-11-24-00
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. This is quite short draft explaining how to transmit prefix origin validation state over BGP. Its security considerations section say: This document introduces no new security concerns beyond what is described in [RFC6811]. I think this is mostly correct, but I also think that there might be also new security considerations when you are not doing prefixi origin validation yourself, but you are trusting someone else to send you that information. I.e. you need to know whether the sender should be trusted to send that information and how the BGP information is protected from tampering (on the other hand if you trust BGP information from untrusted sources, or allow attackers to modify BGP messages, you most likely have more serious issues :-) Adding that kind of text to the security considerations section would be needed. -- kivinen at iki.fi