RE: [DNA] RE: draft-ietf-dna-link-information-03

[Alper Yegin <alper.yegin@yegin.org>]

Jari,

> >>>4.  Security Considerations
> >>>
> >>>   A faked link-layer event notification can be used to launch a
> >>>   denial-of service attack on the node and the associated network.
> >>>   Secure generation and delivery of these notifications MUST be
> >>>   ensured.  This is a subject for link-layer and network stack designs
> >>>   and therefore it is outside the scope of this document.
...

> >As for the "MUST", I understand that there are currently deployed systems
> >that do not deploy appropriate security to handle this threat. That fact
> >should not take anything away from what a secure system MUST be doing. I
> >think that fact just makes them insecure in this sense, hence vulnerable
> to
> >spoofed link ups and downs. For that, I'm inclined to keep the MUST in
> >there.
> >
> >
> What you said was "Secure generation and delivery of these
> notifications MUST be ensured." What I'm complaining about
> is that there's no way to fully protect the notifications
> against all threats, particularly if you include DoS. 
> 

Reading your response I realized the current text is open to interpretation.


All I wanted to say was, if my L3 receives a link-up notification, this
notification should be integrity protected, replay protected, and source
authenticated -- in some form. If these are not achieved, it can be
"leveraged" for DoS attacks. I didn't mean to require DoS prevention for any
DoS attacks. 

This level of security is very practical. In most (if not all) cases where
the L2 and L3 reside on the same physical box, we rely on physical security.
Only in cases where L2 and L3 reside on separate boxes, and they
notifications go over a link, then we may need to rely on additional
measures, like L2 or L3 security (IPsec). In fact, physical security may be
used there too.


Having said that, let me look at your text below...




> As
> a result, it seems that we are making a MUST that no one
> can implement. You also do not specify what the implementor
> needs to do to satisfy the MUST, so it would hard for
> anyone to determine whether they are compliant with
> the spec.
> 
> What would perhaps be more useful is to avoid any
> requirements, or say something that is a bit
> more specific, such as "It is RECOMMENDED that
> security at the link layer be used".
> 
> Here's some strawman text:
> 
> Attackers may spoof various indications at the link layer, or
> manipulate the physical medium directly in an effort to confuse the
> host about the state of the link layer. For instance, attackers may
> spoof error messages or disturb the wireless medium to cause the host
> to move its connection elsewhere or to even disconnect. Attackers may
> also spoof information to make the host believe it has a connection
> when, in reality, it does not.
> 
> These attacks may cause use of non-preferred networks or even
> denial-of-service.
> 
> This specification does not provide any protection of its own for the
> the indications from the lower layers. But the vulnerabilities
> can be mitigated through the use of techniques in other
> parts of the protocol stack. 

So far so good.

> In particular, it is RECOMMENDED
> that link layer security is used.

What we need is L2 security that can specifically secure link-layer
connection management related signaling. As you know, not all L2 security
solutions do that. 

Also, we need to capture the other aspect: secure relaying of the event
notification from L2 to the L3. 

> However, these techniques are typically unable to
> protect against all threats, particularly those related to
> denial-of-service.

I'd not even mention DoSs. I didn't mean to get into general DoS. Just
wanted to mention unsecured L2 events can lead up to DoS attacks.

> It should also be noted that upper layer mechanisms may provide
> partial protection against situations where incorrect event
> notifications are generated. For instance, where Secure NEighbor
> Discovery (SEND) [RFC 3971] is used, the host can ensure that it is
> ultimately connected to an authorized router.

I'm not sure if we really want to say that. Because it opens up a lot of
questions and the solution is not straight forward.

Let me know what you think about my points above. We can take your text as
baseline.

Alper





> 
> --Jari
>