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

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Apr 2016 08:48:09 -0400

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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 26 Apr 2016 10:18:28 -0400

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 <[email-masked]
> wrote:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Apr 2016 14:26:40 +0000

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 <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Apr 2016 10:51:24 -0400

Yes, I think that what is needed is IAB review of what is going on
rather than action on this particular draft.

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.

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.

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

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.

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

On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis <[email-masked]> wrote:
> comment on the draft in question. So is there any action requested regarding
> the draft?
>
> 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
> <[email-masked]> wrote:
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Apr 2016 10:57:21 -0400

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

With respect, I disagree.

A collection of pointers to a dozen other documents is not a security
architecture.

I am aware that this is not BGP which is a layer 3 switching protocol.
This is layer 2 but the same security concerns apply. The fact that we
have seen nation state actors use BGP injection attacks as tools of
war demonstrate that this is a real concern.

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

For an infrastructure of this scale, the security architecture should
really be described in a separate document and at length.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Apr 2016 21:27:42 +0000

Phillip,

> rather than action on this particular draft.

OK. Thanks.

> On Apr 26, 2016, at 10:51 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> security architecture written up.

To add further context, RFC 5085 describes, at a high level, OAM for PWs. To understand your point, do you mean there’s a need for a security architecture for OAM for PWs? Some of your comments are generic (see below for an example), and somewhat hard for me to parse if you mean the infrastructure itself, the PWs, the L2VPNs, the OAM on top, or something else.

>  I don't think that you can expect

https://tools.ietf.org/html/rfc7079 <https://tools.ietf.org/html/rfc7079>

(I’ve not contributed to that RFC, but seems to imply the only interop hiccup has been the optional CW with Ethernet PWs, not OAM)

> against the network had not been performed.

This exemplifies my earlier point: “against the network” seems quite generic. You have control message exchange without RFC 5085 and without this draft.

Thanks!

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Apr 2016 21:32:51 +0000

Phillip,

Please find below one follow-up, the rest of the message snipped out for clarity

> On Apr 26, 2016, at 10:57 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

I understand what you write, but you are answering a different question.

> rather than action on this particular draft.

Here, I was only asking if you have concerns with one specific improvement that we can add to the Security Considerations of this document.

Thanks!

— Carlos.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Apr 2016 09:59:57 +0100

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

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.

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

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

> 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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Apr 2016 10:31:45 +0100

> rather than action on this particular draft.
Sorry - what is the scope of your proposed IAB review?
> 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.

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

> networks' are attacked on a daily basis and that this is the basis for

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.

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

> 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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Apr 2016 10:44:54 +0100

> I am aware that this is not BGP which is a layer 3 switching protocol.
I don't think anyone would describe BGP as a layer 3 switching protocol!

It exchanges reachability information, it does not switch packets.

> war demonstrate that this is a real concern.

I think you need to explain the attack scenario you have in mind.
> really be described in a separate document and at length.

Let's start with the MPLS variant. What do you think needs to be added 
to RFC5920, and what of that is explicit to PALS?

- Stewart

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Apr 2016 15:37:30 -0400

On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant <[email-masked]>
wrote:

> problem you are seeing in the field. So far none has been brought to PALS
> (ne PWE3)

The point of security considerations is that the onus is on the developers
to show that the system is secure.

The documents I have read don't describe a coherent security architecture.
It seems to me that the security of the MPLS/SDN etc world is something
that hasn't really received the consideration it needs.

A few years back we suddenly realized that BGP had no security model and
desperately needed one. The whole point of security considerations was to
try to avoid situations like that occurring. It seems we have done the same
thing in this space.

The other issue is that security people probably should be looking at layer
2 security because that is the only way to achieve protection against
certain mass surveillance attacks. It is a potential tool that has been
overlooked.

data and control planes.

The type of attack that would be of concern would be injecting messages
into the control plane to affect movement of packets. There are games that
can be played just by manipulating quality of service.

> elements of the dataplane and OAM are cost and time sensitive.

I am mostly interested in security of the control plane messages. Though it
might well be useful to consider the possibility of using these
infrastructures as a possible platform for building traffic analysis
resistant networks.

I just did and I am right. The layer at which BGP data moves is pretty much
irrelevant to me. It could move out of band on carrier pigeon for all I
care. BGP is supplying the information that directs packets at layer 3.
Hence it is best viewed as a support protocol for layer 3.

The ISO layered model isn't very helpful because it directs attention to
how packets move. Once you start on virtual links and quality of service,
you end up with nested stacks if you try to maintain 'layering'.

This document has the title 'psuedowire' in the title. The protocol it is
describing creates a capability that has link-like nature. Therefore from a
security perspective we are talking layer 2 even if you build this on layer
3.

At that layer I am interested in service and traffic analysis attacks.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 Apr 2016 21:29:54 +0000

Phillip,

It might be useful to updated the Subject line for the rest of the discussion.

Trying to focus the conversation on the current Subject, I am leaving the relevant sentence, and inserting a comment at the end.

> On Apr 28, 2016, at 3:37 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> This document has the title 'psuedowire' in the title. The protocol it is describing creates a capability that has link-like nature.

This document, draft-ietf-pals-seamless-vccv-02, does not have “psuedowire” (nor “pseudowire”) in the title, and does not describe a protocol that creates a capability that has a link-like nature.

For reference:

CPIGNATA-M-H03V:seamless-vccv cpignata$ tail -n +12 draft-ietf-pals-seamless-vccv-02.txt | head
                         Seamless BFD for VCCV
                    draft-ietf-pals-seamless-vccv-02

Abstract

   This document extends the procedures and Connectivity Verification
   (CV) types already defined for Bidirectional Forwarding Detection
   (BFD) for Virtual Circuit Connectivity Verification (VCCV) to define
   Seamless BFD (S-BFD) for VCCV.  This document updates RFC 5885,
   extending the CV Values and the Capability Selection.
CPIGNATA-M-H03V:seamless-vccv cpignata$

Thanks,

— Carlos.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Apr 2016 10:19:50 +0100

I think we need to wind this discussion way back.

MPLS and PW (which can run over IP and well as a MPLS) are widely deployed
technologies. When running over MPLS PW inherits the MPLS security model.

If you think that MPLS needs to extend RFC5920, then that is a much bigger
discussion and one that you need take to the MPLS WG.

When using an IP transport, the security model belongs to the L2TPext WG
and that is a discussion you need to take to that WG.

This draft is a tiny extension to RFC5085, and I cannot see that it 
degrades the
security of RFC5085. As such we should note your points and move on.

The right way forward here is to take your concerns about the security
of pseudowires to the PALS, MPLS and L2TPext WGs as a wider concern and
not to hang them on this text.

Stewart

On 28/04/2016 20:37, Phillip Hallam-Baker wrote:
> On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     problem you are seeing in the field. So far none has been brought
>     to PALS (ne PWE3)
> The point of security considerations is that the onus is on the 
> developers to show that the system is secure.
>
> The documents I have read don't describe a coherent security 
> architecture. It seems to me that the security of the MPLS/SDN etc 
> world is something that hasn't really received the consideration it needs.
>
> A few years back we suddenly realized that BGP had no security model 
> and desperately needed one. The whole point of security considerations 
> was to try to avoid situations like that occurring. It seems we have 
> done the same thing in this space.
>
> The other issue is that security people probably should be looking at 
> layer 2 security because that is the only way to achieve protection 
> against certain mass surveillance attacks. It is a potential tool that 
> has been overlooked.
>
>
> The type of attack that would be of concern would be injecting 
> messages into the control plane to affect movement of packets. There 
> are games that can be played just by manipulating quality of service.
>
> I am mostly interested in security of the control plane messages. 
> Though it might well be useful to consider the possibility of using 
> these infrastructures as a possible platform for building traffic 
> analysis resistant networks.
>
>
> I just did and I am right. The layer at which BGP data moves is pretty 
> much irrelevant to me. It could move out of band on carrier pigeon for 
> all I care. BGP is supplying the information that directs packets at 
> layer 3. Hence it is best viewed as a support protocol for layer 3.
>
> The ISO layered model isn't very helpful because it directs attention 
> to how packets move. Once you start on virtual links and quality of 
> service, you end up with nested stacks if you try to maintain 'layering'.
>
> This document has the title 'psuedowire' in the title. The protocol it 
> is describing creates a capability that has link-like nature. 
> Therefore from a security perspective we are talking layer 2 even if 
> you build this on layer 3.
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2016 10:36:44 +0100

Hi all,

> I think we need to wind this discussion way back.

I agree. I see a couple of things happening in this
discussion that have happened before and will happen
again:

1) a secdir reviewer finds very little in the way of
security mechanism specified for important routing
protocols when trying to understand some minor update
to something

2) the reviewer comments on that saying: "hey, this
whole thing is pretty insecure looking, what's up?
e.g. you could do <badthing-n> here."

3) authors/chairs/WG participants say "it's ok, these
are well managed networks, if you can do <badthing-n>
then there are much worse things you could do" and
maybe over-react a bit as well, fearing that some
security mafia are going to try force them to pretend
to add crypto to loads of stuff

4) n++; goto 2 (a few times;-)

I'm not sure how we break that cycle to be honest,
at least not for we==IETF participants.

I doubt it's likely that we can ensure that secdir
reviewers are all familiar with MPLS, PW, etc etc.
I equally doubt that routing folks will (for both good
and perhaps less good reasons) define, implement
and deploy the kind of security mechanisms that'd
be needed to avoid secdir reviewers being surprised.

I suspect what'll eventually happen is that outside
the IETF context, routing folks and/or their customers
will decide that boundary security is just no longer
good enough by itself and will end up having to do a
load of work to address that. And some bits of that
work will end up being IETF stuff. (One would hope
that all the SDN and similar bits of work are going
to head down that path and not try to depend just on
boundary security for example.)

In the meantime, I think we just repeat the above
loop now and then.

Cheers,
S.