Re: [DNA] Issue 8: Modify Security Considerations

[JinHyeock Choi <jinchoe@samsung.com>]

Vijay

> > Our line of thoughts are like below.
> > 
> > 1. With SEND, we can secure Router Discovery, such as Router 
> >     Advertisement. 
> > 2. With secured RA messages, we can secure DNA.  
> 
> this reasoning is flawed. who said all DNA mechanisms will be
> based on RA messages?

Even though, at this point, we can't be certain that DNA will be 
based on RA message, I think that's highly likely and will bet a
dinner on it. :-) Thinking it over, 'ALL' is a very hard qualitifier to 
satisfy.  

> > 3. With secured DNA mechanisms, a host can safely adjust its 
> >     security based on which network link it believe it is attached to. 
> > 4. Without secured DNA schemes, it's inadvisable to do so.  
> > 
> > We think that DNA schemes can be used to detect crossing security 
> > boundaries indirectly and SEND can be used to secure DNA, so the 
> > connection.  
> 
> that is your opinion. IMO, it doesnt belong in a Goals document.
> what if I have never planned on using SEND. :)

I see your point. It may be premature to mention SEND in goals draft 
because, right now, we can't say what form DNA schemes will
take. It maybe be better for us to mention SEND in Solution drafts. 

[omitted] 
> just delete the second paragraph. you can still convey what you
> want to in the Security Considerations section without that text.
> 
>    Because DNA schemes are based on Neighbor Discovery, its trust models
>    and threats are similar to the ones presented in [9].  Nodes
>    connected over wireless interfaces may be particularly susceptible to
>    jamming, monitoring and packet insertion attacks.
> 
>    With unsecured DNA schemes, it is inadvisable for a host to adjust
>    its security based on which network it believes it is attached to.
>    For example, it would be inappropriate for a host to disable its
>    personal firewall based on the belief that it had connected to a home
>    network.

I agree. I'll modify as you proposed. It may be better for us to include 
the second paragraph in Security Consideration of Solution drafts.  
 
> ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756
> which is reference [10]

The reference number is from the new version. In it, [9] is RFC 3756.  
This comment warms my heart because it showed that you really paid 
attention. :-)  

Thanks for your kind and helpful comments. 

Best Regards

JinHyeock