Subject: [manet] DLEP-17: Security Considerations

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 09:56:49 -0500

All,

The "Security Considerations” text isn’t really adequate.

I suspect part of the problem is editorial.  I am supplying
candidate replacement text that I believe will be sufficient
for the draft to pass the IETF Security Area review.

Background:
  In the IETF, “implement” generally refers to code available
  to execute a feature in a product, while “use” or “deploy” 
  refers to the operational decision of how to configure a product
  when installing it in an actual physical network.  

  I realize that some people (incorrectly) use “implement” to refer
  to deployment, but IETF protocol specifications generally try 
  to avoid that confusion.

  Also, unlike some other standards bodies, the IETF doesn’t have a 
  concept of “conformance testing”.  Products that claim to implement 
  an RFC are expected to implement it completely and properly, 
  but there are no IETF “protocol police” checking a product to see 
  whether each detail was done correctly.  

  Last, in the IETF, the long-standing custom is that “implementation”
  of security is mandatory, while “deployment/use” of security is
  optional.  The reasoning is that an operator best knows their own
  security risks, but if the implementation does not include the 
  specified security mechanism (e.g. TLS) then (a) the implementation 
  won’t be interoperable and/or (b) the user won’t be ABLE to deploy/use 
  the security when they deem it appropriate.

Proposed New Text for Section 11, sub-heading 1:

	1. An attacker might pretend to be a DLEP peer, either at 
           DLEP session initialization or by injection of messages 
           once a session has been established, and/or

Also, the several paragraphs that begin with “If the modem and router are”
ought to be rewritten.  Proposed New Text is:

        All DLEP implementations must also implement support for 
        IETF TLS [RFC5246], so that an operator always is able to choose 
        to deploy TLS with DLEP when the operator deems that appropriate.   

        Use of DLEP with TLS, however, might not be needed in some 
        DLEP deployments.  Additional guidance on TLS use with DLEP follows.

	When the modem and router are NOT both on the same layer-2
        link (e.g. IP subnetwork, Ethernet VLAN) then session messages
        could be altered by an off-link attacker in order to subvert the
        behavior of either or both DLEP participants.  In short,
        a man-in-the-middle attack by an off-link attacker is possible.
        In these situations, deployment and use of TLS with DLEP is 
        RECOMMENDED.

        In some deployments, for example deployments that include a
        “Layer-2 VPN” connecting different sites, there might be a 
        non-trivial risk of an on-link attacker.  Operators should 
        carefully consider the details of their deployment and their local
        operational risk model. In situations where local risks warrant, 
        then deployment and use of TLS with DLEP is RECOMMENDED.

Lastly, the final paragraph as written is not really acceptable in the 
modern IETF.  Here is Proposed New Text:

	Deployment of DLEP does not change the security risks for the
        data plane (i.e. the data packets between a router and a modem).
        In circumstances where there is non-trivial risk of an on-link
        attacker, then the use of appropriate link-layer security mechanisms 
        (e.g. IEEE MAC-layer security [IEEE 802.10, IEEE 802.1AE] for data 
        packets between a router and a modem is RECOMMENDED.

Informational References probably should add:

	[IEEE 802.1AE] IEEE, Standard for Local and Metropolitan Area Networks: 
                       Media Access Control (MAC) Security, IEEE, NJ, USA. 2006

	[IEEE 802.10]  IEEE, Standard for Local and Metropolitan Area Networks:
                       Interoperable LAN/MAN Security (SILS), IEEE, NJ, USA. 1992.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 17:18:35 +0000

Ran,

I really like your proposed changes to the Security Considerations, but 
I do have a concern.  Many major radio manufacturers consider TLS a step 
too far, and mandating it for environments where it is considered 
unnecessary will prevent uptake of DLEP.

I think we are all agreed that when there are multiple hops between 
modem and router then TLS is a MUST.  But when there is a single piece 
of wire between the devices, people will (possibly correctly) argue that 
it is pointless.

Do you have any advice on how we could add some text to your 
recommendation along the lines of:

"If you can prevent DLEP running over multiple hops in your 
implementation, then you MAY choose not to implement TLS."

How one prevents multi-hop is left as an exercise to the reader...

This is an open question to the WG as well.

Cheers,

Rick

On 24/11/15 14:57, RJ Atkinson wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 17:32:23 +0000

On 24/11/15 17:19, Rick Taylor wrote:

Ran,

>> In these situations, deployment and use of TLS with DLEP is

We assume layer-2 transparency for the data plane already with DLEP 
(Section 2, para 2).  If we assume the same layer-2 connectivity for the 
control plane, can't we remove the TLS requirement altogether?

You go on to recommend Layer-2 VPNs requiring some kind of external 
security, so I'm starting to wonder if TLS is a red herring.

Rick

---

From: "MATTY, Steven" <[email-masked]>
Date: Tue, 24 Nov 2015 17:39:58 +0000

Hi Rick et al

Is this a confusion between the terms "implement" and "use"/"deploy?".  I think Ran is saying that
all DLEP solutions MUST implement TLS support but it is not mandatory to "use" TLS (this is something
best left to the end user to decide whether to enable TLS when deploying)

For a DLEP router or DLEP radio to claim conformance to the DLEP standard it MUST provide an implementation
which allows the user to enable TLS. It just doesn't HAVE to be enabled.

Regards

Steve

>-----Original Message-----
>From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
>Sent: Tuesday, November 24, 2015 5:19 PM
>To: RJ Atkinson; MANET IETF
>Subject: Re: [manet] DLEP-17: Security Considerations
>
>Ran,
>
>> The "Security Considerations" text isn't really adequate.
>>
>>    In the IETF, "implement" generally refers to code available
>>    to execute a feature in a product, while "use" or "deploy"
>>    I realize that some people (incorrectly) use "implement" to refer
>>    Also, unlike some other standards bodies, the IETF doesn't have a
>>    concept of "conformance testing".  Products that claim to implement
>>    but there are no IETF "protocol police" checking a product to see
>>    Last, in the IETF, the long-standing custom is that "implementation"
>>    of security is mandatory, while "deployment/use" of security is
>>    won't be interoperable and/or (b) the user won't be ABLE to deploy/use
>> Also, the several paragraphs that begin with "If the modem and router are"
>>          "Layer-2 VPN" connecting different sites, there might be a
>This mail has originated outside your organization, either from an external
>partner or the Global Internet.
>Keep this in mind if you answer this message.
>

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 17:42:03 +0000

Steve,

You are right, I agree that is what Ran is saying.  However, I still 
stand by my comment that some radio vendors are pushing back against 
*implementing* TLS regardless of deployment.

Rick

---

From: "MATTY, Steven" <[email-masked]>
Date: Tue, 24 Nov 2015 17:46:40 +0000

Hi Rick

Please ignore my comment. I mis-read your comments...

Time to go home I think

Regards

Steve

>From: MATTY, Steven
>Sent: Tuesday, November 24, 2015 5:40 PM
>To: 'Rick Taylor'; RJ Atkinson; MANET IETF
>Subject: RE: [manet] DLEP-17: Security Considerations
>
>Hi Rick et al
>

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:37:48 -0500

> On 24  Nov 2015, at 12:18 , Rick Taylor <[email-masked]> wrote:
> 
> Ran,
> 

If radio manufacturers are like some router vendors, they will claim 
the DLEP RFC whether or not they implement TLS.  This is NOT good, 
but the situation is not new to the IETF.

> of wire between the devices, people will (possibly correctly) argue that 

It depends on whether one thinks that on-link attackers exist,
and whether one has various other tools (e.g. 802.1x, 802.1AE,
switch-specific features) to manage/limit such attacks.

> This is an open question to the WG as well.

We discussed this last summer and I proposed that alternative to TLS 
back then.  It did not seem to be accepted by the WG back then, 
but maybe the mood has shifted in the mean time.

The obvious way to eliminate multi-hop is to add mandatory text
for implementers.  Here is some candidate text (one will need
multiple MUST and MUST NOT statements to nail the multi-hop
box shut):

	- DLEP implementations MUST NOT support routable IP addressing
          on DLEP-capable interfaces.
	- DLEP implementations that support IPv4 MUST ALSO support
          use of IPv4 link-local unicast for DLEP-capable interfaces
          and IPv4 link-local multicast for DLEP Discovery messages
	- DLEP implementations that support IPv6 MUST ALSO support
	  the use of IPv6 link-local unicast for for DLEP-capable
          interfaces and IPv6 link-local multicast for DLEP Discovery
          messages.
	- DLEP routers MUST NOT forward packets with link-local addressing
          between interfaces within that router.

Cheers,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:42:13 -0500

> On 24  Nov 2015, at 12:32 , Rick Taylor <[email-masked]> wrote:
> 

Security is annoying.  A chain is only as strong as its weakest link.

TLS is not a red herring, because the operational experience is
that off-link attackers are widespread and commonplace.  

By contrast, many Ethernet-centric environments use a range of tools 
(e.g. 802.1x, mac address lockdown in switches, others) to keep 
unauthorized nodes from successfully connecting to a wired/cabled/optical
Ethernet link.

Any L2 VPN breaks many of the tools described in the paragraph just
above, which is why it is a separate case worth describing.

My sense is that you might be happiest with specifying DLEP
to ONLY support link-local addressing (for both IPv4 & IPv6).

I’m not sure what the WG overall thinks.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:47:14 -0500

> On 24  Nov 2015, at 12:39 , MATTY, Steven <[email-masked]> wrote:
> 
> Hi Rick et al
> 
> Is this a confusion between the terms "implement" and "use"/"deploy?”.  
> I think Ran is saying that all DLEP solutions MUST implement TLS support
> but it is not mandatory to "use" TLS (this is something best left to the end user
> to decide whether to enable TLS when deploying)
> 
> For a DLEP router or DLEP radio to claim conformance to the DLEP standard
> it MUST provide an implementation which allows the user to enable TLS.
> It just doesn't HAVE to be enabled.

s/enabled/enabled by default/

That is, use of TLS can be a user-configurable thing with any default 
setting that the implementer chooses to pick.

> Steve

Yes, that is exactly what I was trying to say (with the s// edit above).

Further, OpenSSL is freeware and has TLS code inside.  It also has a very
reasonable memory footprint.  So for a radio vendor to say TLS is too hard 
to implement seems a bit silly.  All they need to do is port a bit of no-cost 
open-source code into their radio. If their radio has SNMP, it probably
used the open-source NetSNMP code for that — so porting open-source isn’t
a new concept to radio vendors.  (Further, for vendors in a governmental
environment, some OpenSSL versions have NIST FIPS-140 approval already.)

Thanks,

Ran

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 24 Nov 2015 18:48:48 +0000

> 
> If radio manufacturers are like some router vendors, they will claim the DLEP
> RFC whether or not they implement TLS.  This is NOT good, but the situation
> is not new to the IETF.
> 

It's a sad state of affairs when the IETF is putting text into specifications that we know people will ignore (and in some cases, we'll *tell them* to ignore), but I guess that's a discussion for another thread. 

Stan

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 24 Nov 2015 18:50:36 +0000

> reasonable memory footprint.  So for a radio vendor to say TLS is too hard to
> implement seems a bit silly.  All they need to do is port a bit of no-cost open-
> source code into their radio. If their radio has SNMP, it probably used the
> open-source NetSNMP code for that — so porting open-source isn’t a new
> concept to radio vendors.  (Further, for vendors in a governmental

Just to make sure I understand - porting/implementing TLS is 'no big whoop', but IPv6 is a non-starter.... 

Stan

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 14:01:12 -0500

> On 24  Nov 2015, at 13:48 , Ratliff, Stanley <[email-masked]> wrote:
> 
> 
>> 
> It's a sad state of affairs when the IETF is putting text into specifications
> that we know people will ignore (and in some cases, we'll *tell them* to ignore),
> but I guess that's a discussion for another thread. 

Stan,

I am hard pressed to think of any IETF standards-track RFC that was FULLY
implemented to the RFC by ALL implementations.  Even bits of RFC-791 weren’t
done the way it said - by some implementers.  Very sad indeed.

I’ve been around the IETF since the late 1980s.  I’ve seen very very large 
router vendors selectively implement RFCs.  I don’t recommend it.  I did 
not do it when I was implementing IETF protocols at various employers.
It creates a lot of operational problems, some with interoperability and
others with security.  I am NOT happy about it.  However, it is real
and it is NOT new.  Even back in the 1980s, “quality of implementation” was
an important factor for operators/users to consider when deciding what
gear to purchase.

But, yes, that thread probably is for another list.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 14:06:42 -0500

> On 24  Nov 2015, at 13:50 , Ratliff, Stanley <[email-masked]> wrote:
> 
> 
> 
>> 
> Just to make sure I understand - porting/implementing TLS is 'no big whoop’,
> but IPv6 is a non-starter.... 

There are at least 2 separate issues that make TLS very much easier to port
into a small embedded system, such as a radio.

First, TLS is a library at the application layer, outside the kernel.  
IPv6 is deep inside the kernel, often touching device drivers, and 
it is pervasive inside the kernel with tentacles many places.  In theory,
all RFC-compliant IPv6 implementations also have to support IPsec.

Second, porting IPv6 as it was in 1995 would have been easier, with
a much smaller memory footprint than today.  These days, after 2nd system 
effect and all the endless tweaks to IPv6, ND alone today is probably 
bigger than all of IPv6 was in 1995.  Been there, done that.  Sigh.

Yours,

Ran