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

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

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:jari.arkko@piuha.net]
> Sent: Wednesday, June 14, 2006 3:26 AM
> To: Alper Yegin
> Cc: dna@eng.monash.edu.au
> 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