RE: about draft-nordmark-multi6-noid-00

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Let's consider the following scenario.
Let's suppose that all ISPs are performing ingress filtering
Also that hosts inside mh sites have assigned one prefix per provider

            +----+
        ----|ISPA|_             +----+
       /    +----+ \_+------+  _|ISPC|_
 +----+              |      |_/ +----+ \__+----+
 | mh1|             _|      |            _| mh2|
 +----+     +----+_/ |      |_          / +----+
       \____|ISPB|   +------+ \_+----+_/
            +----+              |ISPD|
                                +----+

There are two different situations to be considered when addressing locator
reachability issues: initial contact and preservation of the established
communications.

i.) Initial contact

i.i) Initiator's perspective

i.i.i) No failure has occurred

Suppose that mh1 initiates a communication with mh2, so mh1 selects PA:mh1
as initial source address i.e. initial locator and AID1, and also selects
PC:mh2 as destination address and AID2.
The initial packet must be sent with the "rewrite ok" bit not set.
Suppose now that the internal routing of the site mh1 is such that packets
sent to PC:: are forwarded through ISPB. This means that the packet
generated by mh1 described above will be discarded by ingress filtering in
ISPB because its source address is incompatible and cannot not be rewritten.
The question is then, how do you deal with this case? (a tunnel between exit
routers, so that the packet is forwarded through the appropriate isp, an
icmp back to the initiator?)

i.i.ii) A failure has occurred in the link between ISPB and its upstream
provider.

Suppose now that the packet generated by mh1 has PB:mh1 as source address
and PC:mh2 as destination address.
Now, since the internal routing system has information about prefix
reachability through the different ISPs (as you explained, mh1 obtains such
information through some routing protocol), the internal routing system
knows that it has to forward the packet through ISPA, since there is no
route available through ISPB. However, the actual packet has PB:mh1 as
source address, making the packet incompatible with ingress filtering. The
packet then will be dropped. Note that retrying from the application running
in mh1 with alternative address is not good since the problem is not related
to the destination address but it is related to the source address. So, how
do you address this issue? (a new ICMP message back to the initiator host?)

i.i.iii) A failure occurred in the link between ISPC and mh2

mh1 sends a packet to destination address PC:mh2 and any of the source
addresses
PC:mh2 is not reachable and this is not visible by the routing system.
Since it is the initial packet, no feedback from the source address
rewriting mechanism can be obtained.
I guess the only option here is to wait a timeout and let the application at
the initiator to retry. My point is that the routing system will not be able
to deal with all the failure scenarios.

i.ii) Target perspective

Question: the first reply that the target sends back to the initiator, is
the "rewrite ok" bit set or not?

ii) Preserving established communications

Suppose that there is communication established between mh1 and mh2.
Suppose that all the locators are working and that all of them were verified
so they acceptable to be used as valid locators in the communication.
Currently the communication is using PA:mh1 and PC:mh2 as locators.
Suddenly a failure in the link between ISPA and its upstream provider
occurs.
The idea then is that ISPA detects the situation and then it announces the
event to mh1. The internal routing system reconverges and packets are no
longer routed through ISPA but they are routed through ISPB. Since the
"rewrite ok" would be set at this moment of the communication, then packets
that are originated by mh1 with PA:mh1 as source address are rewritten by
the exit router so that PB:mh1 is included as source address. Now mh2 learns
that it has to use PB:mh1 as destination address because this is the address
contained in the packets that it is receiving. Is that ok?
Now my question is how long does this mechanism takes to react? i.e. the
response time. In order to preserve established communications, the
interruption shouldn't be too long. The problem here is that intradomain
routing is pretty slow detecting outages. Suppose that ISPA is running BGP
with its upstream provider, then if i am correct, the value recommended in
the BGP spec to detect an outage between peers is 90 seconds. This means
that the interruption in the communication will be longer than 90 seconds.
IMHO this is not good enough to preserve established communications. Am i
missing something?

My point is that the usage of the routing system to determine which locator
to use and to preserve established communication is not a good option
because:
- It is pretty expensive, since you need to inject the reachability of all
prefixes from the ISPs to the multi-homed site. This may be ok for medium to
big sites, but i am not so sure in the case of a very small site with CATV
and ADSL
- Some failures have to be handled by the host itself, since not all
failures are visible from the routing system because of aggregation issues.
see point i.i.iii
- The main drawback is that the time required by the routing system to
detect outages is simply incompatible with preserving established
communications. This IMHO is a fundamental incompatibility since it is
caused by design choices. I mean, the intra-domain routing system prefers a
bit outdated but stable view of the topology rather than an very accurate
but unstable view of the topology. this implies that the time required by
the routing system to accept a change in the topology will be long, at least
longer that what it is acceptable to preserve an established communication.

It is then my conclusion that path outage detection and locator selection
has to be performed by the end-host themselves and not by the routing
system.

Sorry if this was too long, but thanks for reading so far.

Regards, marcelo

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Erik Nordmark
> Enviado el: sabado, 25 de octubre de 2003 23:20
> Para: mbagnulo@ing.uc3m.es
> CC: Erik.Nordmark@sun.com; multi6@ops.ietf.org
> Asunto: Re: about draft-nordmark-multi6-noid-00
>
>
> > - Are you assuming that the multi-homed site runs bgp with each of its
> > direct providers and that it obtains a full bgp feed from each of them?
>
> Not required.
> You need routing to work for all of the sites locators.
> And for border router rewriting of the source locator to be a useful way
> to detect the working path the site's border routers need to have enough
> information to tell which outbound path to use. Depending on the failures
> you are concerned about this could be as simple as the border routers
> being able to tell whether the link to the ISP is up or down, or it
> could depend on the site receiving each ISPs routing table to see which
> prefixes appear to be reachable over which ISP/link.
>
> I don't think even in the latter case it is necessary to run BGP; if the
> ISP could redistribute a its view of reachable prefixes using a separate
> instance of an IGP running across the border that should suffice.
> (Not that I know if configuring that is much simpler than
> configuring BGP).
>
> But there is no need for the site to advertise anything to its ISPs; each
> ISP only need to know which prefix it has delegated to the site.
>
> > - I understand that ingress filtering compatibility is
> guaranteed by source
> > address rewriting, is that ok? if so, how do handle ingress
> filtering issues
> > when sending initial packets whose source address cannot be rewritten?
> > (rewrite ok bit not set)
>
> I don't think ingress filtering can be made strictly better any time soon
> even if we adopt some multihoming proposal; if an attacker would want to
> exploit holes in IPv6 ingress filtering the attacker could just use
> non-multihoming packets (e.g., TCP over IPv6 as currently defined).
>
> Having said that, if the multihoming protocol performs explicit
> initiator-driven state creation (draft-nordmark-multi6-sim-00.txt is an
> example) instead of having a data packet cause responder state creation
> actions as in noid, then one can make the state creation work
> with "rewrite
> ok" enabled.
>
>   Erik
>
>
>