Re: [manet] DLEP-18 Security Considerations

[Stan Ratliff <[e-mail]>]

Alvaro,


On Sat, Feb 6, 2016 at 5: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.
>

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