[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] Issue 8: Modify Security Considerations



thanks.

Vijay

JinHyeock Choi wrote:
> 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