Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jul 2004 09:15:33 +0200

(Chair hat off)

I guess I have three high level concerns with NOID.

1. I am uncomfortable about the dependency on reverse DNS. It will effectively
mean that only well-run servers can benefit from mh, because client systems
with temporary addresses (especially RFC 3041 addresses) are realistically
unlikely to have reverse DNS in place. And that probably eliminates mh for
peer-to-peer applications too, which is a shame.

2. I'd have liked to see a walk-through for a 3rd-party referral case (i.e.
how would it work for p2p anyway?).

3. I am also uncomfortable about "the bit." The whole of section 6 is, well,
a bit kludgy. The only clean solution IMHO is a shim header, which knocks
8 bytes off the user's MTU. In the catgeory of possible alternatives, we could
in theory add
  - encode a couple of bits in the flow label
  - get back the ECN bits

(I'm not advocating either of these, but since the draft lists alternatives...)

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jul 2004 10:40:59 +0300 (EEST)

> peer-to-peer applications too, which is a shame.

(I haven't had time to look at the NOID draft in more detail, so let's
hope I'm not missing some critical context..)

RFC 3041 describes that those addresses can be added to the reverse
tree as well (e.g., such as a hexadecimal string of the address), just
without any real meaning for identifying the node.  This is also
mentioned in draft-ietf-dnsop-ipv6-dns-issues-08.txt section 2.2.

However, for not to lose privacy this would probably mean at least two
things:

 1) the node must not have non-temporary addresses, at least in the
(same) forward DNS name (as the public address)

 2) the temporary reverses would have to be added automatically etc. 
-- draft-ietf-dnsop-ipv6-dns-issues-08.txt analyzes the feasibility of 
this to some degree.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 27 Jul 2004 04:27:49 +0200

Brian,

> peer-to-peer applications too, which is a shame.

While I kind of agree with what you are saying, I still think that mh 
benefits might be a good encouragement to fix the reverse three. And 
with secure dynamic updates we might have a way to do that. But I guess 
I am just being overly optimistic.

- - kurtis -

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 28 Jul 2004 22:33:30 -0500

Maybe it's too close to San Diego for e-mail to make sense to me, but
...

From: "Brian E Carpenter" <[email-masked]>
To: "Multi6" <[email-masked]>
Sent: Monday, July 26, 2004 2:15 AM
Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt

>   - encode a couple of bits in the flow label

Huh? Does this mean (1) we bag ECN in general, (2) we bag ECN for
multihoming and hope no one gets confused about interpreting
overloaded bits, or (3) we're totally confusing Spencer?

The rest of Brian's note made sense to me, I just couldn't parse this
part.

Thanks,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jul 2004 15:19:35 +0200

Spencer Dawkins wrote:
>>3. I am also uncomfortable about "the bit." The whole of section 6
> 
> is, well,
> 
>>a bit kludgy. The only clean solution IMHO is a shim header, which
> 
> knocks
> 
>>8 bytes off the user's MTU. In the catgeory of possible
> 
> alternatives, we could
> 
>>in theory add

I was being drastic: we persuade the IESG that ECN is a massive
failure and have them reallocate the bits. (I'm not advocating
this solution; I simply think we should list all options.)

> The rest of Brian's note made sense to me

This is very reassuring :-)

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Jul 2004 15:51:46 -0700 (PDT)

> 1. I am uncomfortable about the dependency on reverse DNS. It will
> effectively mean that only well-run servers can benefit from mh, because
> client systems with temporary addresses (especially RFC 3041 addresses) are
> realistically unlikely to have reverse DNS in place. And that probably
> eliminates mh for peer-to-peer applications too, which is a shame.

FWIW I have the same concern.
Given that the alteratives to using the DNS for verification have other
downsides I think we should explore how to make a hybrid using techniques
from HIP and WIMP to secure things when DNS is not usable.

> how would it work for p2p anyway?).

Makes sense to add that to the draft.

> 8 bytes off the user's MTU. In the catgeory of possible alternatives, we
> could in theory add

I personally think an 8 byte extension header would be fine.

(Re)using existing bits in the flow label or ECN for this isn't possible
since you'd need some indication in the packet whether the new or the old use 
is intended, hence you need at least one bit somewhere else.

  Erik