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

[Stewart Bryant <[e-mail]>]

On 26/04/2016 13:48, Phillip Hallam-Baker 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).

I don't see how you conclude that this is anything to do with SDN, other
than noting that SDN is ONE of the control planes that might be used,
except that in the early days of this work we called it "static".

> As such it properly references
> RFC5085 for security considerations.

As others later state this is a small update to RFC5085. As such it 
should not be held
hostage to your concerns about RFC5085, which is a widely deployed protocol
with significant interoperation, at least in its MPLS variant.

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

So I am curious what would an interception attack on an OAM protocol look
like and what would harm would such an attack do? If you could simply
read the packets you could find out the loss, delay, jitter and outage rate
but I don't see why an attacker would be that interested in such data.

If you could intercept the OAM packets, I am sure that the data packets 
carried
over the same path would be far more interesting, and securing those would
secure the OAM since they fate share.

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

I really don't understand this point.

In the MPLS case we use exactly the same dataplane and exactly the same
signalling plane as is used by Internet traffic. You may have concerns 
about the
security of those aspects of the Internet, but this is not the place to 
address
those concerns. If you extend the security of MPLS, this protocol will 
inherit
those extensions.

I am not sure how widely L2TP OAM is actually deployed, but both the L2TP
control and dataplane (and the OAM fate shares with the dataplane) run
over IP, and will inherit any security enhancements that are applied to IP.

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

As I noted above, the most widely deployed version is the MPLS variant
and any concern about MPLS security needs to be addressed to the MPLS
WG. PALS will automatically pick up any MPLS security extensions.

- Stewart