Subject: RE: Comments on draft-nordmark-multi6-threats-01

From: "Christian Huitema" <[email-masked]>
Date: Tue, 8 Jun 2004 23:45:33 -0700

> > If by identifiers you mean the last 64 bits of an IPv6 address, then
I
> > certainly disagree. Mandating that hosts should use the same bottom
64
> > bits on every interface would have some severe privacy implications.
The
> > basic assumption should be that third parties should not be able to
> > correlate addresses/locators used on different interfaces or on
> > different networks without the host consent.
> 
> This is in the context of "identifier" as defined in the draft
> and nothing else:
>       identifier  - an IP layer identifier for an IP layer endpoint
>                     (stack name in [NSRG]).  The transport endpoint is
a
>                     function of the transport protocol and would
>                     typically include the IP identifier plus a port
>                     number.  There might be use for having multiple
>                     interfaces per stack/per host.
> 
> Do you still disagree?

Well, I don't know whether hosts should use the same identifier for
transactions with different third parties. Here, to, there are privacy
implications. If I had a choice, I would go for the minimal possible
requirement, i.e. an identifier for the abstract context for which
continuity of communications is desired. I would also not assume that we
should combine identifier and port number.

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 9 Jun 2004 07:10:51 -0700 (PDT)

> should combine identifier and port number.

Section 8 in the draft talks about privacy considerations.

Given that the stack doesn't (and can't) know the continuity requirements
for some communication - this can be a lot more than the lifetime of
a transport connection - I think we need to have identifiers that can be
stable for more than the lifetime of a single transport connection.

Otherwise, even simple application patternss such as "call me back when done"
(which would cause a second transport connection in the reverse direction)
would fail.

  Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 9 Jun 2004 16:35:42 +0200

Hi,

> Section 8 in the draft talks about privacy considerations.

i guess that also in this point, we should follow the general criteria 
of not making things worse than currently are.
SO the level of privacy provided in current single homed IPv6 should be 
provided in multihoming, i guess.

(a possibility could be to include the current level of privacy support 
in IPv6, just as the other current state of the art are presented.)

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2004 11:30:32 -0700 (PDT)

> in IPv6, just as the other current state of the art are presented.)

Good point.
I guess we can start with IPv4 where in some cases (dialup being the
prime example) the IPv4 addresses change over time.
In IPv6 the temporary addresses RFC provide a way to make it
harder to correlate packets from the same machine over time.

So I think the "do no harm" criteria means that the introduction
of multihoming support should still provide the same ability as we
have in IPv6 with temporary addresses.

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Jun 2004 21:57:55 +0200

> prime example) the IPv4 addresses change over time.

But sometimes it stays the same for very long periods of time.

> harder to correlate packets from the same machine over time.

Which can also be quite problematic in certain situations (DoS, for 
instance). The original intention of RFC 3041 was to make sure that 
when a host moves from one prefix to another, its correspondents can't 
track it by the interface identifier that stays the same. Being able to 
hide within a subnet prefix that doesn't change is an extra feature. 
Not being able to support this feature doesn't automatically disqualify 
a multihoming solution, IMO.

> have in IPv6 with temporary addresses.

We can't let ourselves be constrained by arbitrary features of the 
current architecture. If the features are important, sure, we must 
support them. But having to do so just because it can be done today 
makes has the potential to disqualify very useful multihoming solutions 
without good reason.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 11 Jun 2004 09:13:16 +0200

> have in IPv6 with temporary addresses.

agree
i guess it should also be noted that in order to be reachable, a node 
has to have a stable IP address (stable means compatible with DNS times 
for instance) (which is obvious anyway, that in order to be reachable a 
node cannot be anonymous :-)

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 11 Jun 2004 09:16:16 +0200

> track it by the interface identifier that stays the same. Being able 
> to hide within a subnet prefix that doesn't change is an extra 
> feature.

which we have available today, and that provides some privacy, so 
loosing it is loosing some capability

> Not being able to support this feature doesn't automatically 
> disqualify a multihoming solution, IMO.

i agree, but we have to be aware of what we are loosing and whether the 
trade off is acceptable

> makes has the potential to disqualify very useful multihoming 
> solutions without good reason.

Fully agree.
so let's first describe what we have and how useful this is, and then 
we can evaluate the trade off we are making when accepting a new 
solution that don't support certain features.

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2004 12:05:21 +0200

> node cannot be anonymous :-)

And we have to be a bit careful here too. The applicability of RFC 3041,
or of CGAs which are the same but more so, is probably not to corporate
networks (which is what the word "site multihoming" makes me think of).
A network that is grown-up enough to require multihoming has almost
certainly given up anonymity at the /48 level already, and at that point
anonymity at the /128 level may not have much value. On the contrary,
traceability of /128s may be *required*.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2004 18:13:03 -0700 (PDT)

> makes has the potential to disqualify very useful multihoming solutions 

Is there something in section 8 that you think is placing too strong
requirements?

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 13 Jun 2004 06:06:54 -0700

> Is there something in section 8 that you think is placing too strong

Since it uses the word "could" I don't think there is a requirement 
here at all, so I have no problem with it. Also, I think Brian is right 
in saying that site multihoming and anonimity have a low correlation.