Re: [manet] DLEP-18 Security Considerations

[Stan Ratliff <[e-mail]>]

All,

I think the critical point here is Alvaro's comment:

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

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



On Sun, Feb 7, 2016 at 9:53 AM, Lou Berger <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>> 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....
>>
>> 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.
>>
>>    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.
>>
>>    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 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 <[e-mail]> wrote:
>>
>>> On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana)
>>> <[e-mail]> wrote:
>>> > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
>>> > <[e-mail] on behalf of [e-mail]> 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?
>>>
>>> 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.
>>>
>>> > What about confidentiality of the data?  What about exposing
>>> information
>>> > 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
>>> > 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?
>>>
>>> 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
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>