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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
