[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