Subject: Re: [manet] DLEP-18 Security Considerations

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sat, 6 Feb 2016 22:22:30 +0000

On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Stan:

Hi!

You'll need references for L2 security.

The main problem I see with the text below is that it is based on assumptions - even though you do say that "DLEP is restricted to...a single (possibly logical) hop at layer 2", it is based on the deployment assumptions.  What happens if it isn't deployed that way?

What about confidentiality of the data?  What about exposing information about users (privacy)?  I know that the assumed deployment model makes it very hard to look at the data in flight between and the physical and L2 security may well be enough.  However, what if DLEP is not used as expected?

IMO, you should describe the expected operating environment (or point to the assumptions) and any security mechanisms that should be included there (L2, physical assumptions), and explain why confidentiality and privacy are not a concern...but then you should also say something like: "if DLEP is used in an environment other then the expected one, then xx, yy and zz MUST/SHOULD be implemented".   I think that this way we would be covering the normal case, but also providing an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.

Alvaro.

Hello WG,

As requested in the email thread earlier today, here's a snapshot of what we currently have in the upcoming DLEP-18 draft wrt security. We've put an additional paragraph in the Assumptions section (Sec. 2.1) that says:

   The reliance on MAC addresses by DLEP forces the assumption that
   participating DLEP peers are on a single segment (either physical or
   logically, via tunneling protocols) at Layer 2.  DLEP further assumes
   that security of the implementations (e.g., authentication of
   stations, encryption of traffic, or both) is dealt with by by
   utilizing Layer 2 security techniques.

Additionally, here is the text in the "Security Considerations":

12.  Security Considerations

   The potential security concerns when using DLEP are:

   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

   2.  DLEP data items could be altered by an attacker, causing the
       receiving implementation to inappropriately alter its information
       base concerning network status.

   Since DLEP is restricted to operation over a single (possibly
   logical) hop at layer 2, implementations requiring authentication
   and/or encryption of traffic MUST take steps to secure the Layer 2
   link.

   To avoid potential denial of service attack, it is RECOMMENDED that
   implementations using the Peer Discovery mechanism maintain an
   information base of hosts that persistently fail Session
   Initialization having provided an acceptable Discovery signal, and
   ignore Peer Discovery signals from such hosts.

   This specification does not address security of the data plane, as it
   (the data plane) is not affected, and standard security procedures
   can be employed.

Thoughts? Suggestions?

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 6 Feb 2016 18:18:46 -0500

Alvaro,

On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> Stan:
>
> Hi!
>

OK. Do you have any in mind?

>
> The main problem I see with the text below is that it is based on
> assumptions — even though you do say that "DLEP is restricted to…a single
> (possibly logical) hop at layer 2", it is based on the deployment
> assumptions.  What happens if it isn't deployed that way?
>

> What about confidentiality of the data?  What about exposing information
> about users (privacy)?  I know that the assumed deployment model makes it
> very hard to look at the data in flight between and the physical and L2
> security may well be enough.  However, what if DLEP is not used as expected?
>

I'm confused. We tried to state the DLEP only works over 1 hop. Reliance on
MAC addresses forces that. If DLEP isn't used as expected, why would anyone
think it would work as expected? Or be secure? A requirement to document
use cases outside the document seems to me like a never-ending task - after
all, "we don't know what we don't know". We could sit & think about
"perverse implementations" almost forever. At the end of the day, if DLEP
is not used as expected, all bets are off.

Having said that, would the addition of text stating "Using DLEP with
multiple network hops between router and modem is out of scope of this
document, and results are unpredictable" serve to address your comment?

Regards,
Stan

>
> IMO, you should describe the expected operating environment (or point to
> the assumptions) and any security mechanisms that should be included there
> (L2, physical assumptions), and explain why confidentiality and privacy are
> not a concern…but then you should also say something like: "if DLEP is used
> in an environment other then the expected one, then xx, yy and zz
> MUST/SHOULD be implemented".   I think that this way we would be covering
> the normal case, but also providing an answer to what if without making
> mandatory mechanisms that may be superfluous.
>
> My 2c.
>
> Alvaro.
>
>
>
> Hello WG,
>
> As requested in the email thread earlier today, here's a snapshot of what
> we currently have in the upcoming DLEP-18 draft wrt security. We've put an
> additional paragraph in the Assumptions section (Sec. 2.1) that says:
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 7 Feb 2016 00:28:15 +0000

On 2/6/16, 3:18 PM, "Stan Ratliff" <[email-masked]<mailto:[email-masked]>> wrote:

Stan:

Hi!

I'm mostly acting as the Devil's Advocate..

Alvaro,

On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Stan:

Hi!

No, you're the ones writing the spec. ;-)

Seriously…  If you write "MUST take steps to secure the Layer 2", then I really hope you (authors, WG, etc.) have specifics in mind. That question will come up.

The main problem I see with the text below is that it is based on assumptions — even though you do say that "DLEP is restricted to…a single (possibly logical) hop at layer 2", it is based on the deployment assumptions.  What happens if it isn't deployed that way?

I'm confused. We tried to state the DLEP only works over 1 hop. Reliance on MAC addresses forces that. If DLEP isn't used as expected, why would anyone think it would work as expected? Or be secure? A requirement to document use cases outside the document seems to me like a never-ending task - after all, "we don't know what we don't know". We could sit & think about "perverse implementations" almost forever. At the end of the day, if DLEP is not used as expected, all bets are off.

Having said that, would the addition of text stating "Using DLEP with multiple network hops between router and modem is out of scope of this document, and results are unpredictable" serve to address your comment?

That would make me happy, but it wouldn't address my comment.  Note that the reliance on MAC addresses is explained as an assumption (not a requirement)…

I think we all understand when/how DLEP is intended to be used, but it is the SecDir/SEC ADs job to ask those "what if" questions.  No one can guarantee that DLEP won't be used unexpectedly — my real intent it to prevent the impulse of identifying anything as mandatory if it is not required.

I see that the document does include the optional use of TLS — I'm assuming most deployments would set the bit to 0.  It is not discussed anywhere when it might be set to 1, if at all.  If the provision for additional security is already there, the door is then open for all kinds of scrutiny.

Alvaro.

Regards,
Stan

IMO, you should describe the expected operating environment (or point to the assumptions) and any security mechanisms that should be included there (L2, physical assumptions), and explain why confidentiality and privacy are not a concern…but then you should also say something like: "if DLEP is used in an environment other then the expected one, then xx, yy and zz MUST/SHOULD be implemented".   I think that this way we would be covering the normal case, but also providing an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.

Alvaro.

Hello WG,

Thoughts? Suggestions?

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Sun, 7 Feb 2016 12:54:35 +0100

On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana)
<[email-masked]> wrote:
> On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
> <[email-masked] on behalf of [email-masked]> wrote:
>
> Stan:
>
> Hi!
>

It will not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts as a
bridge (as in "layer-2 bridge") between the connection to the router
and the radio network.

If you are more than 1 IP-hop away you will not get the user traffic.

> about users (privacy)?

if you have one IP-hop between radio and router linklayer/MAC security
takes care of this. If not you are outside the specification of the
protocol and do something strange to the traffic anyways... so it
should not be DLEP's problem.

>  I know that the assumed deployment model makes it

If you break the basic assumptions of the protocol, you should not
expect its security considerations to be secure in your situation.

> IMO, you should describe the expected operating environment (or point to the
> assumptions) and any security mechanisms that should be included there (L2,
> physical assumptions), and explain why confidentiality and privacy are not a
> concern…

http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1

> but then you should also say something like: "if DLEP is used in an
> environment other then the expected one, then xx, yy and zz MUST/SHOULD be
> implemented".   I think that this way we would be covering the normal case,
> but also providing an answer to what if without making mandatory mechanisms
> that may be superfluous.

There is no guarantee that xx/yy/zz will give you any kind of security
in an unspecified environment.

Henning Rogge

---

From: Justin Dean <[email-masked]>
Date: Sun, 7 Feb 2016 07:58:06 -0500

How about the following update?  Taken from bits of Hennings' explanation
here and Ran's proposed text from quite a while back.  Please note the
difference in deployment and implement, and the resulting what actually
gets used in real deployments....

   DLEP is restricted to operation over a single (possibly
   logical) hop at layer 2; Deployments other than single-hop are
   not permitted and outside the scope of this specification.
   Deployments requiring authentication and/or encryption of traffic
   MUST take steps to secure the Layer 2 link.

All DLEP Implementations either:

(a) MUST implement Transport Layer Security (TLS)' [RFC-5246]
so TLS is available for use when deployment dictate or
(b) MUST restrict the valid IP (both IPv4 and IPv6) unicast
addresses for use with DLEP to link-local addresses.

   This specification does not effect security of the data plane;
   standard security procedures can be employed for the data plane.

On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge <[email-masked]> wrote:

> the
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Lou Berger <[email-masked]>
Date: Sun, 07 Feb 2016 09:53:30 -0500

Justin,

Two minor suggestions:

s/ link-local addresses/a directly attached IP sub-subnet/

And at then end of  b

Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and 802.1X.

Lou

On February 7, 2016 7:58:37 AM Justin Dean <[email-masked]> wrote:

> ----------

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 7 Feb 2016 11:33:08 -0500

All,

> assumptions.  What happens if it isn't deployed that way?

It's NOT an "assumption". We've mis-lableld it as an assumption. It's
actually a requirement.
Henning's response to the above text is correct:

"It will not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts as a
bridge (as in "layer-2 bridge") between the connection to the router
and the radio network."

Anyone attempting multi-hop deployment will immediately bump into the issue
of a router issuing packets with a Destination MAC address that's not on
the local segment. Traffic won't pass. As Henning states, it simply won't
work.

I believe we need to move the following text from "Assumptions" to
"Requirements":

   DLEP assumes that the MAC address for delivering data traffic is the
   MAC address used by DLEP to identify the destination.  No
   manipulation or substitution is performed; the MAC address supplied
   in all destination messages is used as the OSI Layer 2 Destination
   MAC address.  DLEP also assumes that MAC addresses are unique within
   the context of a router-modem session.

   The reliance on MAC addresses by DLEP forces the assumption that
   participating DLEP peers are on a single segment (either physical or
   logically, via tunneling protocols) at Layer 2.

We also need to take the TLS flag out of the IPv4 and IPv6 Connection Point
data items (a clear "miss" on our part). I believe this addresses the
concern, in that 1-hop deployment is no longer an "assumption".

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Sun, 7 Feb 2016 18:46:03 +0100

> It's NOT an "assumption". We've mis-lableld it as an assumption. It's

Yes.

> of a router issuing packets with a Destination MAC address that's not on the
> local segment. Traffic won't pass. As Henning states, it simply won't work.
>

Correct.

> concern, in that 1-hop deployment is no longer an "assumption".

If we really want to do TLS we can always add a "TLS Connection Point"
TLV in a later extension draft.

We could also keep the flags field if we think its useful for later,
but I think the TLV format is flexible enough to deal with it when we
need a flags field.

Henning