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

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jun 2006 11:08:45 -0700

Jari, all:

Please see below for the revised text for the security considerations
section.

Especially the last paragraph. I personally find it useful. But if you
believe it is not useful, or harmful, etc., I don't mind deleting it.  

Suggest deletion/modification/etc as you see appropriate.

--

4.  Security Considerations

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. In particular, it is RECOMMENDED
that authentication, replay and integrity protection of link-layer
management messages is enabled when available. Additionally, protocol stack
may also use some upper layer mechanisms to achieve partial protection
against situations where incorrect event notifications are generated (e.g.,
upper-layer confirmation of the link-layer event).

When the link-layer and the network-layer reside on separate nodes as in a
distributed stack implementation, the event notifications MUST be
authenticated, replay and integrity protected as they are delivered. The
specific mechanisms to achieve the security of notifications are outside the
scope of this document.

Alper

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wednesday, June 14, 2006 3:26 AM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03
> 
> Hi Alper,
> 
> Some further discussion inline:
> 
> >
> >
> >>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.
> >
> >
> This is stack internal unless you have a distributed implementation.
> My advice would be to not start a discussion of how the distributed
> implementation can secure its communication between L2 and 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.
> >
> >
> Yes. Perhaps we could use a sentence that mentions the specific L2 event
> DoS threat, and not my general DoS issue above.
> 
> >
> >
> >>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.
> >
> >
> Its only an example. We could remove the example part or use another
> example if you want.
> 
> --Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 Jun 2006 08:58:48 -0700

>Additionally, protocol stack

Are you referring to DNA itself here?  (e.g. use of SEND)

>specific mechanisms to achieve the security of notifications are outside 

It seems odd to be making strong normative statements at the same time it is 
stated that the mechanisms to achieve the mandates are out of scope.

Overall, I think there is still a missing piece here relating to damping.  
It is one thing for an attacker to be able to execute a DoS attack on one 
node;  it is another to be able to leverage that node's DNA implementation 
to DoS others on the same network, or across the Internet.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jun 2006 13:56:59 -0700

> Are you referring to DNA itself here?  (e.g. use of SEND)

I know the above text is vague. If we try to make it more concrete by giving
examples, I'm afraid we need to further expand on it as it is not straight
forward how one can use SEND, etc. to achieve that added protection. 

If we cannot capture a solid solution (even as an example) without
generating more questions than we answer, I'm inclined to delete the above
paragraph as it may not help in this form.

Thoughts?

> stated that the mechanisms to achieve the mandates are out of scope.

I didn't think of shying away from a must-do just because we are not
providing the solution in this document. Think of it as a requirement for
the implementations of event notifications. 

Please let us know if you have a suggested text replacement.

> to DoS others on the same network, or across the Internet.

This sounds reasonable. Can you please propose some text to capture what you
are saying?

Alper