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

From: Eric C Rosen <[email-masked]>
Date: Wed, 13 Jan 2016 10:16:13 -0500

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.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Jan 2016 10:37:45 +0100

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
> The draft has the following text in section 4.4.1 ("The Extranet 
> 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."
>
>> 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
>>
> The draft now contains the following text in section 4.5 ("The 
> Extranet Separation Extended Community"):
>
> 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 
>> particularly tricky, as it intentionally cross-connects VPNs, but in 
>> a manner that is intended to be strictly limited by policy.
>>
> violations (i.e., may result in a packet being delivered to a VPN 
> where, according to policy, it is not supposed to go)."
>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 27 Jan 2016 13:35:27 -0500

On 1/27/2016 4:37 AM, Benoit Claise wrote:
> pages.
I'm afraid I don't understand this sentence.

> You know, a few summary paragraphs that indicates where this 
> potential fragility of the solution (which could be in a new 
> operational consideration section or in the security considerations.
As I've been trying to explain to Sue, I don't understand what is being 
asked for in these "few summary paragraphs".   An "operator's guide to 
provisioning extranets" would be useful, but not within the scope of 
this draft.

The security considerations section already points out that 
misconfiguration of the Route Targets may result in misdelivery of 
traffic; the above text is merely a paraphrase of material that is 
already present in the document.

Note that there is no requirement to have a separate "operational 
considerations" section.

> I don't think I've seen text around coordination to set up filter, for 
> example.
Coordination to set up filters?  I don't know what you are referring to.

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

Actually, I wrote that text in an email to Sue.  Although it too is just 
a paraphrase of existing materiaI, I could add it to the "overview" 
section as part of the description of what an extranet is.   Are you 
saying that you will lift the DISCUSS if I just add that paragraph?