Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02

["Carlos Pignataro (cpignata)" <[e-mail]>]

Phillip,

Many thanks for your review.

As you rightly call out, this is indeed an incremental addition — I might add for emphasis a very incremental change.

One point of clarification, however, is that this solution as defined does _not_ use BGP. The relevant control protocols’ security considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' — if you follow the pointers, you will get to the control connection (endpoint and message) security as well as protection for data plane spoofing.

In re-reading the Security Considerations section (thanks again for the review), I do believe there is an area of improvement: from RFC 5885, since these PWs specify single-hop adjacencies, the document ought to specify the use of GTSM for the IP/UDP encapsulations.

I’ll be happy to add that in. Please let me know if you have any concerns with it.

Phillip, Andy, Stewart,

Lastly, Phillip, you are suggesting or recommending the development of a comprehensive security architecture (scoped for L2VPNs? or PWs? or VCCV?). Since that is clearly beyond the scope of this (incremental) doc, I’ll let Andy and Stewart (PALS chairs) answer that one.

My personal opinion as individual participant is that all the different security considerations for each architectural building block and modules (control planes, data plane, attacks, etc) are in place — perhaps not in a single document, but throughout.

Thanks!

— Carlos.


> On Apr 26, 2016, at 8:48 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> 
> This document is an incremental change to a layer 2 virtualization
> layer (Software Defined Networking). As such it properly references
> RFC5085 for security considerations.
> 
> That said, I am a bit surprised at the security considerations in
> RFC5085 which points out that denial of service is an issue but not
> the introduction of a new set of opportunities for interception. This
> is surprising given that BGP interception had already been used in
> international hostilities when the RFC was published.
> 
> Further the proposed solution is to sprinkle on some magic IPSEC dust
> or equivalent. While that might be an appropriate approach in an
> experimental protocol, it is hardly adequate for a production protocol
> with implications for Internet security as a whole.
> 
> Given the critical function of this layer and the date of its
> inception, I would expect to see a comprehensive security architecture
> developed as part of the overall scheme.