Subject: Fwd: draft-baker-6man-multiprefix-default-route-00.txt is a new draft

From: Fred Baker <[email-masked]>
Date: Thu, 8 Nov 2007 09:15:40 -0800

This is something that came out of some of the SAVA work, but also  
has relevance to the RFC 3704 discussion. I'd be interested in the  
working group's thoughts.

Begin forwarded message:

> From: [email-masked]
> Date: November 8, 2007 2:01:04 AM PST
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-baker-6man-multiprefix-default-route-00.txt is a new  
> draft
>
> You posted a new draft today. In the interest of informing your Cisco
> colleagues, would you be so kind as to fill the rest of us in on your
> project and what the draft is about?
>
>    http://www.ietf.org/internet-drafts/draft-baker-6man-multiprefix- 
> default-route-00.txt
>   "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker, 7- 
> Nov-07,
>   <draft-baker-6man-multiprefix-default-route-00.txt>
>
>
> The abstract you included reads:
>
> This note addresses routing in a network that supports multiple
> prefixes and has different DMZs, in the context of BCPs 38 and 84
> (ingress filtering).  It proposes a change to the way IPv6 forwarding
> occurs, and so should be considered carefully by the Internet
> community.
>
> There is more background at http://wwwin-people/fred/explanation.html
>
> By the way, if you're not on ietf-interest, you may find it an
> interesting list to join.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Nov 2007 13:27:12 +0100

Hi Fred,

AFAIU, you are essentially proposing to perform source address based  
routing by the hosts and by the routers in a multiprefix site, is  
that correct?

Regards, marcelo

El 08/11/2007, a las 18:15, Fred Baker escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> Subject: draft-baker-6man-multiprefix-default-route-00.txt is a  
>> new draft
>>
>>    http://www.ietf.org/internet-drafts/draft-baker-6man- 
>> multiprefix-default-route-00.txt
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFHM0Q8bjEdbHIsm0MRAi8jAJ0XM5Ls6OoIQAVBPk/qQW/R0hqiiQCfUXTQ
> waLbY1/Hkr/O7UdfYXZTNVk=
> =6V2r
> -----END PGP SIGNATURE-----
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Nov 2007 13:39:55 +0000

On Nov 12, 2007, at 12:27 PM, marcelo bagnulo braun wrote:

> AFAIU, you are essentially proposing to perform source address  
> based routing by the hosts and by the routers in a multiprefix  
> site, is that correct?

I don't like the term, because I first do a destination lookup and  
only look up the source address in certain cases. Kind of like the  
previous comment on source routing, which in IEEE 802.5, DSR, and RFC  
791 IP means that the source specifies all or part of the routing  
path. I think the term mis-states the case.

But yes, in certain cases where there is a multipath route, the point  
is that if the datagram is handed to the wrong ISP and the ISP is  
doing ingress filtering, the datagram will be dropped, and hence I  
suggest that we direct it toward the right ISP.

Is there something wrong with that? Would you prefer it be dropped as  
it leaves the site? Would you prefer that the matter be indeterminate?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Nov 2007 16:05:59 +0100

Hi Fred,

El 12/11/2007, a las 14:39, Fred Baker escribió:

> only look up the source address in certain cases.

i understand that it is done when the destination is off site and  
there are multiple routes to the external destination. So in a  
regular multihomed site that accept default routes from each ot its  
ISPs, basically, source address dependent routing is performed for  
all packets with an external destination, right?

> Kind of like the previous comment on source routing, which in IEEE  
> 802.5, DSR, and RFC 791 IP means that the source specifies all or  
> part of the routing path. I think the term mis-states the case.
>

agree, that is why i normally use Source address dependent routing  
instead of source routing

> But yes, in certain cases where there is a multipath route, the  
> point is that if the datagram is handed to the wrong ISP and the  
> ISP is doing ingress filtering, the datagram will be dropped, and  
> hence I suggest that we direct it toward the right ISP.

right

>
> Is there something wrong with that?

i don't know....

I have proposed a very similar thing in http://tools.ietf.org/id/ 
draft-ietf-shim6-ingress-filtering-00.txt

but it got quite some push back and we finally dropped it from the  
shim6 wg. I would be interested to continue working on this,

regards, marcelo

> Would you prefer it be dropped as it leaves the site? Would you  
> prefer that the matter be indeterminate?
> iD8DBQFHOFerbjEdbHIsm0MRAh89AKDO1FiDeHknTEpXSwl0SP30BXSxXwCgj389
> ovysRXKu7Rr1wrO93DvioZQ=
> =u6Oy

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 12 Nov 2007 17:27:00 +0100 (CET)

> suggest that we direct it toward the right ISP.

But still, you appear to propose to fundamentally change the
forwarding process by inserting a relatively complex lookup
operation into per-packet forwarding, and I think such a change
needs quite a bit more in terms of justification.

Instead, my inclination would be to "solve" this problem in a
much simpler manner, simply by declaring it a configuration
error.  A site which receives prefixes from more than a single
provider is clearly multihomed, and needs to have its providers
make appropriate exceptions to a strict "I will only accept
packets with source addresses from within the prefix I delegate"
rule.  Either that, or the domain in question needs to ensure via
a combination of address selection and routing policy that one
avoids being subjected to (presumably unwanted) RPF failures.

Regards,

- Håvard

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Nov 2007 17:33:48 +0100

Hi Havard,

> avoids being subjected to (presumably unwanted) RPF failures.

but which type of sites do you think will have such configuration? I  
mean, i would expect that very small multihomed sites may end up with  
this configuration, e.g. a home network with dsl and CATV access.
So in this case, i am not sure if the trust needed to release the  
ingress filters will exist, so i am not sure the isp will agree to  
release them

Regards, marcelo

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 12 Nov 2007 13:28:05 -0500

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Monday, November 12, 2007 8:40 AM
> To: marcelo bagnulo braun
> Cc: IETF IPv6 Mailing List
> Subject: Re: 
> draft-baker-6man-multiprefix-default-route-00.txt is a newdraft
> 

I found nothing objectionable at all in the draft.

Matter of fact, it seems to address something that also occurs with
IPv4, with multihomed hosts. And that apparently, some OSs screw up
royally. Which is, if a multi-homed IPv4 host, connected to two
different IP subnets, transmits an IP packet over Subnet A, it often is
found to use as source address the address assigned to its Subnet B
interface.

Whether or not this behavior results in total comm failure does not
preclude that is seems just plain wrong.

I agree that calling this "source routing." or anything similar, would
be misleading.

Bert

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Nov 2007 22:52:26 +0000

On Nov 12, 2007, at 4:27 PM, Havard Eidnes wrote:

> Instead, my inclination would be to "solve" this problem in a much  
> simpler manner, simply by declaring it a configuration error.  A  
> site which receives prefixes from more than a single provider is  
> clearly multihomed, and needs to have its providers make  
> appropriate exceptions to a strict "I will only accept packets with  
> source addresses from within the prefix I delegate" rule.  Either  
> that, or the domain in question needs to ensure via a combination  
> of address selection and routing policy that one avoids being  
> subjected to (presumably unwanted) RPF failures.

You have read RFC 3704, right? You're aware of the routing issues here?

I think the provisions in that are quite a bit for the SOHO, and  
residential broadband providers tend to be reticent to do anything  
like what you suggest. Hence the comment. I would like to see a  
better solution than the one you are proposing.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Nov 2007 07:27:00 +0200 (EET)

On Mon, 12 Nov 2007, Havard Eidnes wrote:
> rule.

Who's watching the watchers?

An architecture where you depend on the first hop ISP to do filtering 
and you cannot check that it has been done further down the network 
doesn't do enough to keep ISPs "honest".

   Either that, or the domain in question needs to ensure via
> avoids being subjected to (presumably unwanted) RPF failures.

I think Fred's solution is proposing a solution in (mostly) simpler 
scenarios which are typically unmanaged.  A default policy, if such 
could be created, shipping in smaller routers could fulfill this goal.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 Nov 2007 13:16:00 +0100

Hi Albert,

> found to use as source address the address assigned to its Subnet B

Please note that the situation that this draft addresses is somehow  
different than the one you mention, since both addresses (with  
possible different prefixes) can be assigned to the same interface

So if different interfaces have different addresses and when the host  
sends a packet through a given interface using the address of the  
other one as source address, this is easier to solve, since you only  
need to honor the address assigned to the outgoing interface

However when both addresses are assigned to the same interface, it is  
harder to do the selection and it is likely that additional  
(external) information is needed e.g. the next hop router or the exit  
ISP), which is a harder problem imho, and i guess this is what Fred's  
draft addresses

THe result is that you end up routing packets taking into account  
their source address, which is different than what is done today.

This basicallly means that for some packets (packet with external  
destiantion address) the exit ISP selection is performed by the hosts  
and NOT by the intra site routing system. Moreover, failures will  
need to be taken care of by the hosts itself, bascially retrying with  
a different source address

While i think all this is very good, i think it is imporntat to state  
up fron the concequences of this change and compare them with current  
practices.

I certainly agree with Fred with the fact that if you don't do  
something like this, then you rpobably will have to drop packets due  
to ingress filtering incopatibility

Regards, marcelo

---

From: James Carlson <[email-masked]>
Date: Tue, 13 Nov 2007 07:46:28 -0500

> found to use as source address the address assigned to its Subnet B

I don't agree that those OSes "screw up royally."  They are, in fact,
doing what their users *tell* them to do.

If an application binds the source address on Subnet B and then sends
a packet with a destination address that's either best reached or
*only* reachable over Subnet A, then what's the system to do?  Should
it send it over Subnet B -- in violation of the local forwarding table
-- and hope the next hop router can deal with the problem?  Should it
disregard the application's source address binding and set the source
address to conform with the output interface?  Should it just drop the
packet and pretend it can't send anything?

No matter what the system does here, it ends up violating basic
functional expectations that the user may have, and that's a Bad
Thing.

I agree that the underlying problem is common and one worth solving,
but I think doing so needs optional OS features to allow the user to
specify which expectations can be violated and under what conditions.
That sounds vaguely outside the normal IETF boundaries to me.

(The underlying problem is, to me, just a lack of reasonable routing
policies.  If a site is multihomed like that, then, at least in a
perfect world, both ISPs would know about _both_ subnets in use, and
that the same customer has a legitimate claim on both.)

> I agree that calling this "source routing." or anything similar, would

It *is* making packet routing decisions based on the source address.
Perhaps that's not exactly the same as "source routing" used in other
contexts, but for the first hop, it's the same thing.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Nov 2007 10:42:39 -0500

> From: James Carlson [mailto:[email-masked]] 

> *only* reachable over Subnet A, then what's the system to do?

I think that Fred's draft tries to prevent applications from making such
mistakes. Seems to me that whether the host is dual-homed on two
separate interfaces, or multi-homed on various IP subnets on the same
physical wire as Fred's draft discusses, is not all that different.

> contexts, but for the first hop, it's the same thing.

I'll concede your point on the first hop.

Bert

---

From: James Carlson <[email-masked]>
Date: Tue, 13 Nov 2007 10:58:54 -0500

> physical wire as Fred's draft discusses, is not all that different.

In my answer, and based on the context, I was addressing the "screw up
royally" comment.

I agree that -- as the draft says -- when you've got a choice among
multiple equivalent routes, choosing the one associated with a router
that gave the original prefix used for the chosen source address is
goodness.

If anything, I'm pointing out that this isn't always possible, and
that users often get what they asked for rather than what they wanted.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 12:02:10 +0100

On 13 nov 2007, at 13:46, James Carlson wrote:

>> royally.

> -- and hope the next hop router can deal with the problem?

No, of course not. But how often do applications bind a socket to a  
specific source address? Even for daemons this is not a given.

The situation that needs addressing is the one where through  
configuration mechanisms such as router advertisements a host  
configures multiple addresses and also multiple default routes, and  
after that, the host picks a source address and a default route that  
don't "match" while such a match is enforced upstream in the network.

The simplest example of how this happens is when you have two routers  
with two independent connections to the outside world that both send  
out RAs for a prefix delegated by the ISP that router connects to.

> functional expectations that the user may have, and that's a Bad

Right. There's also the case where the application or part of the  
system knows about different addresses and tries to probe for a  
combination of source address, destination address and route that  
works. (Such as the shim6 REAP protocol is designed to do although  
REAP doesn't know about routes.) So it should clearly be possible to  
send packets that don't conform to the source address / route  
alignment. However, having this alignment by default would be good.

I'm not so sure that routers correcting "misbehaving" hosts here by  
selecting a different route based on the source address is a good  
default behavior, though, as this could make for a performance hit.

> that the same customer has a legitimate claim on both.)

That's not going to happen. Even in cases where you pay an ISP $$$$ it  
can be hard to get this done. When you pay an ISP $$ this isn't even  
remotely an option unless we can come up with an automated way of  
opening up ingress filtering holes. And something like that would take  
many years to see wide deployment.

> contexts, but for the first hop, it's the same thing.

Source routing = the source determines (part of) the path packets take  
through the network

Source address dependent (SAD) routing = routing decision at this  
particular hop may be influenced by the source address in the packet

They are very different.

---

From: James Carlson <[email-masked]>
Date: Tue, 20 Nov 2007 06:36:55 -0500

> alignment. However, having this alignment by default would be good.

Yes, I agree that getting the alignment where possible is good.

> default behavior, though, as this could make for a performance hit.

I don't think avoiding that performance hit is a possibility.  Section
2.3 of the draft discusses exactly this issue and offers forwarding at
each hop based on the source address as a resolution.  Every router
with multiple routes to a given destination will need to deal with
this.

That appears to come to the same result, at least in terms of looking
up the right answer.

The proposal seems to me to have a lot of sharp edges.  For instance,
if one of those upstream routers advertises a more specific route (not
just the default route), then forwarding will find this one route
first, even when the source address doesn't match that path, and even
when some *other* router advertising a less-specific route would be
able to forward the packet correctly.

The draft suggests that source address comes into play only when the
routes are equal -- multipath routes.  Given the likely failure modes,
I'm not sure I understand whether, why, and when the source address
ought to be given a lower weighting than the destination address.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2007 14:17:17 +1300

> 2.1.  Host selection of an address
> 
>    [RFC3484] describes an architecture by which a network administrator
>    can define which source address prefixes should be used on datagrams
>    sent to various destination prefixes.  This proposal assumes that if
>    remote non-default prefixes are propagated within a network, this
>    technology governs the choice of address.  As such, traffic headed to
>    destinations for which there is routing other than the default route
>    will never be sent to an upstream that will discard them.

Hmm. Is it really that simple? If so, why do we have
draft-bagnulo-6man-rfc3484-update and
draft-arifumi-6man-addr-select-sol? In fact, is it really possible
to avoid some sort of reachability probe?

> 2.2.  Host selection of a router
...
>    if DHCP [RFC3315] is in use, it may be possible to rely on the Router
>    Advertisements bring broadcast periodically.  This case requires
>    further thought.

Wouldn't this be an argument for recommending that RAs SHOULD be
sent if a site has multiple prefixes in use, regardless of DHCP usage?

    Brian