[Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change)

[[e-mail] (Noel Chiappa)]

    > From: Harald Tveit Alvestrand <[e-mail]>

    > The GSE proposal

One of the unfortunate things about Mike's GSE document (as opposed to Dave
Clark's 8+8 message to the IPng mailing list, which started the whole ball
rolling) was that it (unfortunately) mixed together two separate ideas:

- i) separation of location and identity, and
- ii) automatic addition of "high-order" location information *at the site
boundary* as the packets left the site

The second, while interesting, resulted in the first not being given the
distinct appraisal that it really deserved.


    > what it would take to bring it back: At the current stage of IPv6, it
    > seems to me that it would take someone working through how to allow one
    > subnet in a classical IPv6 network to use 8+8 while the rest of the
    > world didn't..... apparently nobody's seriously suggested that in
    > Multi6.... I don't know if it's workable.....

Alas, at this point, I'm not sure it's viable. Here's the problem: 8+8 (in
all its variants, including GSE - the two are *not* synonomous) assumed that
the TCP checksum included only the "identity" part. That way, if the
location-identity binding changed, it wouldn't complicate the checksum
computation. (Having done an "add a location namespace to TCP-4" proposal in
some detail for the NSRG, I can tell you that it gets pretty tricky.)

To really get the full benefit of 8+8, you'd have to go back and change the
TCPv6 checksum definition. This is unlikely to happen. So you're stuck with
either an option to change the TCP checksum behaviour (see paren comment
above) - which results in a lot more complexity, and an inability to make the
extended features available to non-upgraded hosts.

The *right* thing would have been to have considered location/identity
separation as an *architectural* issue, and left the *engineering* issues of
how to *secure* that binding until later - initial implementations could
have, e.g., *locked* the binding to be that in the SYN packet (for TCP; other
protocols the same). However, the basic mechanism (the binding table, the
checksums, etc) would have been there, ready and waiting, when we did work
out the engineering. (This, by the way, is exactly what we did with subnets -
the host mechanism was added in RFC1122 before it was fully worked out how we
were going to use it.)


Water under the bridge now, alas... Although it remains a useful lesson for
architects: work out basic concepts, add basic mechanisms, and *deliberately*
leave the engineering details for later. If you can't do that, you're not
doing architecture.

(TCP retransmission is a great example of this: the details of the algorithms
have changed completely, but the basic mechanisms, because they were
fundamental, easily absorbed them.)


[I put this part out of order, down here, so that this less valuable
re-hasing of the past can be skipped by those who don't care.]

    > The IPNG WG seemed to achieve "rough consensus" that GSE was not a
    > viable approach; the arguments against GSE were summarized in the draft
    > draft-ietf-ipngwg-esd-analysis.
    > At some later time, this draft was proposed for publication.
    > .. the IESG questioned the justification for some of the claims in the
    > draft regarding the percieved security weaknesses of GSE and sent it
    > back to the WG; it never returned.

As I recall (again, operating from memory, I haven't bothered to re-read the
draft, or try and find my marked-up paper copy :-), a number of us heavily
criticized the analysis as biased, and technically unsound, and the whole
thing (proposal and analysis) just went into abeyance: the proposal because
it was clearly not going to succeed, and the analysis because there was no
point if the proposal was abandoned.


To the best of my memory, I felt that the analysis was deeply flawed, and
wound up coming down against *all* identity/location separation schemes on
the basis of the problems with *this particular one*. Yes, of course when you
have two different names, the binding between them is a point of attack.
However, that's not sufficient reason to dismiss it.

I felt such a conclusion was *especially* completely unreasonable because the
then-contemporary MIPv6 concept (as I gleefully pointed out) did *exactly
that* - separate identity and location! But the group which did the analysis
(many of whom also worked on MIPv6, which just deepened the irony - or
unfairness, depending on the mood in which one viewed the situation) didn't
seem to take notice of that.

All of which led me personally to conclude that it was a "hatchet job" - i.e.
the outcome was determined before the analysis started. Those on the other
side will no doubt feel I'm being unfair to them, but, as the lawyers say,
"the document speaks for itself" - particularly the earlier versions. The
later versions may have fixed some of the more egregious errors, but by then
it was moot.

	Noel

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/architecture-discuss