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
