Skip to main content

Last Call Review of draft-ietf-l3vpn-as4octet-ext-community-
review-ietf-l3vpn-as4octet-ext-community-secdir-lc-kent-2009-07-18-00

Request Review of draft-ietf-l3vpn-as4octet-ext-community
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-07-07
Requested 2009-06-25
Authors Dan Tappan , Yakov Rekhter , Srihari R. Sangli
I-D last updated 2009-07-18
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-l3vpn-as4octet-ext-community by Security Area Directorate Assigned
Completed 2009-07-18
review-ietf-l3vpn-as4octet-ext-community-secdir-lc-kent-2009-07-18-00
Title: 

review of
draft-ietf-l3vpn-as4octet-ext-community-03




I 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.





Draft-ietf-l3vpn-as4octet-ext-community-03.txt is a very brief (6
page) document that defines a new type of BGP extended community, one
that can carry 32-bit AS numbers. It is a simple, logical successor to
the existing extended community structure, which is limited to
representing 16-bit AS numbers.





The Security Considerations section states that "All the security
considerations for BGP Extended Communities apply here."  This
may not be very informative for the average reader. I thought it might
be preferable to include references here to relevant Security
Considerations sections from prior RFCs dealing with this topic. So, I
looked at RFC 4360 (BGP Extended Communities Attribute), since that is
the document that is being extended to accommodate 32-bit ASNs.
However, that document has a largely vacuous security considerations
section:





"This extension to BGP has similar security implications as BGP
Communities [RFC1997].





This extension to BGP does not change the underlying security issues.
Specifically, an operator who is relying on the information carried in
BGP must have a transitive trust relationship back to the source of
the information.  Specifying the mechanism(s) to provide such a
relationship is beyond the scope of this document."





I then looked at RFC 1997, and discovered that its Security
Considerations section states:





"Security issues are not discussed in this memo."







I suggest the authors take the
time to write a meaningful Security Considerations section addressing
BGP Extended Communities, since none of the prior documents on this
topic seem to have done so.