Subject: [bess] Stephen Farrell's No Objection on draft-ietf-l3vpn-acceptown-community-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 Feb 2015 06:48:20 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-l3vpn-acceptown-community-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 6: I think I buy the argument that there are no
new security issues here but that's only true I think if the
security issues with route reflectors are somewhere (and if
those cover cases where crypto is not used to enforce the
"P" in VPN). Wouldn't a reference to something like that be
good here?

- I like non-informative appendices:-)

---

From: Thomas Morin <[email-masked]>
Date: Wed, 04 Feb 2015 13:40:29 +0100

Hi Stephen, all,

> "P" in VPN). Wouldn't a reference to something like that be

RFC4456, which specifies BGP route reflection has a security section 
which merely states that it "does not change the underlying security 
issues inherent in the existing IBGP", but which can be referenced 
nonetheless.

OLD:

    No new fundamental
    security issues are introduced by ACCEPT_OWN.

proposed NEW:

      No new fundamental security issues are introduced by ACCEPT_OWN, 
beyond what is
      already documented in "Security Considerations" sections of 
RFC4271 and RFC4456.

Best,

-Thomas, as doc shepherd