Re: [manet] DLEP-18 Security Considerations

["Alvaro Retana (aretana)" <[e-mail]>]

On 2/6/16, 3:18 PM, "Stan Ratliff" <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> wrote:
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Stan:

Hi!

You'll need references for L2 security.

OK. Do you have any in mind?

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?

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?

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,

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