Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

From: "Christian Huitema" <[email-masked]>
Date: Mon, 5 May 2003 15:11:22 -0700

> One way of addressing this particular concern is to say the top 48
bits
> are mutable from one globally unique value (a "site identifier") to
> another globally unique value (an "aggregation locator") via some
> mapping function at both exit from the source site as well as entry at
> the destination site.

The focus on the site misses an important point. Computers are often
multi-homed to several sites, e.g. WiFi and GPRS. If you do something as
radical as changing the behavior of TCP, then you want a solution that
handles host multi-homing as well as site multi-homing. But then you
cannot expect that all the "locators" that carry packets to a single
TCP++ solution belong to the same aggregate.

In the site multi-homing case, you must also be concerned with privacy
issues. You should not force multi-homed computers to attach the same
"global identifier" tag in all of their IP addresses, and you may expect
privacy advocates to forcefully remind you if you ignore that point. 

Having a 16+16 solution a la Mobile IPv6 may be fine, provided that the
privacy-conscious can encrypt the correlation identifier (the second 16)
in an encrypted exchange. And it would also be nice if the second 16 did
not have to be present in every packet.

-- Christian Huitema

---

From: David Conrad <[email-masked]>
Date: Mon, 5 May 2003 15:51:24 -0700

Christian,

> The focus on the site misses an important point.

I thought this working group was working on site multi-homing.

On Monday, May 5, 2003, at 03:11  PM, Christian Huitema wrote:
> Computers are often
> multi-homed to several sites, e.g. WiFi and GPRS.

Terminology issue.

According to the working group draft:

    A "site" is an entity autonomously operating a network using IP and,
    in particular, determining the addressing plan and routing policy for
    that network. This definition is intended to be equivalent to
    "enterprise" as defined in [RFC 1918].

WiFi and GPRS are access methods.  A network provider could offer 
connectivity to a "site" via WiFi or GPRS.

However, with that said, presumably the device you are thinking of is a 
dual-mode cell phone/PDA or equivalent.  As I have said before, a 
"site" in such a case could be defined to be the PAN (of perhaps no 
devices) connected to the Internet via the cell phone/PDA or 
equivalent, connected via WiFi and/or GPRS.

> If you do something as
> handles host multi-homing as well as site multi-homing.

If you are doing something as radical as changing the behavior of TCP, 
then there are a lot of things that could be fixed, e.g., the layering 
violations of having the network address be aware to the transport and 
application layers, creation of a real session layer, etc. etc.

However, I don't think this would be the right working group (or even 
the right area) to try to come up with (Transport Layer Protocol)++.

> You should not force multi-homed computers to attach the same

I think this is a bit overblown.

Privacy advocates went non-linear on the idea that _individuals_ could 
be identified by the traffic they originate or receive due to IPv6's 
stateless auto-configuration using the EUI-64 associated with hardware 
interfaces on the user's computer.  I do not believe they were 
concerned that _sites_ could be identified.  If they were, I would 
imagine they'd be pretty unhappy with IPv4.

Rgds,
-drc

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 06 May 2003 09:03:08 +0300

> not have to be present in every packet.

With the danger of repeating myself (which I apparently do),
I just want to remind that the above is more or less what
HIP does.  In HIP the second 16 is carried only during the
initial host-to-host state setup; after that both the second
16s are "compressed" into ESP SPI.

There is one problem with encrypting the second 16, which is
making stateful middleboxes harder to implement.  Thus, there
is a tradeoff between privacy and dealing with middle boxes
such as firewalls.  In the case of HIP, this is (partly) taken
care of by allowing the hosts to use several "second 16"s,
different ones for different purposes (or locations).  There
might be other alternatives, like partial encryption that
allows authorized middle boxes to learn, through some computation,
the real second 16s while making such a computation far too
expensive for third parties.

Secondly, in whichever solution is selected, we must remember
that the mapping from the identifiers to the locators (or from
DNS names to identifier/locator pairs) must be made secure enough
in a scalable manner.  Secure DNS has been shown not to be scalable
in practise.

--Pekka Nikander

---

From: David Conrad <[email-masked]>
Date: Tue, 6 May 2003 20:08:19 -0700

On Monday, May 5, 2003, at 11:03  PM, Pekka Nikander wrote:
> Secure DNS has been shown not to be scalable in practise.

Oh?  References?

Rgds,
-drc

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 07 May 2003 11:32:11 +0300

>> Secure DNS has been shown not to be scalable in practise. 

Well, apparently I should have been more careful with my
wording.  No, it has not been scientifically (by analysis)
shown not to be scalable.

I was merely referring to the current state of deployment
and to my admittedly very limited practical experience,
mostly within the scope of Mobile IPv6 security design team.
Maybe I am wrong, and in any case my statement above was
far too strong.  Sorry about that.

Now, what I was referring to was merely our strawman analysis
of what happens if you use secure reverse DNS to verify if
someone is authorized to use a particular address.  I didn't
find the text any more (maybe it is available in the DT
archives, but I don't know where they are).   Anyway, the
result was that you typially end up doing maybe 7-8 DNS
queries and verifying 10-12 public key certificates, or
something like that.  Not really scalable if you would need
to do that for each address that you get.

Thinking about the issue a little bit more, it is not at
all clear whether we need secure reverse DNS in this case
at all.  If we want to securely resolve host identifiers
(second 16s or whatever) into locators, maybe we need.
In that case the analysis applies, and should probably be
made again, perphaps with more rigor this time.

--Pekka Nikander