Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

["Susan Hares" <[e-mail]>]

Alvaro: 

 

There were two  portions to my comment:  Deployment considerations and
easily found BGP-Community definitions.  The text fits 95% of my desired
work.  I have two small suggested changes in each category.   I have
included these below.  I can live with either of these suggested changes
being rejected. 

 

I asked John Scudder (my IDR Co-chair) regarding the textural flow in this
document.   John seems to follow Eric’s writing style with ease.  You might
want to pass the textual change for deployments I suggested below by John as
well as Thomas and Martin.   It may also be useful for to have John Scudder
read through the text to make sure we have not damaged Eric’s flow and
style.    

 

===========

Deployment considerations: 

 

The text reads a bit harsh now in the "VPN security violations", and may I
suggest the following addition in 

Paragraph 12.  

 

/Old We use the term "VPN security violation" to refer to any situation in

which a packet is delivered to a particular VPN, even though, by

policy, it should not be delivered to that VPN.

/

 

New 

/We use the term "VPN security violation" to refer to any situation in

which a packet is delivered to a particular VPN, even though, by

policy, it should not be delivered to that VPN.

 

A bit of context on VPN technology may put the 

"VPN security violation" in context.  Any application 

of the technology based on  [RFC4364] requires 

that an operator pay special 

attention to configurations of RTs,

any manual configuration of VRFs, and the 

intended data paths. 

Please see the section 9 on security 

considerations for additional details.  

/

 

Clearly Distinguishable BGP Communities: 

 

Could I suggest just one white space changes to version 7 for the BGP
Aspect?  

 

Section 4.4.1 

 

Old/

  To facilitate this, we define a new Transitive Opaque Extended

   Community (see [RFC4360], [RFC7153], and Section 9 of this document)

   the "Extranet Source" Extended Community.  When a CE router

   advertises (via BGP) a route to a PE router, and the AFI/SAFI of the

   route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source

   Extended Community MAY be attached to the route.  The value field of

   the Extended Community MUST be set to zero.  By placing this Extended

   Community on a particular route, a CE router indicates to a PE router

   that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied

  to that route.  That is, the CE router may use this Extended

   Community to indicate to the PE router that a particular route is to

   be treated as a route that matches the address of an extranet source,

   and exported accordingly to other VPNs.  A PE router that interprets

   this Extended Community MUST ignore the contents of the value field.

/

New/ 

  To facilitate this, we define a new Transitive Opaque Extended

   Community (see [RFC4360], [RFC7153], and Section 9 of this document)

   the "Extranet Source" Extended Community.  When a CE router

   advertises (via BGP) a route to a PE router, and the AFI/SAFI of the

   route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source

   Extended Community MAY be attached to the route.  The value field of

   the Extended Community MUST be set to zero. 

 

   By placing this Extended Community on a particular route, a CE router
indicates to a PE router

   that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied

   to that route.  That is, the CE router may use this Extended

   Community to indicate to the PE router that a particular route is to

   be treated as a route that matches the address of an extranet source,

   and exported accordingly to other VPNs.  A PE router that interprets

   this Extended Community MUST ignore the contents of the value field.

/

 

This add white-space with textual change, but a spacing helps the person
easily see the definition of the extended community. 

 

Sue 

 

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[e-mail]] 
Sent: Thursday, April 21, 2016 5:28 PM
To: Susan Hares; Benoit Claise (bclaise); [e-mail]
Cc: 'Eric C Rosen'; [e-mail]; 'John G.
Scudder'; [e-mail]; [e-mail]; Martin Vigoureux; 'The IESG'
Subject: Re: [bess] Benoit Claise's Discuss on
draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

 

Sue:

 

Hi!  Can you please take a look at this?

 

Thanks!

 

Alvaro.

 

On 4/12/16, 3:29 PM, "Martin Vigoureux" <
<mailto:[e-mail]> [e-mail]> wrote:

 

>Dear all,

> 

>we took the opportunity of this IETF meeting to discuss with Sue, Joel 

>and Benoit, and with Eric.

> 

>Sue has had two requests:

>1/ to add some text clarifying the encoding and processing of the 

>Extended Communities this document is defining.

>Eric had already integrated this text in the document (v06) and more 

>specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended

>Community) and 4.5 (for the Extranet Separation Extended Community). 

>The text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the
split.

> 

>We have reviewed that with Sue and my understanding of our discussion 

>is that this is acceptable.

> 

>2/ to add some text covering risks of mis-configurations Eric has added 

>the paragraph quite soon in the document (the Overview section), such 

>that the reader is aware. Following Thomas' suggestion to enhance that 

>text with other cases of incorrect configurations, Eric has also added 

>some text to the Security Considerations section.

>Since the document describes a tool-set, rather than trying to describe 

>all the possible usages of these tools, the preferred approach was to 

>give a form of warning on risks of misconf.

> 

>Our understanding is that the addition of this paragraph would meet 

>Sue's expectations.

> 

>Version 07, which incorporates the above, is available.

> 

>Sue, please review the changes and let us know if our understanding is 

>correct or not, and thus if you consider your points addressed.

> 

>Thank you all

> 

>Best regards,

>Martin & Thomas

> 

>Le 23/12/2015 16:13, Susan Hares a écrit :

>> Eric:

>> 

>> *To clear my objection to this draft*, please add these sections to make

>> it clear what the content of the BGP values and their handling.    We

>> disagree on what the BGP registry document states, but that point is 

>> not worth holding up this document.  People can find the type and 

>> sub-type fields in the registry.  What is not in the registry is a 

>> clear description of the restrictions of the value field and handling.

>> 

>> Placing the BGP Extended communities within the rest of the rules is 

>> just unclear. Please put these two sections in and give the details 

>> in this sections.

>> 

>> As to the deployment section, you did not consider the text I offer  

>>below and the suggested insertion in the security section.  Perhaps 

>>you  can consider that text in your next email.  On whether this 

>>deployment  section is ³DISCUSS² worthy, I am still communicating with 

>>Benoit and Joel.

>> 

>> I wish you the peace and joy of the Christmas season,

>> 

>> Sue Hares

>> 

>> =============

>> 

>> Sections which must be added to clear my concerns

>> 

>> ----------------------------------------------------------------

>> 

>> *4.4.1 Extranet Source Extended Community *

>> 

>>     To facilitate this, we define a new Transitive Opaque Extended 

>> Community, the "Extranet Source" Extended Community.

>> 

>>     The value field of this extended community is all zeros.

>> 

>> *Restrictions: *This value field MUST be set  to zero upon origination,

>>   MUST be ignored upon reception and MUST  be passed unchanged by 

>> intermediate routers.

>> 

>> *Additional Restrictions: *A Route Reflector MUST NOT add/remove the 

>> Extranet Source Extended  Community from the VPN-IP routes reflected 

>> by the Route Reflector,  including the case where VPN-IP routes 

>> received via IBGP are reflected to EBGP peers (inter-AS option (c), see

>> [RFC6513]   Section 10).

>> 

>> *4.4.2 Extranet Separation Extended community *

>> 

>> **

>> 

>> We define a new Transitive Opaque Extended Community, the "Extranet 

>> Separation" Extended Community.  This Extended Community is used only 

>> when extranet separation is being used.

>> 

>> *Restrictions:*  Its value field MUST be set to zero upon 

>> origination, MUST be ignored upon reception, and MUST be

>> 

>>     passed unchanged by intermediate routers.

>> 

>> *  Restrictions on Adding/deleting this community:*  ??  (Eric ­ 

>> please add something here).

>> 

>> *Comments that could be put in a Security section: *

>> 

>> **

>> 

>> Whenever a VPN is provisioned, there is a risk that provisioning 

>> errors will result in an unintended cross-connection of VPNs, which 

>> would create a security problem for the customers.  Extranet can be 

>> particularly tricky, as it intentionally cross-connects VPNs, but in 

>> a manner that is intended to be strictly limited by policy.  If one 

>> is connecting two VPNs that have overlapping address spaces, one has 

>> to be sure that the inter-VPN traffic isn't to/from the part of the 

>> address space that is in the overlap.  The draft discusses a lot of 

>> the corner cases, and a lot of the scenarios in which things can go
wrong.

>> 

>> *From:*BESS [ <mailto:[e-mail]>
mailto:[e-mail]] *On Behalf Of *Eric C 

>> Rosen

>> *Sent:* Tuesday, December 22, 2015 2:08 PM

>> *To:* Susan Hares; 'Benoit Claise'; 'The IESG'

>> *Cc:*  <mailto:[e-mail]>
[e-mail]; 'John G. Scudder'; 

>>  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail]; 

>>  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail]

>> *Subject:* Re: [bess] Benoit Claise's Discuss on

>> draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

>> 

>> On 12/22/2015 12:51 PM, Susan Hares wrote:

>> 

>> Eric:

>> 

>> Thank you for revisions in version -05 of your document.  

>> Unfortunately it does not resolve either of the two points I raised.

>> 

>> 1)*On the BGP Extended Communities*, I feel your specification is 

>> *unclear and warrants change on the DISCUSS* Criteria due to 

>> interoperability issues.

>> 

>> 

>> I've explained why I don't think this is correct.  In particular, I  

>>don't think it is wise to mention the value of the "Transitive Opaque  

>>Extended Community Type" codepoint, as this can be found in the IANA  

>>registry for Transitive Extended Community types, and implementers  

>>should really be encouraged to consult the registries for the 

>>codepoints.

>> 

>> 

>> 2)I¹ve given you 2 small sections to add to your document at the 

>> beginning of section 4.4. to resolve this DISCUSS point.

>> 

>> 

>> Note that the codepoint you mention for Transitive Opaque Extended 

>> Community Type is not correct.  Unnecessary last minute changes do 

>> tend to introduce errors.

>> 

>> 

>> 3)You need to just fill in one part below on RR restrictions for 

>> *Extranet Separation Extended community*.

>> 

>> 

>> I will add some text saying that RRs must not add or remove this EC.

>> 

>> 

>> 2) *On the deployment section:*  I given text and examples ­ but I 

>> think you still misunderstand what I am looking for.

>> 

>> 

>> Perhaps.

>> 

>> 

>> Since you are an author of academic papers,

>> 

>> 

>> I am not.

>> 

>> 

>> consider I am looking for an operator-based ³abstract² that focuses 

>> the reader on the key points.I am sure you can create one for this 

>> document, but I not clear why you object to it the concept.

>> 

>> 

>> It seems to me that you are asking for something that could be titled 

>> "An Operator's Guide to Provisioning Extranet MVPN".  While that 

>> might be useful, it is not within the scope of the current document.  

>> As I've said, I am not aware of any IETF requirement that requires 

>> such a thing to be included.

>> 

>> 

>> will you please let me know that you have read my suggested text 

>> insertions on both these topics.

>> 

>> 

>> I have.

>> 

>> 

>> 

>> 

>> 

>> 

>>