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

[Benoit Claise <[e-mail]>]

Thank you Sue for your review and your follow-up, and even proposing 
some new text. Much appreciated.

Authors, this is an example of a very dense document. I understand that 
the MPLS VPN + BGP + Multicast can get complex, but it's difficult to 
extract the deployment considerations out of these 60 pages.
There are some operational paragraph from time to time.

I agree with Sue when she mentions: "The whole draft is a set of rules 
for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves 
in the case of an intra net.  Unless these rules are followed exactly, 
traffic may flow into a VPN it is not suppose to."
This document doesn't give an operator “so-what” for deployment in 60 
pages. You know, a few summary paragraphs that indicates where this 
specification is useful and where it is not for operators, and the 
potential fragility of the solution (which could be in a new operational 
consideration section or in the security considerations. I don't think 
I've seen text around coordination to set up filter, for example.

Sue has been trying to be helpful and even proposed some text:

    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.


Regards, Benoit
> 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.
>