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

Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries"

    Date:        Sat, 12 Jul 2003 06:08:01 +0300 (EEST)
    From:        Pekka Savola <pekkas@netcore.fi>
    Message-ID:  <Pine.LNX.4.44.0307120604450.2478-100000@netcore.fi>

  | If you can't trust the guy whose NIQ's you're answering to enough that you 
  | need to obfuscate the association between RFC3041 and non-RFC3041 
  | addresses, you shouldn't be answering those NIQ's at all.

Pekka, couldn't you say the exact same thing about DNS queries?

The two are just different mechanisms for getting the same information
after all (well, similar information anyway, each has advantages over
the other for different uses).

I haven't heard anyone claiming that DNS queries should be blocked at
site borders, because you can't trust the big outside world to know
any of that information.

If sites want to filter any packets (any kinds of packets) going to/from
any nodes in their domain at all, that's their right.

But there's absolutely nothing here that mandates that people should be
told that they really should block all NIQ packets, any more than we
would consider telling people that they should block all DNS packets.

In an earlier message michael.hunter@eng.sun.com said:
  | I think it should be as strong as the statement about replying with RFC3041
  | addresses in NIQs.  The reason for not wanting either is that both allow for
  | the association between RFC3041 addresses and other addresses.  I can't see
  | making a statement about the two cases with differing levels of strength. 

Personally, I see no harm, and potentially some advantages, in returning
3041 addresses in an NIQ reply.   Remember it isn't 3041 addresses that
are supposed to be the secret, it is the identity of the node.  If you
already know that, then knowing its 3041 addresses is going to be pretty

I imagine the theory is that someone could query every node it can find
to build up a list of 3041 address to identity mappings, and so destroy
the 3041 privacy?   How?   Remember that 3041 addresses remain valid for
only a week (normally) and that new ones are created (and actually used
primarily) every day.

That means, to build up any kind of useful directory, the whole internet
would need to be scanned with NIQ queries every week (and probably every
day).   That's absurd.   Even scanning an organisation large enough to
be able to make any practical use of this kind of privacy internally isn't
really practical.

On the other hand, I can see a utility in being able to locate a 3041
address that relates to a host I want to communicate with (a 3041 address
that works right now).   That could be useful to hide traffic
communication patterns from people who want to snoop on the net and
measure who is talking to whom, and how much.   So, if I look up a
server in the DNS, and want to communicate with it, I could send it a
NIQ and request its 3041 addresses (I think a new request bit would be
a good idea for this), and then pick one of those to use to send to
(probably using the lifetime to pick the newest of them).   Note that
(if needed, and in appropriate circumstances) this query (including the
fact that it is an NIQ query) can all be encrypted, and hence invisible.
On the other hand, the IPv6 headers in the outer packets cannot be
obscured (for obvious reasons).

The other direction - responding to a NIQ sent to a 3041 address
is a completely different issue of course.   That would completely
blow away the privacy that 3041 offers - so this is a completely
different issue, there's no similarity at all between this and a
request for 3041 addresses (including requesting "other" 3041
addresses in a query sent to a 3041 address - all queries sent to
3041 addresses should be dropped).

While (as Dave Thaler suggested) one could respond to a NIQ name
query with a random (or temporary) name - that's not really going
to be any more useful than not responding at all, so just don't
bother.   Responding with addresses is a complete no-go area.

Of course, it isn't only NIQ that suffers this problem when packets
are sent to 3041 addresses - systems running such addresses need
to be aware of all servers they're running that might identify them
if queried, and make sure that none of those are listening on 3041
addresses - this includes SMTP, HTTP, FTP, ... servers, all of which
normally simply volunteer the node's identity (but also SNMP, and
lots more, that can be persuaded to reveal the info).   The IDENT
protocol (as bogus as that nonsense is) is another thing that you
obviously don't want running on a 3041 address.

Most of this really should be included in 3041 itself - perhaps 3041
should even be saying that hosts not respond to incoming connections
addressed to 3041 addresses by default (ie: INADDR_ANY or its v6
equivalent) should not include 3041 addresses) no matter how
innocuous they seem - that they be reserved exclusively for outgoing
connections.   3041 assumes that incoming connections result from
DNS lookups, and as 3041 addresses aren't put there, there will be
no incoming connections to care about - but that's bogus, as the
existence of the IDENT protocol demonstrates (even if it wasn't
obvious without that).

Note - this may seem to be in conflict with my example of why returning
3041 addresses in a NIQ response might be a good idea, but it isn't really.
Servers that know what they're doing (ie: not to identify themselves to
people who aren't supposed to know) can happily explicitly listen to
any 3041 addresses they like.


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 majordomo@sunroof.eng.sun.com