Subject: Checks for amplification attack

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Jun 2007 11:33:37 -0700

Hi,

We have posted a draft which checks for loops in the source routed
header. It works for nearly all the cases. The reason is in case a new
header is added to replace the RH0, or if the RH0 is not deprecated
(for reasons that it is required by the management) then we can as
well use the checks in the RH0 header itself.

Such packets should however be rate limited and such checks will
probably best be performed by software.

http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt

Thanks,
Vishwas

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

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 03 Jun 2007 20:11:12 +0100

> http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt

Properly configured uRPF already solves most of the routing loops.

Section 3 very shortly describes a method of 'checking if the packet
goes through a router twice', but it doesn't actually explain how it
can be accomplished, it only explains that one can't because there is
no 'routing identifier'.

The second paragraph of section 3 in effect describes performing uRPF
on the RH0 header.

Also, if you would check for a loop, the typical "management" use of
RH0 (read: traceroute6) stops working, as in most cases the packet
will come back over the same path as it was sent.

Greets,
 Jeroen

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Jun 2007 19:20:36 -0700

Hi Jeoren,

The idea is that for every router the packet goes through, we need to
check the IP address of all the interface addresses, and make sure
that the none of the interface address either before or after in the
source routing header match any of the IP address of the packet.

Yes RPF check could be helpful too. But I am unsure how it would
behave in case of ECMP other other anomaly cases.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Jun 2007 20:01:43 -0700

Hi Joeren,

After thinking a while I realized that, by talking about RPF
everywhere you miss a very basic point. Internet routing is
essentially assymetric in nature. So the path taken for a packet from
source A to B is not the same as one taken from B to A. RPF works at
the edge in my view but not on all routers. Having worked on routing
protocols I know that for a fact.

Do let me know what you think?

Thanks,
Vishwas

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Jun 2007 08:13:48 +0300 (EEST)

> source routing header match any of the IP address of the packet.

Not sure whether this is worth doing in the first place, but just to 
get the story straight:

By 'goes through', do you also intermediate routers which are do not 
need to process the routing header in any way (i.e.: are never in 
"Destination Address" field of the routing header)?

If yes, this would require punting packets from hardware forwarding to 
the control processor which is IMHO a non-starter.

> behave in case of ECMP other other anomaly cases.

Maybe Jeroen meant to refer to ingress/egress filtering in general, 
not just uRPF.  Strict uRPF is usually applied around the edges of the 
network (where the size and definion of 'network' varies).  Other 
kinds of ingress/egress ACLs (usually static / automatically generated 
ones) can be better applied at peering/upstream/etc. borders.  Having 
such ACLs prevents almost all RH0 looping abuse.  (There is a scenario 
Gert Döring mentioned where you loop between backbone routers within 
the target organization but that can be eliminated by disabling RH0 
processing in that organization's routers' control plane).

-- 
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: "Vishwas Manral" <[email-masked]>
Date: Mon, 4 Jun 2007 08:23:03 -0700

Hi Pekka,

> the control processor which is IMHO a non-starter.
Having a background on ASIC design for packet forwarding, I believe
that is exactly what is done for packets that need to be processed in
some exceptional behavior. Its a very very normal case. The other case
is to process the packets in the embedded processors, using some
firmware.

Can you explain why the above design is a non-starter?

Thanks,
Vishwas

---

From: "Ebalard, Arnaud" <[email-masked]>
Date: Mon, 4 Jun 2007 17:59:59 +0200

Hi Vishwas,

> source routing header match any of the IP address of the packet.

Can you tell me if I understand correctly by commenting that example:  
for every packet that includes a Routing Header with something like  
88 addresses in it (feasible with a 1500 PMTU), a router with 5  
addresses will check every address it is configured with against  
those 88 ones (440 comparisons). With 100 Mbit/s of traffic, the  
router can see almost 9000 such packets per second. Where I come is  
that it will have to perform something like 4 millions IPv6 address  
comparison per sec, and in slow path. Is that correct ?

Regards,

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 4 Jun 2007 09:34:33 -0700

Hi Arnaud,

You nearly got it right. Only small thing however is such packets will
be rate limited to the CPU (software), so we will drop all packets not
conforming to the rate limiting.

The reason it will be used is only for management purposes only (hence
the header should never be used for data traffic - which seems like
the only reason why people want to use the routing header).

Thanks,
Vishwas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Jun 2007 09:25:47 +0300 (EEST)

> Can you explain why the above design is a non-starter?

As an operator, I do not wish to buy routers that are DoS'able or 
whose control processor CPU resources can be wasted on inspecting 
transiting traffic. "Punting packets to the slow path" is one primary 
thing that a high-speed router should not have to do.  I think I'm not 
alone in the operator field with this sentiment.

Oh yeah, hop-by-hop extension header should be retired as well :-)

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 7 Jun 2007 14:21:44 -0700

Hi Pekka/ A+,

> The packets you want to rate limit are the one addressed to the
> router that include a RH0, not the one that are flowing through (dst
> address of IPv6 packet is not one of the router), right ?
Its slightly more complicated. By checking only at the destination
addresses, we reduce attacks, except for the case where someone knows
intricate details of IP routing. By checking in all nodes, we further
reduce the probability of all such attacks. If as Pekka said we do not
want to process the packet on all intermediate nodes, we could as well
only process the packet at the destination.

Pekka I agree with your sentiment regarding the below.

> alone in the operator field with this sentiment.
My aim has been to try and salvage the functionality present in the
RH0 header, without having to still deal with the attacks. The router
is not DoS'able as streams to the CPU can be ratelimited. I had
pointed out checks that can reduce the kind of problems that have been
discussed on the list. If the same checks can be done in the hardware/
embedded processors that would be ok too.

Thanks,
Vishwas

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 8 Jun 2007 00:42:08 -0400

> alone in the operator field with this sentiment.

you are not alone.

> Oh yeah, hop-by-hop extension header should be retired as well :-)

i hate to sound heretical, but perhaps having an option to 'not
process', one to 'process' and one to 'drop if having' is called for?
I need to read the jabley-draft I think now too.