Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt

From: Alain Durand <[email-masked]>
Date: Thu, 18 Jul 2002 15:04:00 +0200

On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote:
> <grin> That would give very interresting results indeed, so let's add
> the fact
> that it for example BIND have to be configged for such a delegation
> like:
>
> zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" {
>         type ipv6nodeinfo;
>         allow_names "*.unfix.org";
> 	  check_forward yes;
> };
>
> This would then tell BIND to do nodeinfo queries for
> 3ffe:8114:2000:240::/60.

This approach will work for the reverse mapping of
Site Local addresses if and only if the primary server and
all its secondary are all in the _same_ site local zone.

If not the ICMP will go to the wrong place...

	- Alain.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: David Terrell <[email-masked]>
Date: Sat, 20 Jul 2002 00:55:21 -0700

> If not the ICMP will go to the wrong place...

This is yet another general problem with SL addressing which has
been discussed before.  One might imagine a configuration option
that lets you restrict query access for SL addressing to site local
(zone-based or otherwise configured local prefixes) requesters.

Regardless, I like ICMP node lookup.  Information is good.  Being
able to provide information is good.

-- 
David Terrell          | Just another satan-worshipping Harry Potter reader.
[email-masked]           | 
Nebcorp Prime Minister | 
http://wwn.nebcorp.com |

---

From: [email-masked]
Date: Sun, 21 Jul 2002 06:09:06 +0900

>> >        allow_names "*.unfix.org";

	i specifically mentioned in the draft (and presentation) that querier
	should be the node itself, as view of scope zone is different
	between them, and there's no way to pass scope zone info over
	DNS protocol (or identifying scopes).

	above example is OK as it is for global addresses, but for site-locals
	and link-locals, above approach (named translates DNS query into
	ICMPv6 node info query) does not work.

	minor implementation problem - non-privileged programs cannot generate
	ICMPv6.  so we need:
	- a root-privileged daemon that sends ICMPv6 node info query,
	- communication channel from libc resolver to the daemon which does
	  not lose scope info (DNS wire format doesn't work).  unix domain
	  socket, shared memory, whatever.
	current KAME revlookupd is problematical with respect to the latter
	bullet.  http://www.kame.net/kame/kame/kame/revlookupd

itojun

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Jul 2002 16:53:10 -0700

> able to provide information is good.

Yup.   I think having the mechanism is great.

What do people think of signing the ICMP packet with the private key that 
corresponds to a KEY RR that is attached to the name mentioned in the ICMP 
packet?

---

From: [email-masked]
Date: Sun, 21 Jul 2002 09:07:36 +0900

>corresponds to a KEY RR that is attached to the name mentioned in the ICMP 

	i may be asking a stupid question, but where do you get that private
	key from?  for instance, if a node responds with "www.ietf.org",
	we could get a public key for www.ietf.org by KEY RR query, but
	not the private key (it's on ietf.org authoritative server, and
	is not accessible from outside).

itojun

---

From: [email-masked]
Date: Sun, 21 Jul 2002 09:27:31 +0900

>	is not accessible from outside).

	aha, now i see what you mean... the ICMPv6 node information responder
	would sign it, and every nodes have secret key on their own.
	the now problem is there's no generic public-key signing protocol in L3.

itojun

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Jul 2002 23:29:13 -0700

> 	is not accessible from outside).

Presumably the device answering the ICMP request is the one named, and 
therefore knows the private key associated with its name.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 21 Jul 2002 16:29:49 +0200

In your previous mail you wrote:

=> to solve this issue I added in my old "INRIA" stack at the request
of Alain Durand a SOCK_CONTROL socket type which has access to information
ICMPs.

Regards

[email-masked]

PS: the change is very small: a definition in sys/socket.h,
an entry in netinet[6]/in[6]_proto.c and some new "if" cases in
netinet[6]/raw_ip[6].c. I let Alain defend his (very good IMHO) idea.

---

From: [email-masked]
Date: Mon, 22 Jul 2002 07:24:14 +0900

>Presumably the device answering the ICMP request is the one named,
>and therefore knows the private key associated with its name.

	no, the device answering ICMPv6 request is not named.

	with the "type ipv6nodeinfo" directive, named will work like this:
	- accept DNS query from a DNS client resolver.
	- send NI query to the target address.
	- receive NI response from the target.
	- send DNS response to the original DNS client resolver.

	since the NI query target can return arbitrary FQDN (like
	"www.ietf.org") named does not have the private key.

client resolver ---------> named -------> the target
		DNS query	 NI query
client resolver <--------- named <------- the target
		DNS response     NI response

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 24 Jul 2002 22:50:16 +0900

>>>>> On Mon, 22 Jul 2002 07:24:14 +0900, 
>>>>> [email-masked] said:

> 	no, the device answering ICMPv6 request is not named.

??? I'm a bit confused.  Are you saying that we can *not always*
assume the device answering ICMPv6 request runs a name server?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: [email-masked]
Date: Wed, 24 Jul 2002 22:56:04 +0900

>assume the device answering ICMPv6 request runs a name server?

	the thread of email assumes the following diagram.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 24 Jul 2002 23:28:45 +0900

>>>>> On Wed, 24 Jul 2002 22:56:04 +0900, 
>>>>> [email-masked] said:

>> client resolver <--------- named <------- the target

Hmm, I read the Ted's message

>>>>> On Sat, 20 Jul 2002 16:53:10 -0700, 
>>>>> Ted Lemon <[email-masked]> said:

> corresponds to a KEY RR that is attached to the name mentioned in the ICMP 

to mean the diagram like this:

                   NI query
nodeinfo client ------------------> the target
                                    with named (authorizing the name)
                                    and private key
                <------------------
                   NI response signed
                   by the private key

(BTW: I understood the very original idea of this thread meant the
diagram you showed.)

But if I just misunderstood, please ignore me.  I was just checking.

					JINMEI, Tatuya

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 24 Jul 2002 16:21:53 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> > client resolver <--------- named <------- the target

As I was toying around with Opportunistic Encryption it shaded another
light on this subject.
Could there be a query type which requests the KEY (just like the DNS
RR) of a host.
This would allow for example FreeS/WAN and Racoon and other IPSec
implementations to request
the public KEY from the host itself in a standardized way. The proposed
DNS<->nodeinfo could
then also provide this information over DNS. Ofcourse one has no 100%
ensurance that the replied
KEY is valid at all.

Greets,
 Jeroen

---

From: Derek Atkins <[email-masked]>
Date: 24 Jul 2002 12:38:47 -0400

> Could there be a query type which requests the KEY (just like the DNS

Yes, it's called IKE.  It's already part of the IPsec protocol suite.

> ensurance that the replied

This is exactly why it isn't done, and why you want keys in DNSSEC.

>  Jeroen

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2002 10:21:39 -0700

>                                     with named (authorizing the name)

No, I was talking about securing the NI query, but not assuming that a 
"name server" would do that work, except in the sense that by definition 
anything that responds to a query for a name with a name could be called a 
name server.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 25 Jul 2002 10:21:35 +0900

>>>>> On Wed, 24 Jul 2002 10:21:39 -0700, 

> anything that responds to a query for a name with a name could be called a 

So more accurately, you meant like this?

                   NI query
                                    with some private key
                <------------------
                   NI response signed
                   by the private key

					JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2002 18:38:45 -0700

> nodeinfo client ------------------> the target

Yes, where the name in the response is a valid domain name, and when the 
client looks for a KEY record on that domain name, it finds a public key 
that can be used to successfully validate the signature on the response.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 25 Jul 2002 11:20:39 +0900

>>>>> On Wed, 24 Jul 2002 18:38:45 -0700, 

> that can be used to successfully validate the signature on the response.

okay, so I guess you and itojun (attached) were talking about
different things.

Returning to your idea, it sounds attractive.  However, I'm not sure
if this approach is applicable widely.  In particular, I'm not sure if
"edge devices" such as personal laptops, PDAs, cell phones..., for
which the nodeinfo-revlookup would be most useful, have private keys
authorized in the DNSSEC framework.

					JINMEI, Tatuya

Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt
From: [email-masked]
To: [email-masked], [email-masked]
Date: Mon, 22 Jul 2002 07:24:14 +0900

itojun
--------------------------------------------------------------------
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: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2002 20:06:51 -0700

> authorized in the DNSSEC framework.

Why not?   I think they do probably have private keys, and configuring them 
with the private side of a DNSSEC key doesn't sound very hard.   It does 
sound like it would be quite useful.   :')

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 26 Jul 2002 02:03:39 +0900

>>>>> On Wed, 24 Jul 2002 20:06:51 -0700, 

> sound like it would be quite useful.   :')

It is probably okay to assume the devices have some private keys.  My
concerns (or what I'm not sure about) are:

- how to register the keys to DNS.  Manual configuration (by an
  administrator) is not realistic for general cases, but I'm not sure
  if DNS dynamic update is effective.
- how to construct the trust chain of DNSSEC toward the root zone.
  The zone to which the edge devices belong is presumably a kind of
  "personal" one, and we may not always assume it is a secure zone.
  In fact, in my understanding the current trend of DNSSEC is to
  restrict signed zones to some "well-known" ones such as a zone
  containing famous commercial web servers.

Some may have an idea to deal with this, though.  If there is a
concrete idea of an entire system, I'm very interested in it.

					JINMEI, Tatuya

---

From: David Terrell <[email-masked]>
Date: Fri, 26 Jul 2002 11:52:20 -0700

>   if DNS dynamic update is effective.

In the mobile, dynamic IPv6 world, it seems like having public keys 
in DNS would be fairly common for things like secured NSUPDATE, so the
host would already be doing this.

>   containing famous commercial web servers.

Something tells me that a lot of people on this mailling list will have
signed, secure zones long before these famous commercial web servers...

-- 
David Terrell          | Step 1: "configure one system using your GUI"
[email-masked]           | Step 2: "now configure 1000 more"
Nebcorp Prime Minister |   - Casper H.S. Dik
http://wwn.nebcorp.com |

---

From: [email-masked]
Date: Mon, 29 Jul 2002 12:18:23 +0900

>that can be used to successfully validate the signature on the response.

	again, there's no protocol for signing ICMPv6 using private key.
	IPsec (AH/ESP) doesn't work here.  do you have any proposal?

itojun