Re: Comments on draft-ohta-multi6-8plus8-00.txt

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Brian;

> There should be an acknowledgement here to Mike O'Dell, who invented both
> the name and the original 8+8 proposal. Technically the current proposal
> is different, but it is unfair not to give Mike the credit.

8+8 is a generic terminology. It was used at least in 1994 in
big-internet ML. Note that Mike O'Dell, you and I were members
of the ML atthat time. Maybe, Mike O'Dell was the first person
to use the terminology "8+8" somewhere else. But, Mike O'Dell
and others used it as a generic terminology.

Archive of big-internet can be found at:

	ftp://munnari.oz.au/big-internet/list-archive

Later, Mike O'Dell made a proposal. It was named GSE.

My architectural draft made it clear from the beginning:

  Note that 8+8 proposal must not be confused by latter proposal of
  routing goof (GSE) by Mike O'dell, which is a proposal to use
  intelligent routers to rewrite source addresses to prevent source
  address spoofing and to tunnel between intelligent routers for pseudo
  multihoming, both of which are against the end to end principle and,
  thus, lacks robustness and/or scalability.

Read the draft.

> > 2.4.1 Locator Derived ID
>
> ...
>
> >   That is, a site is assured to have 65,536 IDs assigned, though the
> >   locator nature of the ID makes IDs not stable against site
> >   renumbering.
>
>
> There are three major problems with this:
>
> 1. 65k ids is not enough.

I never said 64K ID enough and the draft describes how the problem
can be solved.

However, you are too pessimisitic.

> If I take the example of my own company, we
> would certainly want to appear as a single "site" for multihoming (at
> many different ISP attachment points) but 65k hosts is nothing like enough.

If your company has so many external connections, your company has
a lot more than 64K locator derived IDs that your company don't
have any problem.

BTW, it is unwise that your company appears as a single "site"
for multihoming, because it makes your company valunerable to
internal link failures.

> 2. As I understand it, each host burns up a subnet number. But in large
> systems people expect to use toplogically significant subnet numbering,
> and the numbering plan must survive any amount of moving of computers from
> one building to another. That is incompatible with tying a subnet number
> to a host.

There is no tying. My draft says:

	Note that ID assignment within a site can be arbitrary and will
	not be consistent of intra site link structure. That is, an end
	with a locator derived ID including a certain subnet id
	may be located anywhere in the site, not necessarily in the
	subnet corresponding to the subnet id.

> 3. As noted in the draft, renumbering breaks these IDs so they cannot be
> regarded as having long term stability.

Of course, not.

But, it should be noted that the longevity is expected to be
longer than that of hash of public keys, because security
sensitive people change keys more frequently than ISPs.

Those who need even better longevity are taken care of by
the draft.

> >   Note that ID assignment within a site can be arbitrary and will not
> >   be consistent of intra site link structure. That is, an end with a
> >   locator derived ID including a certain subnet id may be located
> >   anywhere in the site, not necessarily in the subnet corresponding to
> >   the subnet id.
>
>
> This seems entirely inconsistent. It seems to say that when a host is
> moved, its ID can no longer be derived from its locator.

No.

The draft says:

	IDs may be derived from locators allocated to sites.

not

	ID may be derived from a locator allocated to an end.

But, I try to further improve the explanation.

> >   If one want to hide its privacy in ID, one should use locator derived
> >   ID for one's ends.

> I see no privacy enhancement here. These IDs are just numbers, and they
> are persistent (at least until the site is renumbered). If you want to
> enhance privacy, the last 16 bits would need to be a temporary pseudo-
> random value.

Wrong. Your locator is persistent and is known by your peers
that there is no point of hiding it.

> I think that only the location independent IDs of section 2.4.2
> are really interesting, but as we have discussed often, it is not
> obvious that a 64 bit space will really work for this. These
> are old arguments from when we discussed the original 8+8 proposal a
> few years ago.

It is an older argument positive answers to which can be found in
bigi archive.

> > 4.1 Modification to TCP
> >
> >   A new TCP option, Multi Address option, is introduced.
>
>
> How are SCTP, UDP, and DCCP handled?

Read the draft.

> >   It is expected that 9 locators are enough for most ends, as a site of
> >   the end can be multihomed to three lower level ISPs each multihomed
> >   to 3 top level ISPs.  However, if an end has more than 9 locators,
> >   which is a case with routers with more than 9 interfaces, TCP or
> >   upper layer modules should be responsible to select 9 or less
> >   locators to be used for the TCP connection.
>
>
> It seems very doubtful architecturally to have a hard limit on the
> number of addresses and to throw yet more address selection problems
> onto every transport layer implementation. Yes, 9 addresses may cover
> most cases, but the code will have to cover *every* case.

9 is not a hard limit. Read the draft.

> > 4.3 8+8 Adaptation Layers for Applications over TCP and DNS
> >
> >   The 8+8 adaptation layers make end to end multihoming invisible to
> >   applications over TCP and DNS, that is, applications using TCP
> >   transport only without hard coded IP addresses.
> >
> >   Some multihoming proposals try to introduce an adaptation layer in
> >   the Internetworking layer to hide locator changes.  However, this
> >   attempt does not make sense.  As demonstrated by NAT, rewriting of
> >   addresses is, in general, not transparent to transport and
> >   application protocols.  
>
>
> But *reversible* rewriting, as originally proposed by Mike O'Dell and
> found also in NOID for example, *is* transparent to IPSEC, transport,
> and application protocols.

Mike O'Dell imitated existing 8+8 proposals to modify TCP and
other transport layer protocols not to include locator
part for checksuming and IPSEC calculation, which is a
modification to the transport layer protocols. Of course, it is
not transparent to application protocols like FTP.

GSE draft says:

  One immediate result is that upper-layer protocols must use only the
  ESD for purposes such as pseudo-header checksums and the like.

> The original O'Dell 8+8 forced the state down into the border 
> routers.

That's why only way to make it transparent to IPSEC and transport
is not to protect locator by IPSEC nor transport checksums.

You should not rely on your memory and check appropriate references
when you want to say something in the past. I do check them.

							Masataka Ohta