Subject: Re: New Routing Header!!!

From: "Vishwas Manral" <[email-masked]>
Date: Sat, 1 Sep 2007 16:37:44 +1000

Hi Thomas,

>From mails I see on the list and offline, I see people who seem to say
they want the functionality. One of the reasons the functionality is
probably not present or used as much is because IPv6 deployments
aren't as widely present as IPv4.

That said my way forward would be to recommend the RPF check at the
edge of networks if such functionality is required and firewalling it
as a default case.

Hi Arnaud,

I agree that adding new functionality to any protocol adds new attack
vectors. As a protocol feature designer when adding any new
functionality, I need to see the security aspects of the functionality
too. I do not think every possible attack can be mitigated, but the
idea should be the remaining attack vectors are so CPU intensive/
costly that it would require a lot more effort on the part of the
attacker to carry out an attack. The RH0 attack is not that serious as
some have pointed out, but the ease of making it a lot more dangerous.

Thanks,
Vishwas

On 8/30/07, Thomas Narten <[email-masked]> wrote:
> > However it seems you have probably not followed mails I have sending
> > carefully enough. I have raised this issue on the list way back and
> > got some feed back too. I have found based on feedback the main uses
> > of the RH header to be Explicit Traffic Engineering as well as for OAM
> > purposes (something the IETF has underplayed for a long time). There
> > is a paper by Geoff Huston (I am not totally sure it was him), that
> > gives some use cases for operators.
>
> What I mean by "find a use" or "find a customer", is not to point to
> some generic, hand-wavy "it would be nice" from some third party. It
> is to get the customer/user who has a real problem to solve to come
> and explain what that problem is, so we can talk about about how to
> solve it. Anything short of that risks development of a solution  in
> search of a problem. The IETF has a lot of experience with that, and
> it is mostly negative.
>
> It's easy to find _possible_ uses. What we should be looking for is a
> problem that needs solving, for which a routing header really is a
> good/best solution, not just a "cool" or "neat" solution.
>
> > Having been the one to have identified the amplification attacks
> > around a couple of years ago, I realize the problems and related
> > security issues. However I am not sure of how you say there are no use
> > cases. I got the information asking that very question on the list. It
> > would be great if you can let me know what you base your assumptions
> > on?
>
> RH0 has been part of IPv6 for more than a decade. Remind of _who_ has
> used it or is using it, and what critical applications take advantage
> of it. I believe the answer to the question is pretty much the empty
> set. That is what I mean there being "no use cases".
>
> Thomas
>

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

---

From: [email-masked] (Arnaud Ebalard)
Date: Sat, 01 Sep 2007 10:21:47 +0200

Hi Vishwas,

"Vishwas Manral" <[email-masked]> writes:

> they want the functionality. 

Yes, they say they want the functionality. But even after many repeated
questions, i don't get the purpose or the use. For me, being able to
bounce packets on others' routers towards selected targets is not a 
purpose or a use. Being able to debug a routing issue is.

> One of the reasons the functionality is probably not present or used
> as much is because IPv6 deployments aren't as widely present as IPv4.

Are you implying that the functionality is used in IPv4 networks?

> edge of networks if such functionality is required and firewalling it

You basically speak about ingress-filtering at the scale of Internet. I
wish someone could make that happen but this is only (still) a
dream. For the firewalling part, you mean implementing the mechanism
everywhere (again, for no specific use) to then deactivate processing by
default.

> vectors. 

Adding useless functionalities adds useless attack vectors.

> As a protocol feature designer when adding any new functionality, I
> need to see the security aspects of the functionality too. I do not
> think every possible attack can be mitigated

Why ? 

It's probably true afterwards, but during the design of a functionality,
you can do pretty much everything to prevent a misuse if you have
security in mind. This can be done if you know the purpose of your
functionality (to keep things usable). Here, you don't know what it will
be used for, what the required deployment scale is, .... i.e. you just
want to keep source routing in IP stacks because it seems fun. This is
the way I see current discussions on that topic.

Regards,

a+

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 2 Sep 2007 11:11:18 +1000

Hi Arnaud,

> Are you implying that the functionality is used in IPv4 networks?
Please check the mails on the list. they do seem to suggest exactly that.

> the way I see current discussions on that topic.
Arnaud, I do not want to keep it if it is of no use. But as I said and
have seen mails on the list as well as offline it seems to imply
otherwise. By controlling the amount of functionality we reduce the
attack vectors. That is the entire aim here, to balance the risk to
the rewards.

Thanks,
Vishwas

---

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 02 Sep 2007 13:17:55 +0200

Hi Vishwas, Hi *,

> Please check the mails on the list. they do seem to suggest exactly

Sorry to insist but i'm pretty sure i carefully read all emails of the
threads and I think I would have taken them into account and stop asking
for people using the mechanism. Can you precisely point me to those?

The ones I saw regarding the IPv4 options basically stated that
operators of IPv4 networks all deactivate IP options processing on their 
routers. This is an applied BCP. Regarding users, i don't remember a
single person providing feedback on its use of the mechanism on IPv4
networks (probably for previous reason). I also remember some mails from
itojun and others regarding the inability to use IPv4 options between
Japan and the USA as an example.

> otherwise. 

Can you please give me in one or two sentences (i.e. little effort) the
specific purpose/use those people have. This is the only thing i keep
asking for on the list and no one has still answered with specific use.

I got only claims that keeping the mechanism would allow path selection
or explicit traffic engineering by the source. Those are only generic
ideas. 

IMHO, the most interesting directions is the question of locator/id
separation for which some have hope keeping source-routing in our stacks
today will perhaps help later. This is just a bet and it's not even
asked by the people that currently work at trying to provide that (HIP,
MIPv6, ...). If there was something on the table to explicitly help
solving multi-homing issues, id/locator separation issues or simply
improve addressing issues, i'd be more than happy to help.

> By controlling the amount of functionality we reduce the attack
> vectors. That is the entire aim here, to balance the risk to the
> rewards. 

Exactly. Expressing uses followed by iterations on design decisions will
help balancing the risk to the rewards. Let's start by expressing the
uses. 

Regards,

a+

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 2 Sep 2007 19:14:54 -0400

-----Original Message-----
From: Arnaud Ebalard [mailto:[email-masked]] 

> Can you please give me in one or two sentences (i.e.
> little effort) the specific purpose/use those people have.
> This is the only thing i keep asking for on the list and
> no one has still answered with specific use.

Testing paths between routers that would otherwise be unused in the
current topology, creating separate paths between dual-homed hosts
connected redundantly to a single network infrastructure, routing
certain types of signals on separate paths from other types of signal
(e.g. multimedia streams routed differently from text or file
transfers).

Bert

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 03 Sep 2007 00:58:03 +0100

> (e.g. multimedia streams routed differently from text or file

On your "own" (thus in some way controlled by you) network, or on the
public Internet where you have totally no control over those networks,
and mostly you will not get control as those ASN's are somebody elses?

If your own, then the security question becomes lighter as a special tag
could be added to packets whereby routers know that these packets should
be allowed to do these tricks, otherwise it won't work as you don't own
those people's routers.

And is this being really used or only for research/testing? [y/n]

Greets,
 Jeroen

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 03 Sep 2007 08:31:19 +0200

Hi Albert,           [thanks for trying to answer the question of uses]

>> current topology

Certainly my english but i don't understand that argument. Are you
stating that source routing can be useful to create traffic on link that
are not used otherwise? It can't be that. Can you clarify that point?

>>, creating separate paths between dual-homed hosts connected
>> redundantly to a single network infrastructure

If you consider end-host connected to a specific "Home Network"
infrastructure, this already exists in MIPv6. It works great, even
with IPsec protection. Last evolution (available under Linux for
instance) allows transparent movement of IPsec tunnel endpoints when a
change from a link to another occurs. As a positive side effect, you
even get address stability.

The point here is that if you only want dual-homed hosts connected to
another network you control, you don't need any help from the core, you
only need some help in _your_ network. This function is provided by the
Home Agent in MIPv6 or by your correspondent. I don't state it is the
solution to all problems on earth, but if you don't want to select
specific weird pathes in the core, i.e. only need to get the best
routing path from you current source address to the destination, source
routing in the network is unneeded.

>> routing certain types of signals on separate paths from other types
>> of signal (e.g. multimedia streams routed differently from text or
>> file transfers).

Can you elaborate on that. I imagine that the path in the core will
quite be the same for all flows (modulation below) and that the penalty
occurs mainly between the different connection means you consider. If
you take satcom, wifi or basic ethernet, you get different prefixes
(hence different source addresses) that allow you to select how your
packet will leave the source (this obviously works in both directions,
if you select the right destination). 

[Correct me where i get things wrong] Now, if you expect differences in
the routing at some point (where source routing should occur), this
means that the operator is able and is willing to provide different QoS
for your flows. There is no way you won't be charged for that. This 
basically means that you have some commercial relationship with it and
also basically exclude providers you don't know directly. IMHO, this
also implies that those operators are near your source (your provider ?)
and/or near your destination. Based on all of that, there are probably
other ways to get QoS applied to your flows, and earlier in the network
than expecting source routing to provide that: asking for different
prefixes, for specific guarantees on specific flows based on protocol,
flow label, destination, ...

As a side note, adding MTU, parsing and soft processing is probably not
the best way to get the best results for your flows.

> And is this being really used or only for research/testing? [y/n]

Couldn't agree more.

Regards,

a+

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 3 Sep 2007 18:13:00 -0400

> From: Jeroen Massar [mailto:[email-masked]] 
> 

Definitely on my "own" network. That's what I was alluding to
previously, when I said that not all uses of IPv6 are for ISP networks,
and that therefore the tool kit available should not be aimed
exclusively to ISP-relevant tools.

> be allowed to do these tricks, otherwise it won't work as you 

In principle, I agree with you perhaps. In practice, these RH0 nodes are
already out there.

> And is this being really used or only for research/testing? [y/n]

Both. I don't think the discussion should devolve into one of arguing on
the merits of specific implementations of source routing. IMO, it exists
today, there are legitimate uses for it (even if not on the public
Internet), so now the only discussion should be how best to keep it from
doing harm in newtworks where it can do harm. No different from other
examples I gave, such as directed broadcast and TELNET, neither of which
has been deprecated.

Bert

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Sep 2007 11:29:27 +1000

Hi Arnaud/ Jeroen,

> > And is this being really used or only for research/testing? [y/n]
What do you think after reading Bill Fumerola's mail? I think the
example he has given is of deployed scenarios.

Thanks,
Vishwas

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 04 Sep 2007 09:28:21 +0200

Hi bill, Hi Stig, Hi *,

bill fumerola <[email-masked]> writes:

> On Fri, Aug 31, 2007 at 03:58:54AM +0200, Stig Venaas wrote:
>> I'm not arguing for keeping source routing here, but one quite useful
>> thing it can be used for is traceroute. You can for instance trace from
>> a remote point in the network towards yourself. This can be very helpful
>> when debugging routing problems.

First, thank you both for the feedback.

Having spent quite some time doing that on the IPv6 internet, i basically
got to the conclusion that if you don't precisely know the router you
send your packets to (the waypoint that will bounce your traffic based
on RH content), you spend more time debugging the reaction of that
router than what happens on the path. There are routers that drops
traffic, others that reply with ICMPv6 error packets indicating an
administratively prohibited condition, others that don't have a route to
your next destination, others that do have a route (default ?) but which
won't go far, etc 

When you include multiple waypoints, this gets even more difficult to
get some precise information (Even if your tool does not try to be smart
on what comes back).

I understand the interest and like the boomerang traceroute too but i'm
surprised network operators do not have better tools than that to debug
and monitor things.

> engineers also can use it when setting up, debugging, or for periodic
> testing of peering sessions to make sure that the other side isn't doing
> anything against the contractual terms of the peer (e.g. overriding the
> normal policies that result from standard RIB->FIB route selection).
>
> examples:
> http://ptd.mbo.ma.rcn.net/peerinfo/
>
> All peers are requested to enable LSRR on router interfaces facing RCN
> peering sessions to facilitate network diagnostics at least during session
> activation.
>
> http://www.via.net/support/support_peer.html 
> We require that our peers permit LSR, loose source routing, at least at the border.
>
> http://www.noc.wiscnet.net/peering/
> We require that our peers permit LSR, loose source routing, at least at
> the border for diagnostic purposes.

Some questions:

- can anyone send LSR traffic to those routers? is it limited?  
- If it is limited in some way, how is it done? 
- What tools do you use to test that and what is the frequency of use?
  (Only traceroute when you have a doubt?)

> i don't have an ACM account, but:
> http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=1016718

Don't have either. I won't give credit only based on the abstract ;-)

> without comparable functionality in IPv6, we lose a feature actively in
> use (through IPv4) by some networks for verification of proper peering.

Is there any place one can ask operators or people that provide peering
at exchange points on that. Basically, my question is: is there any
consensus on the use of source routing among those people? I know people
that prohibit their use.

> if i'm out of touch with current policies on peering & LSRR, please let
> me know.

a+

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 04 Sep 2007 18:26:48 +0100

[..]

> exclusively to ISP-relevant tools.

That is exactly why I asked :)
It narrows down the problem space a lot!

> In principle, I agree with you perhaps. In practice, these RH0 nodes are

For this to be possible though, vendors will have to have RH0
implemented, but disabled per default. As you configure all these nodes
(and I expect only the routers to be affected, not endhosts), these
should provide a simple toggle for turning this behavior on.

And I guess that we have made you, and quite some other people, totally
happy. You will of course want to do something like a filter on your
borders rejecting RH0 based packets there, or some kind of ignoring stance.

Arnaud Ebalard wrote:
[..]
> I understand the interest and like the boomerang traceroute too but
> i'm surprised network operators do not have better tools than that
> to debug and monitor things.

And RH0 is not meant for this purpose IMHO.

Something which most likely can achieve the desired effect is:
http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00040.html

Especially as those are ratelimmited and controlled by the NOC that
operates that service, which also means you can actually contact them
when there is such a problem.

Are there any people here who think that is a good idea, as there where
no bad comments, I could try and push it forward in RIPE so that we have
a standardized, easy-to-find way of finding these resources.

Greets,
 Jeroen

---

From: bill fumerola <[email-masked]>
Date: Tue, 4 Sep 2007 17:11:03 -0700

> asking for on the list and no one has still answered with specific use.

will you read it this time?

as i stated in my previous post, source routing is used at peering points
to test/verify paths being given by bgp match the paths being taken by
packets. given multiple different types of topologies (different layer2
setups, route server v. mesh) at the peering points source routing
provides a one-size-fits-all way of testing.

-- bill