Skip to main content

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