On 12/17/2015 8:47 PM, Kathleen Moriarty wrote:
I just have one question/request to improve the security consideration
section. The only security mentioned in this draft is what's called a
"security violation", where traffic may go to the incorrect "VPN"
endpoint. If you are worried about traffic winding up in the wrong
place, why is there no consideration for observing this traffic on the
wire? Since there is no encryption, wouldn't this also be a security
consideration to call out specifically?
Mention of the possibility of active attacks that could alter or tamper
with the traffic or passive attacks that could observe the traffic as a
risk due to lack of encryption (confidentiality protection) would help or
a reason why this doesn't matter.
The reason I didn't mention this in the Security Considerations section
is that the issues are not specific to Extranet MVPN, which is the topic
of this document. The Security Considerations section mentions those
issues that could result in misdelivery of traffic if the procedures of
the document are not properly executed; this set of issues is certainly
within the scope of the document.
I understand that there are issues having to do with the possibility of
observing or altering the traffic on the wire. Certainly I could
mention that the procedures of this document do not provide encryption,
and hence do not by themselves ensure the privacy/integrity of the data
against attacks on the backbone network. Would that be sufficient?
I don't want to make any specific recommendations for mitigating those
attacks, because:
- Issues of how to provide privacy/integrity for multicast traffic in
general would seem to be out of scope for this document;
- Issues of how to provide privacy/integrity for various
tunneling/encapsulation methods would seem to be out of scope for this
document;
- Issues of how to provide privacy/integrity for the base L3VPN
technology would seem to be out of scope for this document;
- Issues of how a Service Provider can protect its backbone network
against various attacks would also seem to be out of scope for this
document.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
