Subject: Re: host-centric draft

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 1 Mar 2004 15:12:43 +0100

On 2004-02-25, at 18.06, Erik Nordmark wrote:

>> So the question is: can we detect the actual reachability using probes
>> fast enough that we don't feel we also need to look in the routing
>> tables? If end-to-end is 30 seconds while routing table is 30
>> microseconds, then sure, I agree that the latter is useful. If
>> end-to-end is 3 seconds, maybe having to wait this long some of the
>> time is better than importing all this BGP complexity. If it's 300
>> milliseconds I'm sure it is.
>
> That's on the benefit side, but also have too look at the cost side
> in terms of scaling.
> If all hosts perform e2e probing of all the local/peer locator pairs
> this might add up to a lot of packets; might be more than the amount of
> data packets that are exchanged in some cases (imagine hosts being 
> sensors
> which only send a data packet every 30 seconds and now you add probing 
> 4 or
> so local/peer locator pairs!).
>
> If we care about *site* (and not *host*) multihoming one could try to
> have hosts share the information they learn from probing with their
> neighboring hosts. But that leads more or less to reinventing
> a routing protocol.

Or piggybacking on one of the existing ones?

Best regards,

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 1 Mar 2004 15:16:00 +0100

On 2004-02-25, at 18.43, Iljitsch van Beijnum wrote:

>
>> might be more than the amount of
>> which only send a data packet every 30 seconds and now you add 
>> probing 4 or
> That's why I think we should only perform reachability checks when we 
> already know or at least have a strong suspicion that something is 
> wrong.
>
> One possible exception is session establishment: it might be useful to 
> try several setup attempts in parallel, as the one that completes the 
> fastest is probably also the one that offers best peformance during 
> the session.
>
Don't this open up for a new DDoS? Interrupt the transport on both 
sides, or at a (or multiple) site exit router, enough to cause a storm 
of setup attempts?

Best regards,

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Mar 2004 00:41:17 +0100

> sides, or at a (or multiple) site exit router, enough to cause a storm

Would the interruption of the transport in and of itself be a DoS you 
need to worry about??  :-(

I think having two, three or four SYNs at the same time is ok as long 
as we only do this once every X seconds rather than several times a 
second which could happen with HTTP. Also, we may want to include a TCP 
option that lets the server know different SYNs are part of the same 
session setup attempt so the server can react in a smarter way. (For 
instance, delay SYN+ACKs a bit for less-preferred addresses and throw 
away the remaining half open TCP sessions when one completes.)

---

From: Geoff Huston <[email-masked]>
Date: Tue, 02 Mar 2004 12:32:29 +1100

In the interests of allowing everyone to come armed with the appropriate 
weapons for
this agenda topic, I've attached a PDF of the current version of the draft.

I may (will) change the presentation between now depending on the response
from this list,, but I would obviously prefer a little shaking out in the 
wg on the
more generic topic of "is this architectural taxonomy on the right track" and
"have I missed an architectural taxonomy element?"

But of course any comment is helpful  - but saying that I want comments
on this list is perhaps just adding more jet fuel to the inferno  - I don't see
this as a reticent group!

   Geoff

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Mar 2004 11:14:25 +0900

Geoff;

> this agenda topic, I've attached a PDF of the current version of the draft.

Thanks.

> from this list,, but I would obviously prefer a little shaking out in 
> the wg on the

Well,

  Modify the Transport or IP layer of the stack in the host

is generic enough to include

  Insert a new level in the protocol stack (identity element)

and

  Modify the behaviour of the host/site exit interaction

that it is no good for classification.

Moreover, the classification is rather rhetorical (API)
than architectural.

That is, most, if not all, approaches of:

  Modify the Transport or IP layer of the stack in the host

can have some API to make it:

  Insert a new level in the protocol stack (identity element)

as demonstrated by my 8plus8 draft:

   4.3 8+8 Adaptation Layers for Applications over TCP and DNS

So, it is better if your presentation is titled:

	A Rhetorical View of Multi6 proposals

							Masataka Ohta

---

From: Geoff Huston <[email-masked]>
Date: Tue, 02 Mar 2004 14:07:44 +1100

Thanks for your comments. Obviously I do see a distinction
between a distinct protocol element that reaches some form
of state synchronisation with its peer and a modification
of a protocol element where there are additional behaviours
added to the element, but within an overall synchronized
state of an existing protocol element.

But as with any architectural model the precise places where the lines
are drawn can involve some level of judgement.

Regards,

    Geoff

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Mar 2004 13:25:06 +0900

Geoff;

> state of an existing protocol element.

Huh?

The properties you mentioned are not orthogonal that
that's not a classification.

For example, how about a modification of a protocol element
where there are additional behaviours added to the element
not within an overall synchronized state of an
existing protocol element?

						Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Mar 2004 20:45:50 -0800 (PST)

> "have I missed an architectural taxonomy element?"

Overall I think this is on the right track.

While in the fullness of time we want session persistence I think we need
to look carefully at what is needed to introduce multihoming when the
peers are not upgraded to use something new. I don't know if
that is what the question mark after "session persistence" on page 11.

Drilling down into the "defining a new protocol element" set there
seems to be two classes:
 - those that define a new namespace (HIP, SIM, ...)
 - those that use an existing name space such as FQDNs (MAST, NOID, CB64, ...)

With that split in mind it seems odd to clumb together the proposals on page
13; SIM is much closer to HIP (with the biggest difference being that the
payload packets are not encrypted by SIM whereas HIP encrypts everything.)

So understanding which proposals provide a new ID name space to applications
would be useful.

  Erik

---

From: Geoff Huston <[email-masked]>
Date: Tue, 02 Mar 2004 16:06:25 +1100

Thanks Eric

-  The ? was shorthand for "how do you..." i.e.I was intending to
    pose this as a question!

- the distinction about the characteristics of the identity token space is
   useful, and I've added an additional slide to call this out, as there
   are certainly some implications about structured and unstructured
    spaces in terms of lookup and referral that need to be called out, I agree.

regards,

    Geoff

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Mar 2004 08:53:16 +0100

On 2-mrt-04, at 2:32, Geoff Huston wrote:

> In the interests of allowing everyone to come armed with the 
> appropriate weapons for this agenda topic, I've attached a PDF of the 
> current version of the draft.

Geoff, is there any reason my two recent drafts 
(draft-van-beijnum-multi6-odt-00.txt and 
draft-van-beijnum-multi6-cbhi-00.txt, which isn't on Kurtis' list) 
aren't included in your analysis?

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 2 Mar 2004 17:04:02 +0900

Geoff,

Mostly as FYI but maybe useful for your presentation,
below is a copy of a message that started a brief
private discussion with Erik, Dave and some others in last
October.  It really considers only wedge approaches,
but goes into some more detail than your current slides.
Some of the information may already be stale, given
that it is five months since this discussion.

--Pekka Nikander

I think that I am starting to see components.  There are a
couple of things that seem to be more or less ubiquitous
over the various solutions:

   1. A wedge layer between IP and the transport layers,
      translating IDs to locators and back.
   2. A modified resolver library that returns IDs instead
      of locators.

Then we seem to have a number of possible solutions that
allow the recipient to map incoming packets on the right
ID pairs:

   3a. A new extension header that provides an
       ephemeral 32-bit ID that acts as a pointer to a
       specific ID pair.
   3b. An ESP extension header that provides a 32-bit
       SPI that acts as a pointer to a specific ID pair.
   3c. A single bit stolen from the IP header that indicates
       that the incoming locator pair must be mapped to an
       ID pair.
   3d. Conceptually steal a bit in the IP header, but implement
       it with clever encoding.
   3e. An implicit assumption that if two hosts communicate,
       they always communicate either with or without the
       new semantics.  Hence, each incoming locator pair
       can be matched against known and cached locator pairs,
       and if a match is found, the locator pair can be mapped
       to an ID pair.

3a and 3b allow multiple IDs behind a single address.
3c, 3d and 3e do not.  3e does not allow locator rewriting
by routers.

So far I think that the solution space is pretty clear.
Next we seem to reach muddier waters.

We seem to need a method to prevent redirection attacks
(both connection hijacking and flooding).

   4a. Rely on some variant of return routability
   4b. Rely on forward and reverse DNS.

The next thing is the context creation protocol.  This seems
to require a 4-way handshake, consisting of a trigger,
request, response, and confirm.

What is noteworthy is that both TCP and SCTP can be
piggybacked over this context creation, since neither TCP SYN
nor SCTP INIT requires state to be created at the responder.

There are multiple dimensions on how the context creation
protocols differ.

Time:

   5a. The context is created immediately.
   5b. Context creation may be delayed.

Security strength of identifiers:

   6a. The context is not associated with any strong
       identifier.
   6b. The context is authenticated with a strong identifier.

Actual mechanism:

   7a. A simple tag is shared during context creation,
       and this tag is later used as a weak means of
       authentication.
   7b. A simple secret is shared during context creation,
       and this secret is later used to authenticate
       changes to the context.
   7c. A D-H protocol is run immediately, and the thereby
       created shared secret is used.
   7d. A D-H protocol may be run later.
   7e. A pair of hash chain anchors are exchanged during
       context creation, and the previous hashes from
       the hash chain are later used to authenticate
       changes to the context.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 2 Mar 2004 09:17:26 +0100

> aren't included in your analysis?

They are now...(I knew I had missed some...)

- - kurtis -

---

From: Geoff Huston <[email-masked]>
Date: Tue, 02 Mar 2004 19:20:06 +1100

The use of specific proposals is as examples in the context of the 
presentation,
as they are intended to be examples of the various styles of approach.
This was to constrain the length of time for the presentation as a more
exhaustive enumeration in the presentation would not really add an
awful lot to the taxonomy but would take a lot of time.

As I understand the overall plan the to-be-written-document would attempt
to analyse all the proposals using this architectural taxonomy,

regards,

    Geoff

At 06:53 PM 2/03/2004, Iljitsch van Beijnum wrote:
>>weapons for this agenda topic, I've attached a PDF of the current version 
>>of the draft.
>
>draft-van-beijnum-multi6-cbhi-00.txt, which isn't on Kurtis' list) aren't 
>included in your analysis?

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Mar 2004 00:30:31 +0900

Geoff;

> awful lot to the taxonomy but would take a lot of time.

Wrong.

The proper way to let your classification understood by people
submitting their proposals is to classify their proposals.

It can also act as an evidense that you do read and understand
the proposals.

Do that.

> to analyse all the proposals using this architectural taxonomy,

I already showed that your taxonomy is no good for architectural
discussions.

If you disagree, classify 8plus8 proposal after reading
section 4.3 of the proposal.

						Masataka Ohta

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 03 Mar 2004 08:58:24 +0900

> nor SCTP INIT requires state to be created at the responder.

This is a common assertion but it is factually incorrect with respect
to TCP.  

If the 3rd packet of the 3-way handshake is lost, *and* the
application protocol is one in which the server is the first to send
data (e.g., a connection banner), the client will move the connection
to ESTABLISHED state and quietly hang waiting for data to arrive,
while the server will have no record of the connection....

The SYN-ACK must be retransmitted if not acked.

					- Bill