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

[Stewart Bryant <[e-mail]>]

On 26/04/2016 15:51, Phillip Hallam-Baker wrote:
> Yes, I think that what is needed is IAB review of what is going on
> rather than action on this particular draft.
Sorry - what is the scope of your proposed IAB review?
> In particular, I don't consider a protocol suitable to be considered
> an IETF standard unless people can buy devices from multiple vendors
> and configure them to work together securely.

Sure, but I would like to see an evidence based assessment of the specific
problem you are seeing in the field. So far none has been brought to 
PALS (ne PWE3)
or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not
heard of a specific problem ever being raised.

If one is raised we will address it in the appropriate WG.

>
> The security approach outlined in 5085 is mix and match with a large
> dose of handwaving. It desperately needs to be reconsidered and a
> security architecture written up. I don't think that you can expect
> interoperability on the basis of that description.

If we do that, we should really do it in two halves, MPLS and L2TP. Since
PALS over MPLS runs the MPLS control and dataplane the solution needs
to be owned by MPLS. Similarly any LT2P work belongs in L2TPext.

>
> The Snowden documents demonstrate that 'well managed enterprise
> networks' are attacked on a daily basis and that this is the basis for
> mass surveillance.

Right, but I cannot see why anyone would want to mass surveil the OAM
protocol, and we inherit the security enhancements to the underlying
data and control planes.

>
> I do not consider IPSEC to be a suitable security mechanism for this
> type of system. If I was given the design brief, I would insist that
> every message be authenticated by digital signature rather than a MAC
> and the control messages logged. I might use a MAC for
> pre-authentication to prevent DoS attack on the control plane. But the
> control messages should be fixed in non repudiable fashion.

We need to examine this statement in more detail to understand which element
of the system you are concerned about. However please remember that some
elements of the dataplane and OAM are cost and time sensitive.

>
> That is the only way I could be confident that PRISM class attack
> against the network had not been performed.

That is all very well, but we do need an eco-system that is prepared to
pay for any upgrade. The place to start here is with an operator requirement
draft. Given a requirements RFC agreed by the operator community, I am
sure we will design the necessary technology to fullfill those requirements.

Stewart

>
>
> On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis <[e-mail]> wrote:
>> Phillip,
>>
>> On behalf of the PALS WG, thanks for your review.
>>
>> To be clear, this sounds like more a comment on RFC 5085 than it does a
>> comment on the draft in question. So is there any action requested regarding
>> the draft?
>>
>> Also, you many not be aware that pseudowires are almost exclusively used in
>> well-managed private enterprise services networks, usually either physically
>> or logically separated from the public Internet for reasons of both traffic
>> management and assurance to enterprise customers that their private traffic
>> is well separated from the Internet. Thus interception is less a threat than
>> it may be for protocols that are used in the public Internet.
>>
>> Thanks,
>> Andy
>>
>>
>> On Tue, 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.
>>