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

[Brian E Carpenter <brc@zurich.ibm.com>]

Factually, Mike first published a pure 8+8 proposal in 
draft-odell-8+8-00.txt in October 1996. GSE came later,
in draft-ietf-ipngwg-gseaddr-00.txt in February 1997.

Apart from that, I am aware of the history and I did read
the current draft before making my comments.

   Brian

Masataka Ohta wrote:
> 
> 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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM