Re: [manet] DLEP-18 Security Considerations

[Lou Berger <[e-mail]>]

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
>