Subject: Re: [arch-d] Major practical decision

From: [email-masked] (Noel Chiappa)
Date: Sat, 9 Dec 2006 11:39:29 -0500 (EST)

> From: marcelo bagnulo braun <[email-masked]>

Good questions!

I think the problem is that it seems that people tend to either think about
i) how to do multi-homing, or ii) how to deploy something to prevent routing
meltdown (e.g. jack-up), and don't always think "how does the design do both"!

So it's not immediately clear to me, for example, exactly how jack-up/mapping
schemes support multihoming. Yeah, the box that does mapping/wrapping could
know (from the mapping table) that IPvN address range X.1-X.n is multi-homed
because it maps to three different new routing-names, A.p, B.q and C.r, and
there's some mechanism (probably not in the routing itself) to make sure that
whichever one it picks is currently functional (i.e. not unreachable because
while A is reachable, the A<->A.p link has gone down, and the routing has
aggregated all A.* announcements to A by the time they get to this mapping
box).

But, yeah, people thinking about one side of this (multi-homing, or routing
meltdown) need to pay attention to how their stuff does the other side.a

    > what kind of approach could provide multihoming support (preserving
    > established communications)

Oooh, there's multi-homing and there's multihoming! Keeping existing
connections up is probably harder than allowing new connections to succeed.
When you say "preserving established communications", did you mean "keep
existing connection up", or what?

    > without requiring support from both peers of the communications? (by
    > peers i mean either the end nodes themselves

With enough thrust, pigs can fly. The question is, do you want them to fly?!
So I'm sure that with enough mechanism we could probably make this work.
However, do we want the additional complexity (and also, potentially,
overhead) to make it work - is this an important enough goal?

    > If we do actually manage to define a solution that _only_ requires
    > modifications to the multihomed site and does not requires
    > modifications to the peers that it is communicating with (nor the the
    > network outside the multihomed site) this would be indeed a really nice
    > feature

Ditto... E.g. we sort of have this now, it's called PI-addresses, but the
overhead is not reasonable.

    > because only those who actually get the multihoming benefits have to
    > pay the costs of supporting the multihoming support tools, which is
    > very nice

Well, presumably the other party gets some benefit too. I mean, if you're
trying to get to Google, or a news site, or an e-business site, and you can
because they are multi-homed, you get the benefit too, not just the site
you're going to.

    > i am not sure i have ever seen a proposal that does this....

Good point.

    > could you expand?

Sigh. The more I read this morning, the more I think we need to stop doing
this by email, and put 20 people together in a room for a couple of days, and
repeat that several times, with breaks of a couple of weeks in between, for
comment/recuperation.

There is just too much ground to cover, and too much to say about most parts
of it...

	Noel

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

---

From: David Conrad <[email-masked]>
Date: Sat, 9 Dec 2006 17:07:54 -0200

Noel,

On Dec 9, 2006, at 2:39 PM, Noel Chiappa wrote:
> because it maps to three different new routing-names, A.p, B.q and  
> C.r,

Right.

> and

One of the reasons I think a tunneling approach is the right way to  
go is that it allows for in-flight re-routing to occur.  That is,  
when the packet reaches a point where the unreachability of the final  
destination can be determined, the router at which the unreachability  
was discovered _could_ (isn't required) de-encapsulate, check the  
mapping for the destination identifier for an alternative destination  
locator, and if one exists, forward it on.

Such in-flight re-routing could be quite helpful for mobility.

Of course, prior to the re-routing, an ICMP-type message would be  
sent to tell the source mapping device that the destination was  
unreachable so the re-routing would only need to be done for those  
packets that were in-flight before the ICMP-type message made it back  
to the source.

> meltdown) need to pay attention to how their stuff does the other  

Yep.

> connections up is probably harder than allowing new connections to  

Not really.  Since connections are established on the identifier, the  
locators used in end-to-end transmission of packets is irrelevant.   
An advantage of the identifier/locator split is that connections can  
be maintained when transitions occur between one locator to another.

> overhead) to make it work - is this an important enough goal?

With the model I'm thinking of, there would be NO additional  
complexity in the end hosts nor (if you don't care about the re- 
routing I mentioned above) in the routers.  Whatever complexity there  
is would be at the point of mapping.

> repeat that several times, with breaks of a couple of weeks in  

20 is probably too many...

Rgds,
-drc

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 9 Dec 2006 21:23:11 +0100

Hi David,

El 09/12/2006, a las 20:07, David Conrad escribió:
> complexity in the end hosts nor (if you don't care about the 
> re-routing I mentioned above) in the routers.  Whatever complexity 
> there is would be at the point of mapping.
>

i am not sure i understand what you have in mind, but the peer that is 
communicating with host within the multihomed site will need to know 
the identifier and all the locators, so it can encapsulate with all the 
different locators, right? If this is the case, the peer (or some box 
near the peer) needs to support whatever protocol are used to securely 
exchange the identifier and locator set. This box needs to be deployed, 
hence, we need support outside the multihomed site, right?

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 10 Dec 2006 10:33:48 +0200

> when the packet reaches a point where the unreachability of the  
> final destination can be determined, the router at which the  
> unreachability was discovered _could_ (isn't required) de- 
> encapsulate, check the mapping for the destination identifier for  
> an alternative destination locator, and if one exists, forward it on.

If I understand you correctly, what you are saying is the following:

1. Consider packets that have two nested headers, the outer one  
carrying a locator and the inner one an identifier.

2. The identifiers have global scope in the sense that any "router at  
which the unreachability [is] discovered" can resolve the identifier  
to another locator.

2a. In order to map the identifier into a locator at any point of the  
network, a global infrastructure for doing the mapping is needed.   
The current IP routing system is one particular example of such an  
global infrastructure (I'm disregarding the well known limitations of  
the IP system here).

Note that this model has been applied already at different points in  
the network in its non-tunnelling and tunnelling forms, cf. e.g.  
MPLS.  Hence, as an architectural pattern it is not new.  Most  
variations can be found on how the infrastructure works.

Now, the problem with this model is security.  The basic attack  
scenario is a DDoS attacker using the re-routing mechanism to  
disperse attack traffic through as many points as possible.  In  
general, either the re-routing point must somehow gain assurance that  
the re-routing in question is legitimate or the packets must somehow  
be self-authenticating, legitimising the re-routing.  The typical  
mechanisms today utilise encapsulation only within one security  
domain (cf. MPLS) or explicitly create some minimal state at the re- 
routing point.

Finally, I would consider such construction tunnelling only if the  
inner and outer header have the same syntax and the locators and  
identifiers are drawn from a single name space (or, at least, from  
syntactically similar names spaces, if you prefer Noel's stricter  
name space definition).  If the headers or identifiers are genuinely  
different, it's not tunnelling but layering, IMHO.

> Such in-flight re-routing could be quite helpful for mobility.

Indeed.  Well known examples of that include Mobile IP Home Agent,  
HIP rendezvous server and SPINAT, and the Previous Access Router in  
Fast MIP.  Each of them does the thing slightly differently, though.   
Typically, in these examples the packet and the infra does not  
contain all of the required state, but only some of it.  Some state  
is explicitly created at the re-routing point.

> packets that were in-flight before the ICMP-type message made it  
> back to the source.

This has even worse potential security problems, as you should be  
able to figure out with a few minutes of pondering.  [I don't  
currently know any way to solve this security problem without having,  
somewhere, some state that includes the the identity of the re- 
routing point.]

> Not really.  Since connections are established on the identifier,  
> the locators used in end-to-end transmission of packets is  
> irrelevant.  An advantage of the identifier/locator split is that  
> connections can be maintained when transitions occur between one  
> locator to another.

I concur.  Getting the required signalling right, efficient, and  
secure, is not that trivial though.  But by now we've done that a few  
times, in a few different ways.

> routing I mentioned above) in the routers.  Whatever complexity  

I'd be very sceptical.  If we had no security problems to deal with,  
I might agree.  However, given that we must plan for a large fraction  
of the net users trying to use any existing mechanisms, and  
combinations thereof, for their own benefit, disregarding the common  
good, things get a lot deal more complex.  In the end of the day, we  
basically need more state that we would otherwise need, and secure  
enough means for setting up that state.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 10 Dec 2006 14:22:11 +0100

El 09/12/2006, a las 17:39, Noel Chiappa escribió:

> C.r, and

yes, that is what i meant.

I mean, this is really difficult problem with multihoming, i think

I can indeed think of mechanisms that would allow initiating new 
communications after an outage has affected one of the paths, that does 
not requires modifications to any device outside the multihomed site.
otoh, i cannot think of any solution that does not require 
modification/configuration to any device outside the multihomed site 
and does keep exisiting connections up through an outage....

> With enough thrust, pigs can fly.

not this one afaict....

if you want to keep existing connections up through outages and not use 
PI, you will need support in the non multihomed peer AFAICT

>  The question is, do you want them to fly?!

very important question indeed

what capabilities are we trying to support?

there is a very big difference in the solutions that try to keep 
existing connections up through outages and just allow initiate new 
communications after an outage...

i think Fred's suggestion of defining what are the goals of a solution 
is really needed in order to understand what are we trying to 
achieve...
> overhead is not reasonable.

right, i was thinking in a new solution (any new solution)

> repeat that several times, with breaks of a couple of weeks in 

what about an interim meeting for this?

interim meeting are nice because only very interested people attend...

regards, marcelo

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Dec 2006 07:04:15 -0500

> One of the reasons I think a tunneling approach is the right 
> way to go is that it allows for in-flight re-routing to 
> occur.  That is, when the packet reaches a point where the 
> unreachability of the final destination can be determined, 
> the router at which the unreachability was discovered _could_ 
> (isn't required) de-encapsulate, check the mapping for the 
> destination identifier for an alternative destination 

I do not think mobility is a special case for this work and it is solved
through current IETF work in multiple working groups now not our concern
here? 

Still thinking about the rest of your response.

Best,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Dec 2006 07:13:37 -0500

Just for the record I do not agree with the security issues Marcelo and
Pekka consistently state at the SHIM6, HIP, or transport layer in
general and we have agreed to disagree on SHIM6.  But for this all
important routing exercise et al I suggest we not cloud the first
incantation of a routing analysis with security until we have something
more concrete to debate regarding the security and we hear all ideas and
thoughts to develop a "model", and then determine the insecure inherent
parts of that model.

/jim

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Sunday, December 10, 2006 3:34 AM
> To: David Conrad
> Cc: Noel Chiappa; [email-masked]
> Subject: Re: [arch-d] Major practical decision
> 
> > One of the reasons I think a tunneling approach is the 
> right way to go 
> > is that it allows for in-flight re-routing to occur.  That is, when 
> > the packet reaches a point where the unreachability of the final 
> > was discovered _could_ (isn't required) de- encapsulate, check the 
> 1. Consider packets that have two nested headers, the outer 
> one carrying a locator and the inner one an identifier.
> 
> 2. The identifiers have global scope in the sense that any 
> "router at which the unreachability [is] discovered" can 
> resolve the identifier to another locator.
> 
> The current IP routing system is one particular example of 
> such an global infrastructure (I'm disregarding the well 
> known limitations of the IP system here).
> 
> Note that this model has been applied already at different 
> points in the network in its non-tunnelling and tunnelling 
> forms, cf. e.g.  
> MPLS.  Hence, as an architectural pattern it is not new.  
> Most variations can be found on how the infrastructure works.
> 
> Now, the problem with this model is security.  The basic 
> attack scenario is a DDoS attacker using the re-routing 
> mechanism to disperse attack traffic through as many points 
> as possible.  In general, either the re-routing point must 
> somehow gain assurance that the re-routing in question is 
> legitimate or the packets must somehow be 
> self-authenticating, legitimising the re-routing.  The 
> typical mechanisms today utilise encapsulation only within 
> one security domain (cf. MPLS) or explicitly create some 
> minimal state at the re- routing point.
> 
> Finally, I would consider such construction tunnelling only 
> if the inner and outer header have the same syntax and the 
> locators and identifiers are drawn from a single name space 
> (or, at least, from syntactically similar names spaces, if 
> you prefer Noel's stricter name space definition).  If the 
> headers or identifiers are genuinely different, it's not 
> tunnelling but layering, IMHO.
> 
> Indeed.  Well known examples of that include Mobile IP Home 
> Agent, HIP rendezvous server and SPINAT, and the Previous 
> Access Router in  
> Typically, in these examples the packet and the infra does 
> not contain all of the required state, but only some of it.  
> Some state is explicitly created at the re-routing point.
> 
> > Of course, prior to the re-routing, an ICMP-type message 
> would be sent 
> > to tell the source mapping device that the destination was 
> unreachable 
> > so the re-routing would only need to be done for those packets that 
> > were in-flight before the ICMP-type message made it back to the 
> > source.
> 
> This has even worse potential security problems, as you 
> should be able to figure out with a few minutes of pondering. 
>  [I don't currently know any way to solve this security 
> problem without having, somewhere, some state that includes 
> the the identity of the re- routing point.]
> 
> > locators used in end-to-end transmission of packets is 
> irrelevant.  An 
> > advantage of the identifier/locator split is that 
> connections can be 
> > maintained when transitions occur between one locator to another.
> 
> I concur.  Getting the required signalling right, efficient, 
> and secure, is not that trivial though.  But by now we've 
> done that a few times, in a few different ways.
> 
> I'd be very sceptical.  If we had no security problems to 
> deal with, I might agree.  However, given that we must plan 
> for a large fraction of the net users trying to use any 
> existing mechanisms, and combinations thereof, for their own 
> benefit, disregarding the common good, things get a lot deal 
> more complex.  In the end of the day, we basically need more 
> state that we would otherwise need, and secure enough means 
> for setting up that state.
> 
> --Pekka Nikander
> 
>

---

From: David Conrad <[email-masked]>
Date: Sat, 9 Dec 2006 20:15:39 -0200

[I've redirected this to [email-masked], bcc'ing arch-d since this is  
talking more about an implementation model than a theoretical model.   
I've gathered the feeling is that discussion about what Noel calls  
the "jack up" approach such as this should occur on ram instead of  
arch-d.]

Marcelo,

Just to be clear, my focus has been to try to come up with a model  
that would minimize the number of changes that would need to be made  
to deployed systems as I believe this significantly improves the  
chances that stuff will actually get deployed.  While I would love to  
see a clean-sheet architecture, I'll admit to being a bit too cynical  
to believe it would ever get deployed.

On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote:
> i am not sure i understand what you have in mind, but the peer that  
> is communicating with host within the multihomed site will need to  
> know the identifier and all the locators, so it can encapsulate  
> with all the different locators, right?

No.  The source "host" would only need to know about the identifier  
of the destination "host" (discoverable via DNS as normal). The  
multiple locators would be bound to the identifier later.  I think it  
is actually fairly important that the "host" _not_ know about  
locators as the alternative is a layering violation that ends up  
causing a lot of problems in the end.

In the model I've argued for, the mapping from identifier to locator  
would occur at the "edge" (where the "edge" could be anywhere from  
the source device to the first hop router to the ISP/end site  
boundary).  At this mapping device/"edge" router, the packet would be  
encapsulated with the destination address being one of the set of  
locators associated with the identifier.  At the destination mapping  
device/"edge" router, the packet would be de-encapsulated and  
forwarded on to the destination identifier.

> If this is the case, the peer (or some box near the peer) needs to  
> support whatever protocol are used to securely exchange the  
> identifier and locator set.

Yes, in the sense that the mapping needs to be propagated somehow,  
either some push mechanism (e.g., a flooding protocol or as a BGP  
attribute or whatever) or a pull mechanism (e.g., something like the  
DNS). If you use the DNS, you could have something like:

; dest identifier                            RR  dst locator pref
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001  100 ...
                                                  b000::0002  200 ...
                                                  c000::0003  300 ...

which could be secured with DNSSEC (assuming it ever gets deployed).

> This box needs to be deployed, hence, we need support outside the  
> multihomed site, right?

I think I see what you're saying.  So, there are 4 cases:

1) unmapped source, unmapped destination: this is what we have now.

2) mapped source, mapped destination: this would be the goal.

3) mapped source, unmapped destination: if the destination is  
reachable via the "legacy" routing system, this would work if the  
mapping service is able to determine that the destination is not  
mapped and fall back to case 1.  For this to work, the source  
identifier would have to be routable, perhaps sub-optimally, in the  
"legacy" routing system.

4) unmapped source, mapped destination: since the source knows  
nothing about mapping, the only way the destination would be  
reachable is if the destination identifier is routable, perhaps sub- 
optimally, in the "legacy" routing system.

Given this, as a transition mechanism, the existing  
"addresses" (which I'm defining to be the merged identifier/locator  
blob of bits we have in the source and destination fields of IP  
packets now) would be treated as identifiers if they are mapped and  
locators if they aren't. The mapping device/"edge" router would make  
the determination on the fly based on whether the mapping succeeded  
or failed.

So, yes, there would need to be some support outside the multi-homed  
site to take advantage of the multi-homing (etc.), but things will  
still work, perhaps sub-optimally, without it.

Rgds,
-drc