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

[Eric C Rosen <[e-mail]>]

On to version -06 ...

On 12/23/2015 10:13 AM, Susan Hares wrote:
>
> 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).
>

The draft has the following text in section 4.4.1 ("The Extranet Source 
Extended Community"):

"The value field of the Extended Community MUST be set to zero. "

"A PE router that interprets this Extended Community MUST ignore the 
contents of the value field."

and the following text in section 4.4.2 ("Distribution of Extranet 
Source Extended Community"):

    "A Route Reflector MUST NOT add or 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).  The value of the Extended Community MUST NOT be changed by the 
route reflector."

    "When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the 
Extranet Source Extended Community from these routes.  This includes 
inter-AS options (b) and (c) (see [RFC6513] Section 10).  The value of 
the Extended Community MUST NOT be changed by the ASBRs."

It seems to me that this contains the information you have requested.  
It may not be in the format you prefer, but I think it goes beyond the 
scope of an ops-dir review (or an IESG Discuss) to demand format changes.
>
> *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).
>
The draft now contains the following text in section 4.5 ("The Extranet 
Separation Extended Community"):

"We define a new Transitive Opaque Extended Community, the "Extranet 
Separation" Extended Community (see [RFC4360], [RFC7153], and Section 9 
of this document).  This Extended Community is used only when extranet 
separation is being used. Its value field MUST be set to zero upon 
origination, MUST be ignored upon reception, and MUST be passed 
unchanged by intermediate routers.  A Route Reflector MUST NOT add or 
remove the Extranet Separation Extended Community from the routes it 
reflects, including the case where routes received via IBGP are 
reflected to EBGP peers (inter-AS option (c), see [RFC6513] Section 10)."

It seems to me that this contains the information you have requested.

> *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.
>
The Security Considerations section already contains the following text:

  "As is the case with any application of technology based upon 
[RFC4364], misconfiguration of the RTs may result in VPN security 
violations (i.e., may result in a packet being delivered to a VPN where, 
according to policy, it is not supposed to go)."

I don't think the above requested text really adds anything, it's just 
saying the same thing over again.
>
> 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.
>
The difficulty of dealing with overlapping address spaces when 
connecting two VPNs is already discussed extensively throughout the 
document.  I don't see that the requested paragraph adds anything of 
substance.