Subject: CELP (was RE:)

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Feb 2004 16:06:12 -0800

The draft and Avri and I wrote on the SLAP idea is now available:

>         Title           : Framework for Common Endpoint Locator Pools
>         Author(s)       : D. Crocker
>         Filename        : draft-crocker-celp-00.txt
>         Pages           : 10
>         Date            : 2004-2-11
>         
> Classic Internet transport protocols use a single source IP Address
>    and a single destination IP Address, as part of the identification
>    for an individual transport data flow. This is problematic for
>    multihomed hosts and for mobile hosts, collectively needing
>    'multiaddressing' support. The basic goal, then, is to find a method
>    for multiaddressing that makes the smallest possible change to the
>    architecture and to current systems, while maintaining flexibility
>    for different emerging solutions.  This draft proposes a framework
>    for methods for creating Common Endpoint Locator Pools that can be
>    used by and among the proposed solutions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 12 Feb 2004 16:04:22 +0100

Hi Dave,

I am trying to understand this CELP idea, so i have some comments.

First, about the Locator Pool concept.

The Common Endpoint Locator Pool contains the locators of both endpoints
involved in a communication.
When a host A is communicating with a host B, the CELP of host A contains
both locators from A and locators from B.

Additionally, i  guess that the CELP has to contain reachability information
about each locator (or perhaps about each locator pair, since a destination
may be reachable or not depending on the source address used.)

Furthermore, some proposals also include information about whether the
locator has been verified or not.

So the CELP, in a host A,  for a communication between A and B, has (at
least) the following information:

Locator Set of A={LA1,LA2,...,LAn}
Locator Set of B={LB1,LB2,...,LBm}

Verified Locator Set of B={LVB1,LVB2,...,LVBk}

Reachables pairs={(LAi,LVBj) for a certain group of i and j}

Do you think that this would be what a LP should contain?

Now the idea would be that the CELP is maintained through different means,
such as enhanced transport protocols and wedge layer so that if one of them
introduces new information in the CELP, this information is available for
all the others. In this way, overhead can be reduced since the information
is obtained only once and not for every particular mechanism.

Now, let's analyze a bit more which information can be provided per each
mechanism:

Locator Set information: This would be the (unverified) locator set of B

There are three types of mechanism that can provide such information:
- The enhanced transport layers
- The wedge layer
- The DNS

So the Locator Set of the CELP is feed by these 3 mechanisms, ok.

Now, the next relevant information is about address validation. Here is
where it starts to get fuzzy for me.
Every mechanism can have very different ways to validate a locator.
Especially verifications made by transport layers can be weaker because only
a connection is at stake, while wedge layer tend to do stronger validations,
and even between the different proposals for wedge layer, the strength of
the validation varies. Finally, the addresses provided by the DNS have also
a different level of validation (which also varies if DNSsec is used)

So, i am not so sure that a validated address means the same for the
different mechanism, so i see a difficulty in including addresses through
different means to be used by all of them.

Clearly, the weaker mechanisms can benefit from addresses validated through
stronger mechanisms but i doubt that the reverse would be possible. In any
way, the first option is possible and it would help to reduce the overhead.

Finally, the other relevant information is the reachability information.
Reachability means that if you send a packet to a certain destination from a
certain source address, a reply is received before a defined timeout.
So reachability is related to a destination a source and a timeout.

The problem that has already been discussed in the list is that the timeout
varies depending on the application.

So, a certain source/destination address may be unreachable for some apps
but not for others.

So we need to include something more specific than an unreachability flag
for a source and destination pair.

An option could be that the different mechanisms include the timeout value
that expired when they decided that a certain source and destination address
is unreachable for them.

So a SCTP connection is using a certain source and destination address pair
and it timeouts after x seconds. It then informs the CELP that this
source/dest address pair takes longer than x secs to respond.
The next mechanism can see whether this is acceptable and wants to try its
luck using it or it is not acceptable. But this is starting to become quite
complex, i think. Another option is just to order the potential
source/destination address pairs according to the last timeout, so that the
one with lower timeout is used first. In any case, i still don't see this
very clear.

Finally another question is how do identify a CELP is identified. I mean
some wedge layer create new id name space, so you can just use the ID pair
to identify the CELP, others don't introduce a new id name space, so regular
ip addresses are used.

Now the new id name space and the IP address space may collide, so a
mechanism to uniquely identify a CELP is required.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Dave Crocker
> Enviado el: jueves, 12 de febrero de 2004 1:06
> Para: Multi6 List
> Asunto:
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Feb 2004 08:22:42 -0800

marcelo,

(my own comments below.  of course, avri might feel differently.)

mb> The Common Endpoint Locator Pool contains the locators of both endpoints
mb> involved in a communication.
mb> When a host A is communicating with a host B, the CELP of host A contains
mb> both locators from A and locators from B.

yes.

mb> Additionally, i  guess that the CELP has to contain reachability information
mb> about each locator (or perhaps about each locator pair, since a destination
mb> may be reachable or not depending on the source address used.)

Certainly the Internet has examples of pair-wise UNreachability. And
certainly there is concern that the Internet is moving towards more and
more of this partitioning. So as you note, a full model must account for
that reality.

However, I believe that early, simple versions of a CELP implementation
may choose _not_ to have pair-wise entries. As you note, there is a good
reason for maintaining locator pairs. However I would expect the simpler
approach to be adequate for many situations.

My point is that that simplifying assumptions are probably useful for
early adoption, in order to reduce the barrier to that adoption.

mb> Furthermore, some proposals also include information about whether the
mb> locator has been verified or not.

The fully-general version of a CELP implementation certainly can and
should maintain an extensive range of routing table classes of
information.

mb> There are three types of mechanism that can provide such information:
mb> - The enhanced transport layers
mb> - The wedge layer
mb> - The DNS

The 'DNS' reference probably should be something like "external lookup
services", with sub-entries, because mobility probably requires a more
dynamic Presence-like service.

mb> So, i am not so sure that a validated address means the same for the
mb> different mechanism, so i see a difficulty in including addresses through
mb> different means to be used by all of them.

Here, again, I see your point as being entirely correct for the
long-term theory of this approach, but I believe a much simpler model
can be used initially.

Where reality turns out to differ from this simpler model, a
conservative choice can be made, such as declaring unreachability. This
would be acceptable because the resulting, limited service is still much
better than what we have today.

mb> Clearly, the weaker mechanisms can benefit from addresses validated through
mb> stronger mechanisms but i doubt that the reverse would be possible. In any
mb> way, the first option is possible and it would help to reduce the overhead.

I think this depends on being able to characterise the different types
of validation, so that the practical meaning of "weaker" and "stronger"
validation have clear, operational definition and measurement. Only then
can we discuss the impact of the differences.

mb> The problem that has already been discussed in the list is that the timeout
mb> varies depending on the application.

This is a good example of the reason this topic is part IP-level and
part Transport-level. I've come to believe that it should be modeled as
a new, full-fledged architectural layer, taking some from IP and some
from IP and adding some new stuff.

At any rate, here again I think we can win with a simplied model
initially, for easier early adoption.  Then it can be enhanced.

(By the way, I hope it is clear that I'm not disagreeing with your
points. I think it is clear that all of them are correct. I'm only
suggesting a divide-and-conquor approach towards dealing with this
domain, where we defer whatever complexities we can, to gain early
utility. Then we can feed that experience into a later round of
enhancement.)

mb> Finally another question is how do identify a CELP is identified. I mean
mb> some wedge layer create new id name space, so you can just use the ID pair
mb> to identify the CELP, others don't introduce a new id name space, so regular
mb> ip addresses are used.

Well, the CELP discussion on granularity shows different sets of parameters
being used to identify different sets of locators.  The examples use IP
Address as the first level of discrimination.

I suppose the different identifiers are necessary for correlation during
maintenance activities. I'm not sure they actually affect _use_ of the
entries.

mb> Now the new id name space and the IP address space may collide, so a
mb> mechanism to uniquely identify a CELP is required.

collide?  huh?

d/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 12 Feb 2004 18:07:01 +0100

Dave,

i agree with your divide and conquer approach and providing simple
mechanisms initially as a mechanism to facilitate adoption.
Moreover, it has to be considered that initially neither applications nor
transport (multiaddress capable or not) will be able to fully benefit from
CELP since some explicit communication between CELP and transport/wedge
layer are required for this i guess.

The point then i guess would be to agree on which points can be delayed and
which points are required even for a simplified initial version.

I will try to comment on this below....

> approach to be adequate for many situations.

I am not sure that this would be good enough.

I mean, the source address used by multihomed sites implies at least the
return path and in many scenarios also the forward path (because of the
ingress filtering)

So, if you don't consider the source address when determining whether a
destination address is reachable, you are basically omitting the fault
tolerance capabilities of multihoming.

Suppose a multihomed site with two ISPs, ISPA and ISPB. Each of the
providers has delegated a prefix to the multihomed site, PA and PB.

A host H1 within the multihomed site is communicating with a host H2 outside
the multihomed site, H1 is using PA:H1 address and H2 has only one address
H2.

Now the link between the multihomed site and the ISPA fails.

Then H2 is reachable using PB:H2 but H2 is not reachable using PA:H1

Bottom line is that if the source address is not considered, fault tolerance
capabilities of multihomed are not present, i think.

> mb> locator has been verified or not.

I think i didn't explain myself very properly in the previous posting, sorry
for the unclear statement.

When i said verified, i was talking about the security verification.

My understanding is that first the host learns a set of locators.
Then it verifies them using some security mechanism, in order to avoid
impersonation, flooding etc.
Finally it verifies the reachability of the locators.

In this part i was talking about the security verifications, that's why the
stronger and weaker language.

Some wedge approaches use pretty strong security mechanism, such a public
key crypto.
Some transport solutions just use a cookie, which may be acceptable because
only a connection is at stake

Then, what i meant is that i don't think that a locator verified by the
transport mechanism will be acceptable for the wedge layer.

However, it may be acceptable in the other case around, i.e. a locator
verified with PK crypto can be accepted by a solution that relies on
cookies.

I hope i have explain my concern in a better way this time.

About the simplified initial approach, i am not sure if this would be
possible here either.

> initially, for easier early adoption.  Then it can be enhanced.

This is the point where i think that an initial simplified model could be
more possible.
If one app marks an address pair as unreachable, no matter what unreachble
means to the app, may be a simple initial start point.

> utility. Then we can feed that experience into a later round of

I agree with your approach

[...]

> mb> mechanism to uniquely identify a CELP is required.

This is just an implementation detail, i guess.

But if a wedge layer uses the Hash of the FQDN as the permanent identifier
(just to take a random example :-) and the transport layer uses the regular
IP address to identify the other endpoint, you have to make sure that these
two don't have the same value for different hosts, because if this happens
you will have the same identifier for two different hosts when accessing the
CELP, but i may be missing something... In any case, i don't think this is
unsolvable

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Feb 2004 11:00:37 -0800

Marcelo,

mb> i agree with your divide and conquer approach and providing simple
mb> mechanisms initially as a mechanism to facilitate adoption.

ok.  however this suggests that the document should have an appendix
that contains a discussion of the longer-term issues. that way, any
near-term, "expedient" choices will be distinguished.

>> approach to be adequate for many situations.

mb> I mean, the source address used by multihomed sites implies at least the
mb> return path and in many scenarios also the forward path (because of the
mb> ingress filtering)

Do other folks also view this as a significant issue _today_?

I still operate under the possibly-false view of an Internet that is
mostly reachable. Perhaps partitioning is already too much of a problem,
for us to ignore this type of fine-grained mechanism?

>> mb> locator has been verified or not.

mb> In this part i was talking about the security verifications, that's why the
mb> stronger and weaker language.

ahh.  ok.  certainly this is a major point of difference among the
different proposals.

However I think that it still permits a question about practical
importance, for early celp.

it is entirely possible that folks will view any reasonable
authentication scheme as sufficient, and that it is not important to
make distinctions in the strength -- beyond a minimal threshhold, of
course.

Admittedly, I am biased on this point. I think anything at the level of
purpose-built keys is fine, to ensure that later packets are from the
same source as the original packet. But not going beyond that type of
"weak" authentication. (And, by the way, I personally dislike the use of
the word 'weak' for labeling this scheme. the authentication mechanism
can be strong. and the contextual assurances can be strong. it is the
_global_ _identification_ that is weak or rather, non-existent...)

mb> About the simplified initial approach, i am not sure if this would be
mb> possible here either.

Excellent.  We have something to debate, because I want to disagree...

(That's a cue for others to contribute.)

d/

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 13 Feb 2004 16:22:47 +0200

Dave,

> from IP and adding some new stuff.

I fully agree with you here.  As you wrote, this also means that
we will need quite a lot of interaction between various areas
at the IETF.  And probably lots of experimentation as well.

> (... I'm only

This is a good approach, IMHO.

(I am sorry but I really can't disagree with you at this level.
However, I do see a number of potential problem areas as soon
as one tries to dive into the details...)

--Pekka

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 16 Feb 2004 11:25:14 +0100

> for us to ignore this type of fine-grained mechanism?

This is very much the world of *today*. And I think we will have to 
assume that for layer9+ reasons the world of tomorrow will have to look 
similar, unless the concerns can be met in other ways.

> Excellent.  We have something to debate, because I want to disagree...

I am not sure I follow what you are arguing here. Are you saying that 
just proving the identity of the other end from connection 
establishment until session termination is enough? I.e no global 
verification, just "continuity" verification?

- - kurtis -

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 16 Feb 2004 12:35:16 +0100

> for us to ignore this type of fine-grained mechanism?

Well, the point here is what part of the internet is reachable trough each
one of the IPS that serve the multihomed site

So, I agree that a partition of the Internet is not likely, but this is not
my concern.

A site becomes multihomed becuase it wants to improve its fault tolerance.
This means that if the site were single homed, some parts of the Internet
would be unreachable for him, so he wants to overcome this problem by
multihoming

So, i think i don't agree with the assumption that the internet is mostly
reachable, because if this were so, why would sites multihome in the first
place?

But  i am probably missing something here....

Reagrds, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Feb 2004 08:39:13 -0800

marcelo,

mb> A site becomes multihomed becuase it wants to improve its fault tolerance.
mb> This means that if the site were single homed, some parts of the Internet
mb> would be unreachable for him, so he wants to overcome this problem by
mb> multihoming

In fact, this reason had not occurred to me!  I have always assumed that
the reliability reason for multihoming was to continue operation when
their own interface goes down.  That's quite different from a concern
over network partitioning, elsewhere.

(Geographically distributed multihoming for large organizations is a
different matter.)

In any event, let me again stress that I am pursuing this kind of issue
in order to distinguish near-term, narrow concerns, versus
longer-term, general concerns. The hope is that this distinction can
allow initial solutions to be simpler.

From my own sense of the net and from the responses so far, I believe
that a host can maintain an address pool based solely on a simple list
of the destination's addresses. That is, for the near term, the
combinatorial complexities of considering local/remote address pairs can
be deferred. Of course, the implications (that is, the limitations) of
this simplifying assumption need to be stated.

d/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Feb 2004 23:42:21 +0100

>> http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt

Still catching up...

Let me start by strongly disagreeing with:

"The basic goal, then, is to find a method for multiaddressing that 
makes the smallest possible change"

IF a change is necessary, it would be stupid to optimize for a small 
change, as the difference in deployment effort between nog change and a 
small change is HUGE while the difference between a small change and a 
larger change isn't very substantial. If changes are necessary, we must 
make sure we get it right the first time if at all possible. A good 
example is the change to the socket API when IPv6 was introduced. This 
change was kept as small as possible, but despite that 5 years later 
only a fraction of all applications have been updated. And now that 
we're talking about multihoming we may have to change this API again, 
or bend over backwards to avoid it.

I also disagree with the assertion that transport-based solutions would 
save on the number of packets exchanged. A wedge solution can monitor 
transport interactions to see whether there is still connectivity. And 
the currently existing transport solution, SCTP, adds lots of extra 
packets by periodically probing connectivity on all paths. In cases 
where there are two or more backup paths this can save a little on 
recovery time after a rehoming event, but I think the cure is worse 
than the illness here and in the case of only one backup path it 
doesn't help anyway: if the primary path fails the only possible course 
of action is to use the backup path, regardless of whether we "know" 
that it works or not. (Obviously when one path fails changes to the 
other paths at the same time aren't unthinkable so all existing 
knowledge is suspect.)

Also, on the ipv6mh list we had extensive discussions about keepalives 
and I think I made a good case for taking advantage of path overlap 
between different destinations, making it possible to reduce the number 
of keepalives to each individual destination while retaining the 
desired average failure detection times.

"Enhanced transport services access the pool directly. Legacy transport 
services access the pool via the IP wedge layer service."

Ok, this is the part I like. However, this reads like you expect the 
enhanced transports and the wedge mechanism to live together without 
sharing any mechanisms. I think that would be a missed opportunity.

And I think you're right there is lots of stuff that overlaps with what 
we're doing in multi6 going on, we need to figure out how to handle 
this. The fact that there hasn't been significant interaction with the 
mobility people yet despite the general recognition that there is 
overlap that has existed for years, isn't a good sign here.

One problem: how do we know that different addresses point to the same 
entity? Within a protocol this could probably be implied, but between 
protocols this can easily become problematic. For instance, some 
protocols may not care that a set of addresses points to different 
hosts providing the same service, while for other protocols switching 
hosts isn't likely to work. It also works the other way around: if we 
don't recognize two addresses belong to the same entity we may lose an 
opportunity to switch between those addresses later. Maybe having 
identifiers isn't such a bad thing after all...

Later:

"From my own sense of the net and from the responses so far, I believe
that a host can maintain an address pool based solely on a simple list
of the destination's addresses. That is, for the near term, the
combinatorial complexities of considering local/remote address pairs can
be deferred. Of course, the implications (that is, the limitations) of
this simplifying assumption need to be stated."

Again: we have to do it right the first time if we possibly can. 
Deferring this also doesn't make sense as ingress filtering by ISPs 
makes source address problems too common to be able to ignore safely 
even if ignoring failures in the middle of a path would be considered a 
good idea.