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

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 06:08:01 +0300 (EEST)

On Fri, 11 Jul 2003, Michael Hunter wrote:
> On Fri, 11 Jul 2003 22:40:29 +0300 (EEST)
> Pekka Savola <[email-masked]> wrote:
> > On Fri, 11 Jul 2003, Michael Hunter wrote:
> > 
> > > On Fri, 11 Jul 2003 08:00:36 +0300 (EEST)
> > > Pekka Savola <[email-masked]> wrote:
> > > 
> > > [...]
> > > > > The other one is: if a NIQ is send to a RFC3041 address, do you reply to
> > > > > it? My take is that by default, you should not and have a switch to
> > > > > override.
> > > > 
> > > > But I fail to see any use for this.  Typically when you implement these, I
> > > > think they'll listen to all addresses ("any incoming packet").  It seems
> > > > that disabling one set of addresses and even giving users a toggle of
> > > > rather little value would be useless.  But of course, one might have to 
> > > > implement differently too.
> > > 
> > > The association between RFC3041 addresses and other addresses is what you
> > > want to protect.  If you let a 3rd party discover that association with
> > > NIQ then you've removed the little usefulness that RFC3041 addresses have.
> > 
> > Please re-read what you write.
> > 
> 
> I'm not understanding the following so I apologize if my response isn't
> to your point.

Sorry if I was unclear..

> > What you're implying is that those you're worried about would learn your 
> > "true identity" and not RFC3041 would ones allowed to send NIQ's to you 
> > and you'd actually answer them?
> 
> So the issue I was attempting to communcate was that the association
> between your RFC3041 address(es) and your other addresses was something
> you wanted to protect.  The following two points need to be protected
> at the same level:
> 
> 1) Somebody sending a request to a non-RFC3041 address and discovering
> your RFC3041 address(es).
> 
> 2) Somebody sending a request to a RFC 3041 address and discovering your
> other addresses/name which resolves to other addresses.
> 
> If you think one is important, I believe you should think both are
> important.

True.  But now comes my actual point: you're making an assumption that all 
nodes in the Internet (basically) would answer to NIQ's from everywhere, 
and consequently there would be some information to disclose.

I don't think this is reasonable.

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 Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Sat, 12 Jul 2003 20:04:56 +0700

Date:        Sat, 12 Jul 2003 06:08:01 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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 [email-masked] 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
harmless.

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.

kre

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 19:16:12 +0300 (EEST)

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

Not really..
 
> site borders, because you can't trust the big outside world to know

.. you don't query DNS information from the nodes themselves.  You query 
it from designated DNS servers.

Now, if NIQ mechanism would be made so that the nodes would report their
hostname<->address mappings to some site-specific registries, and one
would be able to query the data from those registries (applicable to the
policy set by the network administrator for such queries), we would be
talking about an entirely different thing.. not too far from DNS + dynamic 
updates (or IETF-specified protocol for standard Looking Glass lookups for 
certain information about routers, depending on whether you're looking at 
querying information from hosts or routers.)
 
> would consider telling people that they should block all DNS packets.

Blocking them would be very much in line with the intended applicability
of NIQs as written down AFAICS.  I'd like to implement the stick
(blockage)  in addition to the carrot (nice words about applicability) in
the NIQ specification so that it's not misused.