Subject: Re: [Architecture-discuss] Re: Sources of architectural change

From: Leslie Daigle <[email-masked]>
Date: Wed, 02 Nov 2005 00:01:31 -0500

Jumping in mid-thread:

Tony Li wrote:
> The creation of this mailing list is certainly one possible step.  It  
> can be viewed as being open to actually discussing change.   
> Alternately, it can be viewed as simply a rat hole to absorb  dissent.  
> It's not clear which it is, and only the actions of the IAB  over time 
> will tell.

I certainly hope the mailing list will be constructive in
discussion (possibilities of) change.  But I think that has a lot
more to do with its charter and the participation on it than,
necessarily, the IAB's actions.

There are IAB members on this list, to participate.  But,

[Harald wrote:]
> But those who expect *fundamental* change to be *started* within *any*
> established organization understand neither organizations nor human nature.

Consistent with Harald's point, I'll say that the IAB is not going to
hand down stone tablets -- and not just because of Kobe (an incident
some of us are too new to the IETF to have witnessed firsthand).

The IAB is (here and in all its efforts, IMO) trying to gather data
from the community and reflect it back, to help us all make more
architecturally sound choices.  That is *not* a question of
"architecture by popular vote"; rather it is a process of synthesis
and argumentation as part of the community.

Can that provide enough guidance and backstop against flagrant
local optimization in design choices?  Don't know -- but it's the
best we've got so far.

Leslie.

> 
> We all have one common and overriding goal: the continued and ongoing  
> growth of the Internet.  Growth requires change and, as you note,  
> organizations tend to resist change.  Thus, if the IETF is not  careful, 
> it is well positioned to inhibit the growth of the Internet  and thus 
> become self-defeating.  As stewards of the IETF, we must  continue be 
> watchful of this trap and encourage innovation, even when  it opposes 
> the status quo and political forces within the  organization.  That is 
> our responsibility to one another and to each  and every Internet user, 
> past, present and future.
> 
> Respectfully yours,
> Tony
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

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

---

From: Tony Li <[email-masked]>
Date: Tue, 1 Nov 2005 21:17:06 -0800

> and argumentation as part of the community.

Leslie,

Well, let me ask the very pragmatic question then: what would it take  
to get
draft-ietf-ipngwg-gseaddr-00 reconsidered?

Tony

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 02 Nov 2005 01:09:14 -0500

Tony,

I'm not going to answer your specific question, as it's
not mine to answer.

But, to address the more general issue based on the bits
of my message you quoted -- the IAB is trying to gather
data and reflect it back in this case.  So far, as
someone who *wasn't* involved in the original set of design
discussions, I have to say it seems like there is a fair
bit of community unease about the outcome, but I couldn't
begin to form my own technical conclusion on the question.

Useful things that the IAB might do/help cause to happen (hey,
there are plenty of bright minds in this community who don't
happen to be on the IAB at this instant):

	. document more clearly why the  general 8+8/GSE
	  approach may appear to be interesting but is not
	  actually a better answer to the issues that are
	  now facing the Internet

	  - OR -

	. document what has been lost in the discussion along
	  the way (as circumstances changed?), with a view
	  to leading the community to rethink a revisit.

And a very unuseful thing, to be avoided:

	. simply stirring up an old discussion and undermining
	  valid current work.

Particularly those of us who weren't involved in the original
discussion have to tread somewhat carefully to avoid the latter
situation.

Leslie.

---

From: Tony Li <[email-masked]>
Date: Tue, 1 Nov 2005 22:55:00 -0800

> I'm not going to answer your specific question, as it's

Whose is it then?  I confess that I'm very unclear on the process
in this situation.

>       to leading the community to rethink a revisit.

I would welcome the IAB's input on either of the above.

My recollection was that the original proposal was met with a
counter-draft that was unpublished, somewhat questionable, and
was used to justify terminating all discussion of the alternatives.

While I understand the caution necessary in re-opening past work,
there is a significant segment of the community that felt quite
railroaded when this first occurred.  In the intervening time, the
architecture has not evolved good alternatives to fulfill the vision
of GSE, and so it looks to some like the process left useful
technology on the floor for no good reason.

If nothing else, the execution of the process created a silent schism
in the community that remains unhealed.

Tony

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 11:31:13 +0100

Since this is ancient history for most of us, some rehashing may be in 
order, at least about what the history was....

> was used to justify terminating all discussion of the alternatives.

One of my regrets is that at the time this discussion occured, I thought 
that I was too inexperienced in the area to contribute, so I did not do 
anything to contribute....

The GSE proposal was first written up in draft-odell-8+8, published October 
1996 (and the only draft ever published with a plus sign in the filename, I 
believe) and later in draft-ietf-ipngwg-gseaddr, dated February 1997.
The first isn't even available from bgp.potaroo.net; the second is.

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.

This was in the Bad Days Before Tracker, so I'm operating strictly from 
memory, both with dates and conclusions... my memory says that 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.

Version -05 of that draft has a date of October 1999; version -00 had a 
date of March 1997, and was written as *accepting* ESD, so while the end 
result was probably a termination of discussion, the process did take 2.5 
years to get that far.

WRT 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.....

                    Harald

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 11:55:39 +0100

In your previous mail you wrote:

=> this was done at the interim meeting at Palo Alto February 1997.

   
=> the last time I asked why it was not published the answer was
some authors were not convinced the draft was really about the
Mike O'Dell's proposal (BTW this is a serious reason to drop it).

Regards

[email-masked]

PS: IMHO the proposal (the real one or the one described in the ESD
analysis) had a serious security problem as most two-space systems
before HIP...

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 12:49:37 +0100

> analysis) had a serious security problem as most two-space systems

you've seen my occasional rant that placing the source address in the IP 
packet was an architectural mistake, among other things because it led 
people to place trust in something inherently untrustworthy....?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 14:14:14 +0100

=> two-space systems try to solve this issue by splitting the address
into a locator and an identifier. Unfortunately it makes the binding
between the locator and the identifier a new point to attack. This is
why some two-space proposals were rejected in the past even one can
think they were better. I am afraid this is what happened with 8+8.

Regards

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Nov 2005 06:22:13 -0800

> WRT 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.....

Harald,

What ends up going in the TCP pseudo-header?

Ok, you could have an e2e option that negotiates GSE, but that's just  
gross beyond belief.  There are
also huge implications for address allocation...

Sigh.  The only problem with making architectural changes is that  
they change the architecture.  ;-)

Tony

---

From: "Edward A. Gardner" <[email-masked]>
Date: Wed, 02 Nov 2005 07:37:05 -0700

>order, at least about what the history was....

Not only is it ancient history, many/most of us lurkers have no idea what 
draft-ietf-ipngwg-gseaddr proposed or is about and have no idea what the 
rest of you are talking about.  And as all the tombstones say, it wasn't an 
archival document.

If rehashing that decision is important to this discussion list, would 
someone please post a technical summary of that proposal or a pointer to one?

If rehashing that decision isn't relevant or constructive, maybe we can 
proceed on to something that is?

Ed Gardner

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 2 Nov 2005 16:04:43 +0100

El 02/11/2005, a las 11:31, Harald Tveit Alvestrand escribió:
>
> WRT 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.....
>

GSE or something in those lines was the subject of many discussions in 
the multi6 wg.
even today, there are still some discussions about allowing site 
routers to write the prefix part of the addresses on the fly.

Personally, i like the approach and the benefits that it provides, but 
personally, i don't know how to make it work from a security p.o.v.
As i see it, or you involve the hosts in the security mechanisms (i.e. 
e2e security of the available prefixes) which would break the initial 
idea of having the hosts unaware of the prefix set available, or you 
build the security in the exit routers, which has at least, a lot of 
complexity, since a state related to a given communication is injected 
in a middlebox, which implies or single point of failure or a protocol 
for coordination of this state between the exit routers, and this has 
additional complexity...

personally, i think that if a gse like approach was not followed in the 
multi6/shim approach was because security issues or in other words, 
that the result of gse when you apply all the security mechanisms that 
are needed is not as attractive

regards, marcelo

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 02 Nov 2005 16:09:03 +0100

Tony,
I perused the GSE proposition (I discovered under 
http://www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt ). (I 
take this occasion to repeat my plea: that it is netiquette to give 
the URL of the quoted documents, including Drafts).

It seems to be a way to allocate aggregated addresses (by non 
discussed Registries of two global spaces) in order to best take 
advantage from them. No objection, but it seems a 00 Draft. Would it 
not be more an ASO BCP and an usage architecture proposition?

I do not see reasons why IPv6 addresses could not be allocated that 
way in the ITU /3 block (however I prefer the concatenation of 
routing, addressing and interfacing global spaces)?

Anyway, I would qualify this of "accidental" (not essential) rather 
than of "architectural" since no one ever claimed that IP addresses 
should all follow the same model.
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 16:14:08 +0100

> What ends up going in the TCP pseudo-header?

That's the part where I think it may not be workable...otoh, this is 
exactly the same set of issues that Multi6 is facing (for some of its 
ideas).

I also believe that the extent of the TCP pseudo-header was one of those 
things that turned out to be a mistake in retrospect, when it seems to be 
too late to change....

> Sigh.  The only problem with making architectural changes is that  they
> change the architecture.  ;-)

:-)

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Nov 2005 17:21:16 +0200

Edward A. Gardner wrote:

> If rehashing that decision isn't relevant or constructive, maybe we 
> can proceed on to something that is?

Meta-comment: we went from discussion of architectural
issues (e.g. mobility and multihoming) to process questions
(how can IAB do architecture) and then to ancient history
(design decisions of IPv6). Lets go back to the issues... (but
I have nothing against people bringing up GSE as a
proposal to solve today's problems).

--Jari

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Nov 2005 07:32:01 -0800

> I also believe that the extent of the TCP pseudo-header was one of  
> those things that turned out to be a mistake in retrospect, when it  
> seems to be too late to change....

Seems?  Or 'is'?

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Nov 2005 07:41:24 -0800

> I perused the GSE proposition (I discovered under http:// 
> www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt ). (I take  
> this occasion to repeat my plea: that it is netiquette to give the  
> URL of the quoted documents, including Drafts).

Whoops, thanks.

> advantage from them. No objection, but it seems a 00 Draft. Would  
> it not be more an ASO BCP and an usage architecture proposition?
>

There is much more to it than that.  Basically, GSE was the last and  
best effort to create an architecture that separated
the address into both a 'locator'  (where is the host) and  
'identifier' (the ESD in the draft).  The TCP pseudo-header would
only be computed across the identifier and the locator would be free  
to change.

Security would not cover the locator and security associations would  
only be between ESDs.

The locator/identifier architecture simplifies the architecture  
because it allows both mobility and multi-homing to become
natural and pervasive.  For mobility, the host is now free to change  
its locator at will.  For multi-homing, the same end-host can
now be reachable via multiple locators.

Tony

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 16:45:27 +0100

>> seems to be too late to change....

I'm fond of not making completely definite statements, but in this case, 
it's hard to imagine the change :-)

if we REALLY want to change it, it's probably simpler to do so by changing 
the protocol number for TCP..... TCPng, anyone?

(ducks)

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Nov 2005 18:09:44 +0200

Tony Li wrote:

> 'identifier' (the ESD in the draft). 

I think some modern architectures such as HIP appear
to do a more thorough job and consider the whole problem. (Or at
least a larger problem, I think HIP NAT support needs improvement.)

> Security would not cover the locator and security associations would  

There's a lot more to security than allowing IPsec SAs to work over
communications in such architectures. Marcelo pointed to some
issues in his mail; you'd probably want to avoid other people hijacking
your communications etc.

I wanted to see if GSE had dealt with these issues, but here's what
the security consideration section from the GSE draft says:

>17. Security Considerations
>
>   More than can be imagined.
>
--Jari

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 02 Nov 2005 17:52:46 +0100

>only be computed across the identifier and the locator would be free

No problem with that. But you can imagine doing that easily today as 
a convention in a numbering plan. Not to confuse the words, I use 
routing/addressing/identification. The only information of interest 
for the network is routing. The rest of the address can be mangled by 
the ISP and restored when back.

>now be reachable via multiple locators.

We are entirely in agreement. This is the way mobilephones work?

What I mean in saying it is accidental is that if you have 10 
internet exchanges on Wimax in an area you can build such a system 
without asking anything to anyone between them. If it works you can 
install 100 more, etc. You can this way become the final world IP 
plan. You have changed nothing in the Internet architecture. You have 
just chosen your own usage architecture and disregarded many RFCs 
without any use to you. A simpler, more secure, etc. system which scaled.

If an idea is good, it will eventually become used. With delays as 
many other ideas will have been verified on the market before.

HIP seems obviously a good idea: at least it seems to correct these 
delaying ideas. But do we need it?
jfc

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Nov 2005 09:26:04 -0800

> >  More than can be imagined.

	Please review

	 http://www3.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd-analysis-05.txt

	and

	 http://www.cs.columbia.edu/~smb/papers/esd-secure.txt

	Dave

---

From: Geoff Huston <[email-masked]>
Date: Thu, 03 Nov 2005 05:37:26 +1100

>The first isn't even available from bgp.potaroo.net; the second is.

It is now - thanks for letting me know

http://draft-odell-8.potaroo.net/

>don't know if it's workable.....

To be best of my recollection this did not resurface in the multi6 effort - 
although its true to say that most forms of rewriting parts of the packet 
header by some form of foreign agent were reviewed in multi6. The issues of 
knowing (and being able to reliably detect)  the difference between a 
'friendly and helpful" rewrite and a "hostile effort at session hijack" 
remained significant issues with the foreign agent rewrite approaches. Like 
Harald my recollection of this in 1999 was that there was a similar concern 
over 8+8.

Certainly this is once more an active topic, in that the issues here appear 
to be a rather tough trade-off between control of the security issues in a 
host-based approach to this topic (such as shim6) and a site/ locale-based 
approach to this topic (such as gse approaches).

Among the detritus of unfinished work there was an effort by myself and 
Margaret Wasserman to write up the multi6 proposals - an early draft is in 
an appendix of 
http://smakd.potaroo.net/ietf/all-ids/draft-huston-multi6-architectures-00.txt-76090.txt. 
As I recall someone else volunteered at a multi6wg meeting to take on this 
as a separate draft - but no further progress was made

Geoff

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Nov 2005 11:17:28 -0800

> I'm fond of not making completely definite statements, but in this  
> case, it's hard to imagine the change :-)
>
> if we REALLY want to change it, it's probably simpler to do so by  
> changing the protocol number for TCP..... TCPng, anyone?

Harald,

I have to look at this as simply another indication that we're not  
ready to make architectural changes.

Shifting to a new protocol number is largely not helpful.  It implies  
that to truly introduce GSE, we have to renumber
*all* of the transports and have backwards compatibility built into  
all of them.  How is this simpler than changing
the version number in the IP header?

Regards,
Tony

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 2 Nov 2005 22:49:47 +0000 (GMT)

On Wed, 2 Nov 2005, Edward A. Gardner wrote:

> rest of you are talking about.

http://www.watersprings.org/pub/id/draft-odell-8%2B8-00.txt
http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt

http://www.watersprings.org/pub/id/draft-ietf-ipngwg-esd-analysis-00.txt
through to
http://www.watersprings.org/pub/id/draft-ietf-ipngwg-esd-analysis-05.txt

Watersprings is a useful tool.

Get up to speed.

L.

> And as all the tombstones say, it wasn't an
> archival document.
>

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>