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

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

Jari,

OK, I'll follow your recommendation unless someone else has any issues with
it.

Alper


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Monday, July 03, 2006 3:38 AM
> To: Alper Yegin
> Cc: dna@eng.monash.edu.au
> Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03
> 
> Alper Yegin wrote:
> 
> >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.
> >
> It does make a MUST requirement without specifying in detail what needs
> to be done to satisfy it (e.g. specific mechanisms).
> 
> I do not personally worry too much about it, but it may raise a few
> eyebrows
> in the rest of the IESG. And I don't see a lot of use for the statement
> in any
> case, so my recommendation would be to just delete it. I'm not forcing you
> to do that as a part of my AD review, however.
> 
> --Jari
> 
> >
> >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.
> >
> >
>