In message <[EMAIL PROTECTED]>, Erik Nordm
ark writes:
>
>> Yes and no, and a lot depends on the trust relationships between seeker
>> S, intermediary I, and target T. And whether or not N*M is a
>> significant issue depends on the relative values of N and M, and the
>> frequency of contact.
>>
>> The latter is easier to see. If a member of set S has comparatively
>> infrequent contact with a member of T, and N ~= M, there isn't a
>> serious problem with the number of security associations -- there won't
>> be many at any one time, so it won't be much of a load.
>
>I agree that the working set of security associations might not be that large.
>But if there would still be a need for a seeker to establish multiple
>SAs i.e. the time to discover each target is likely to increase
>compared to a case where a single SA can be maintained between a
>seeker and an intermediary. But this is only one aspect of the tradeoffs.
>
Right, though in general the clients have the resources to manage this,
whether directly or via a local proxy.
>
>> In other words, we can't really make any security statements until we
> can define our terms better.
>
>One question is my mind is whether there are threats that are common
>for discovery in general, or whether one has to look specifically
>at DNS discovery to get a better handle on the relevant threats.
>
>
>> The crucial question for security is how a node decides what other
>> nodes to trust. My light switch might decide to trust everyone, on the
>> assumption that no one else has access to the house wiring. I don't
>> think I want my burglar alarm to make the same assumption, since those
>> wires do appear outside my house, both at the service entrance and at
>> the nice, convenient outlets on my porch. (I would note that the U.S.
>> National Electrical Code (adopted by most, though not all,
>> municipalities) *requires* a few outdoor outlets.) In other words, you
>> have to pick your threat model, too.
>
>So how can we understand the threat model for DNS discovery?
>
That takes work... A good starting point would be Derek Atkins' and
Rob Austein's DNS threat analysis document (draft-ietf-dnsext-dns-threats-01.txt)
I haven't had a chance to read it carefully in this context. Rob, I
know you're on this list...
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
