Subject: [SAVA] Re: [Int-area] Call For Participation and Interest: Source Address Validation Architecture (SAVA)

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon Sep 18 22:44:06 2006

What you described is BCP38. OK. Done.

Everything else are techniques/features/functions to implement BCP38. We
know that BCP38 works. We've got a lot of experience with it and there
has been a lot of innovation to enhance BCP38 (BCP38 ++) so that you
"know" the source address came from an authorized source (i.e. in the
world of Cable and ETTX/Metro/Carrier Ethernet). 

So back what is the point of Sava? I'm not seeing anything new? Pekka's
worked on an BCP 38 experiences docs. RIPE is working on a BCP38 config
guide.

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:07 PM
> To: Pekka Savola
> Cc: Jun Bi; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and 
> Interest: Source Address Validation Architecture (SAVA)
> 
> Pekka,
> 
> You raise some very fundamental questions about SAVA. I will 
> try to enumerate and answer them. If I get any of the answers 
> wrong, I invite the SAVA contributors to step up and correct me.
> 
> First, you ask what it means for a packet to have a "valid 
> source address". It means that there is some degree of 
> certainty that the packet originated at a site to which the 
> address was assigned by a legitimate numbering authority. 
> This is a much stronger statement than an alternative 
> definition, which claims only that the packet is not spoofing 
> some well known address (for example, one of your own 
> backbone addresses).
> 
> The degree of certainty that source address filtering and 
> uRPF can provide is inversely proportional to the number of 
> hops between the validating and originating devices. So, 
> (although this might be anticipating solutions), the SAVA 
> architecture will probably include a source address 
> filtering/uRPF component that will be implemented by upstream 
> routers, and a signature component, by which the upstream 
> router notifies downstream routers that validation has (or 
> has not) occurred.
> 
> Next, you ask what network resource are protected by SAVA. I 
> think that the answer is the entire Internet, but especially 
> the routers that are close to the validating nodes. This is 
> because SAVA can identify all of the following classes of 
> spoofed packets:
> 
> a) spoofed packets that are bound for routers (in the local 
> or remote AS)
> b) spoofed packets that are bound for hosts, but cause router 
> interfaces to congest.
> 
>                                      Ron
> 
> 
> 
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/routing-discussion
>

---

From: miw at juniper.net (Mark Williams)
Date: Wed Sep 20 01:56:12 2006

The issue is not whether BCP38 works or not if applied. It does, and 
that is not in dispute.

The issue is whether it will ever be applied in its current form in 
enough places to make enough difference. As things are, it doesn't look 
as if it will be. Recommended source filters have been around for more 
than a decade now - I remember applying them to my network back in the 
first half of the 1990s. Despite this we still have a situation where 
approaching a quarter of the endpoints in the Internet can get a spoofed 
source address into the network. There are several attacks out there 
that require a spoofed source address, and many more that are much 
harder to shut down if they do use spoofed source addresses. What's more 
there are zombies out there that can detect the ability to use spoofed 
source addresses and operate accordingly.

A medicine that the patient is not taking cannot effect a cure.

One area of focus for SAVA is to actually create stronger incentives to 
operators to apply source filters. A second focus is to come up with a 
system which works if coverage does not approach 100%. BCP38 does not 
work because if 25% of the network is not covered, then the blackhats 
can just choose where to launch the attack from.

SAVA does not claim to be aiming to solve every security problem in 
today's Internet. It is looking to significantly reduce one kind of threat.

I think there are three questions that need to be asked here:

1. Does the ability to insert packets with spoofed source addresses into 
the Internet represent a threat? (I think it does).

2. Are there measures currently in use that look likely to solve the 
problem? (I think not, but agree there are measures that would work if 
incentive to deploy could be made sufficiently great.)

3. Would it be a good thing if there was a coordinated effort to improve 
the situation for IPv6 while it is still at a low level of deployment? 
(I think it would.)

cheers,

Mark

Barry Greene (bgreene) wrote:
> SAVA mailing list
> [email-masked]
> http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
>

-- 
"Product roadmap and/or product discussion in this email set forth
Juniper Networks' current intention and is subject to change at any
time without notice.  No purchases are contingent upon Juniper
Networks delivering any feature or functionality expressed or implied
in this roadmap or product discussion."
-----------------------------------------------------------------
Mark Williams                        Juniper Networks
Liaison                              Beijing Office
Academic Networking Sector           Tel: +86 10 6528 8800 x16032
Asia Pacific                         FAX: +61 7 3251 0155
[email-masked]                      Cell: +86 1370-111-4749

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed Sep 20 02:16:27 2006

>>>>> "Mark" == Mark Williams <[email-masked]> writes:

    Mark> 3. Would it be a good thing if there was a coordinated
    Mark> effort to improve the situation for IPv6 while it is still
    Mark> at a low level of deployment? (I think it would.)

I think thisquestion misses a lot of complexity.

I think it depends very much on what the effort is.  How does it
affect end-user privacy and freedom?  How does it affect anonymous
traffic?  (I'll accept that you don't need to support spoofed source
addresses to have reasonable levels of anonymity, but I am less
willing to accept that universal cryptographic authentication would be
good.)  What new threats are created?  How does it affect business
models?  Does it create any new concentrations of power and if so,
what checks and balances are in place for these new concentrations of
power?

--Sam

---

From: miw at juniper.net (Mark Williams)
Date: Wed Sep 20 02:40:46 2006

I agree the question glides over a lot of the complexity. It is a 
complex problem with lots of ramifications and I wanted my post to be 
readable inside a few minutes. I share you concerns about end-user 
privacy and freedom and I have lots of problems with universal 
cryptographic authentication from a technical feasibility point of view 
as well as a privacy point of view.

But if you look at it in another way, there are solutions that could be 
imposed that are very threatening to privacy and in the current climate 
there are people who would like to impose them.

I would prefer to see the effort to solve an infrastructure security 
problem that is in itself essentially orthoganal to privacy solved in a 
forum that is known to care deeply about privacy issues than in 
alternative forums that if you were to be generous you would say they 
don't care.

cheers,

Mark

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed Sep 20 03:28:01 2006

>>>>> "Mark" == Mark Williams <[email-masked]> writes:

    Mark> I agree the question glides over a lot of the complexity. It

    Mark> But if you look at it in another way, there are solutions
    Mark> that could be imposed that are very threatening to privacy
    Mark> and in the current climate there are people who would like
    Mark> to impose them.

One of the key things I take away from RFC 3935 (the IETF Mission
Statement) is that the IETF engages when it believes it can do a good
job of designing a solution.

That's a stronger requirement than we engage when we believe we can
make less of a mess than someone else.

So, at least to sell me on the proposal, you need to show me that that
we're actually going to make things net better, not that we'll make
them less net bad that someone else.

Just giving you my evaluation criteria as someone who may be in a
position to evaluate a charter in this space.

---

From: kempf at docomolabs-usa.com (James Kempf)
Date: Wed Sep 20 11:51:07 2006

> operators to apply source filters.

I think this is the key issue. Until there are stronger incentives to put 
source filters in place (or, shall we say, stronger disincentives to not put 
them in place), there will always be some percentage of operators who just 
don't do it. The incentives have to be really strong, though, if you want to 
get 100% coverage.

> A second focus is to come up with a system which works if coverage does 
> not approach 100%. BCP38 does not work because if 25% of the network is 
> not covered, then the blackhats can just choose where to launch the attack 
> from.
>

IMO, address spoofing is not really a technical problem, it is a 
social/political/legal/regulatory one, given there is a known solution. It's 
possible that there might be a technical solution that doesn't require 100% 
coverage, but it is likely to be much more complicated, making it even less 
likely to get deployed.

If the primary issue is how to get operators to universally deploy source 
filters, which isn't a technical issue, then is there really anything that 
IETF can do?

            jak

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Wed Sep 20 16:24:07 2006

> filters, which isn't a technical issue, then is there really anything that 

Well, we could try to figure out whether there are {better, more 
reliable} solutions for deploying source filtering between ISPs. I'm 
not sure if we could be successful in that, but that might create an 
incentive if a network could get effectively filtered by its peers and 
upstreams even if it didn't filter itself.

-- 
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: lear at cisco.com (Eliot Lear)
Date: Wed Sep 20 17:23:48 2006

Sorry for such a dense question, but can someone point me to the SAVA
draft?  I can't seem to find one...

Eliot

---

From: junbi at tsinghua.edu.cn (Jun Bi)
Date: Wed Sep 20 18:46:05 2006

The related documents are located on http://narl.tsinghua.edu.cn/sava/

Regards,
Jun Bi

---

From: kempf at docomolabs-usa.com (James Kempf)
Date: Thu Sep 21 00:51:52 2006

>> filters, which isn't a technical issue, then is there really anything 
>> that IETF can do?
>
> Well, we could try to figure out whether there are {better, more reliable} 
> solutions for deploying source filtering between ISPs. I'm not sure if we 
> could be successful in that, but that might create an incentive if a 
> network could get effectively filtered by its peers and upstreams even if 
> it didn't filter itself.
>
> -- 

Here's an idea (which, BTW, I'm not adovocating). ISPs agree that if they 
detect spoofed packets from someone they cut off forwarding to/from that AS 
until the problem is fixed. Really simple and modestly straightforward to 
deploy, but not a technical solution. It requires the RIRs and operator 
associations to issue a policy, and the operators to agree to it. Maybe the 
RIRs also have a policy of yanking someone's address space allocation if 
there are repeated violations, as an enforement mechanism. Lots of incentive 
for operators to deploy. But there's really no role for IETF in this, unless 
there is need for some technical solution to propagate information on 
malfactors around, or to terminate forwarding.

The problem is, most Internet types don't like this kind of thing. It smacks 
of "regulation" (in fact, it is a kind of regulation, self regulation). 
Personally, I think the Internet is better off without a lot of regulation. 
If and when a significant chunk of national economic activity moves online 
such that these kinds of problems end up negatively impacting national GDP, 
the problem will fix itself. Governments will step in, maybe the ITU will 
get involved to ensure that the bad guys can't escape. I hope I'm not around 
when that happens.

            jak

---

From: joel at stevecrocker.com (Joel M. Halpern)
Date: Thu Sep 21 00:56:25 2006

Having read the problem description draft, I must say that I am left 
with the impression that this is an interesting research 
activity.  And all of the discussion on the lists so far as also 
given me that same impression.

While a working group should not be formed to endorse a single 
solution, it also should not be formed unless we believe that there 
is a (or are multiple) solution(s) ready for engineering.

Yours,
Joel M. Halpern

At 05:55 AM 9/20/2006, Jun Bi wrote:
>Cc: "Jun Bi" <[email-masked]>; <[email-masked]>; 
><[email-masked]>; <[email-masked]>
>Subject: Re: [SAVA] Re: [Int-area] Call For Participationand 
>Interest:SourceAddress Validation Architecture (SAVA)
>
>
>Int-area mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/int-area

---

From: fred at cisco.com (Fred Baker)
Date: Thu Sep 21 07:13:01 2006

On Sep 20, 2006, at 9:02 AM, James Kempf wrote:
> Here's an idea (which, BTW, I'm not adovocating). ISPs agree that  
> if they detect spoofed packets from someone they cut off forwarding  
> to/from that AS until the problem is fixed. Really simple and  
> modestly straightforward to deploy, but not a technical solution.  
> It requires the RIRs and operator associations to issue a policy,  
> and the operators to agree to it.

well, there's the rub.

If the source address is spoofed, it's pretty hard to say what AS the  
packet arrived from. If you can detect the spoofed packet on a link  
to a neighboring AS, you could cut off that AS, but you won't know  
whether that AS actually allowed it in or whether it has some other  
customer that allowed it in. You only know it got to you.

Unless someone shows me numbers to the contrary, I'll bet that the  
most probable case in which you will received spoofed packets is on  
the links that give you the most packets, which is to say the ones  
that pay you the most money or which you pay the most money to gain  
access to. Cutting those connections off costs you real money.

Now, if the ISPs tell me they're willing to abide by such a policy,  
I'm all for it, but I'll bet a good meal in a great restaurant that  
they're not the ones that propose the idea.

> Lots of incentive for operators to deploy. But there's really no  
> role for IETF in this, unless there is need for some technical  
> solution to propagate information on malfactors around, or to  
> terminate forwarding.
>
> The problem is, most Internet types don't like this kind of thing.  
> It smacks of "regulation" (in fact, it is a kind of regulation,  
> self regulation). Personally, I think the Internet is better off  
> without a lot of regulation. If and when a significant chunk of  
> national economic activity moves online such that these kinds of  
> problems end up negatively impacting national GDP, the problem will  
> fix itself. Governments will step in, maybe the ITU will get  
> involved to ensure that the bad guys can't escape. I hope I'm not  
> around when that happens.
>
>            jak

---

From: kempf at docomolabs-usa.com (James Kempf)
Date: Fri Sep 22 05:59:06 2006

Hmm, well sounds as if there may be a technical problem after all. First, an 
intrusion detection problem: does this stream of packets have forged source 
addresses? Then, a traceback problem: if so where do these packets originate 
from?

Presuming these problems were solved, what would one do with the 
information? Go to the offending ISP and ask: "Someone is forging source 
addresses from your domain, can you please institute source filtering to 
stop them?"

            jak

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>; "Jun Bi" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, September 20, 2006 3:22 PM
Subject: Re: [SAVA] Re: [Int-area] Call For Participation and 
Interest:SourceAddress Validation Architecture (SAVA)

>> Here's an idea (which, BTW, I'm not adovocating). ISPs agree that  if 
>> they detect spoofed packets from someone they cut off forwarding  to/from 
>> that AS until the problem is fixed. Really simple and  modestly 
>> straightforward to deploy, but not a technical solution.  It requires the 
>> RIRs and operator associations to issue a policy,  and the operators to 
>> agree to it.
>
> well, there's the rub.
>
> packet arrived from. If you can detect the spoofed packet on a link  to a 
> neighboring AS, you could cut off that AS, but you won't know  whether 
> that AS actually allowed it in or whether it has some other  customer that 
> allowed it in. You only know it got to you.
>
> Unless someone shows me numbers to the contrary, I'll bet that the  most 
> probable case in which you will received spoofed packets is on  the links 
> that give you the most packets, which is to say the ones  that pay you the 
> most money or which you pay the most money to gain  access to. Cutting 
> those connections off costs you real money.
>
> Now, if the ISPs tell me they're willing to abide by such a policy,  I'm 
> all for it, but I'll bet a good meal in a great restaurant that  they're 
> not the ones that propose the idea.
>
>> Lots of incentive for operators to deploy. But there's really no  role 
>> for IETF in this, unless there is need for some technical  solution to 
>> propagate information on malfactors around, or to  terminate forwarding.
>>
>> The problem is, most Internet types don't like this kind of thing.  It 
>> smacks of "regulation" (in fact, it is a kind of regulation,  self 
>> regulation). Personally, I think the Internet is better off  without a 
>> lot of regulation. If and when a significant chunk of  national economic 
>> activity moves online such that these kinds of  problems end up 
>> negatively impacting national GDP, the problem will  fix itself. 
>> Governments will step in, maybe the ITU will get  involved to ensure that 
>> the bad guys can't escape. I hope I'm not  around when that happens.
>>
>>            jak

---

From: fred at cisco.com (Fred Baker)
Date: Fri Sep 22 07:01:35 2006

On Sep 21, 2006, at 2:09 PM, James Kempf wrote:
> Hmm, well sounds as if there may be a technical problem after all.  
> First, an intrusion detection problem: does this stream of packets  
> have forged source addresses? Then, a traceback problem: if so  
> where do these packets originate from?

And the news in this statement is what, precisely?

Yes, people put bogus source addresses into packets. Barry indicates  
that it is far less common than it once was, but someone else (name  
escapes me and I'm too lazy to go find the email) that some attacks  
depend on them doing so.

The ability to detect that the address was spoofed is roughly  
inversely proportional to the distance from the spoofer. The first  
hop router has some hope, in that it at least potentially has an ND  
entry for the device. The second hop router can at most say that it  
comes from a known LAN in the right general direction. The third ISP  
downstream can MAYBE say that it comes from a prefix in its route  
table, assuming that it has no default route or excludes that from  
consideration.

Tracability is pretty tough. Any router should be able to say what  
the previous router was (eg, what MAC address/lambda/MPLS LSP/ 
whatever it received the datagram from) for any given datagram. Note  
"should"; I can think of lots of reasons why the information may have  
been discarded before the analysis of the IP header started. If the  
router is an ISP/ISP router, it "should" therefore be able to say  
what the previous ISP was. "should".

There are a bunch of SIGCOMM etc papers on statistical traceability  
in IPv4. The fields they use didn't make it into IPv6.

I could imagine a new hop-by-hop option: "previous router". Some  
router, perhaps the first hop router, ensures that the header is  
there; it and each subsequent router writes one of their own IP  
addresses into it, and if the next hop detects a problem it can be  
used to unwind the issue. Interesting special cases apply: what if an  
ISP uses a ULA for network management and link-local addresses for  
routing? No router need have a public address except the BGP router,  
and (Route Arbiter) that need not actually be a data path router. So  
I'm trying to debug a packet and have only my neighboring ISP's ULA  
or the link-local address to work with. Yes, one could use the source- 
route option for this (same problem) but that's 128*20=320 extra  
bytes per datagram. Seems a trifle excessive.

Anyone for the Evil Bit? Oh, yes, RFC 3514 uses the fragment offset  
field of the IPv4 header.

Can someone please say something that hasn't been said a thousand  
times before?

---

From: kempf at docomolabs-usa.com (James Kempf)
Date: Fri Sep 22 07:23:10 2006

>> First, an intrusion detection problem: does this stream of packets  have 
>> forged source addresses? Then, a traceback problem: if so  where do these 
>> packets originate from?
>

The "news" is the part you left off:

That's my point. Even if we had the technology to figure this out, the 
social/political/regulatory/you name it nontechnical framework is lacking to 
make the information useful for having any impact. Mr. ISP could simply 
ignore the request, as is likely if they're in collaboration with the 
offenders somehow.

And, as the rest of your post pointed out, solving the technical problem is 
nontrival, and has been looked at before.

            jak

---

From: heldal at eml.cc (Per Heldal)
Date: Fri Sep 22 11:45:41 2006

On Wed, 2006-09-20 at 01:06 +0800, Mark Williams wrote:
[snip]

> A medicine that the patient is not taking cannot effect a cure.

Spot-on. 

You may find any number of technical solutions to the problem, but it
won't help much unless the ops-community is prepared to enforce
implementation. I.e. it becomes a political issue more than a technical
one.

Imagine:

1. Operators agree to boycott equipment vendors who fail to make
BCP38-compliance the *default* behavior of their equipment.

2. A significant software supplier (e.g. OS vendor) including spoofing
probes in their SW. You can't reliably test BCP38 compliance of remote
networks unless probes are deployed within the tested network. Imagine
every internet-attached PC or MAC probing a couple times a year. That
should give a decent indication of which networks do allow spoofing or
not.

3. Transit-operators filter "spoofing-friendly" prefixes from
routes-received until the problem is fixed.

This could eliminate spoofing, with of without SAVA. The remaining
question is whether the ISP-industry is prepared to implement this kind
of self-regulation before influential but less-clued elements impose
measures that may be a lot more destructive.

SAVA may prove good for the future, but it'll take years for any
standard defined today to find its way to all corners of the net, and
for all non-compliant legacy equipment to be removed.

 //per
-- 

Per Heldal - http://heldal.eml.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20060922/0813f371/attachment.bin

---

From: miw at juniper.net (Mark Williams)
Date: Fri Sep 22 14:47:39 2006

Per,

your posting is insightful.

On enforcement of any measures: you are absolutely correct. SAVA, as a 
technical approach cannot change the outline of the 
political/sociological/economic discussion, nor should it aim to. The 
aim is to change the values of some of the parameters that get plugged 
into that discussion in such a way that the output changes.

For the scenario that you painted:

1. Forcing equipment vendors to make BCP038 the default behaviour of 
their equipment. This is a good idea at first glance and may well prove 
to be a good idea on deeper discussion as well. It has certainly cropped 
up in discussion in the SAVA context.

Note however that BCP038 is defined in such a way as to be implemented 
by an intelligent person on whatever equipment they may have in a 
network they understand. It is not defined in a way that is easily 
performed mechanically by equipment that does not think or know the 
design of the network it is part of. Nor is there any consensus today 
(mainly because it hasn't been dealt with in a standards forum) of what 
making BCP038 the default behaviour really means. I suspect most people 
who know their stuff would have a pretty good intuitive understanding 
but it needs to be defined so router vendors can implement it and 
operators know what to expect when they get the software load that 
implements it.

Thinking about what happens in the period after this feature becomes 
available, I can imagine that there would be quite a lot of effort 
required a network of the scale of the IPv4 Internet to accommodate a 
sudden change in the default behaviour of equipment. This is the reason 
why SAVA has taken the approach of dealing with IPv6 only. At the 
current level of deployment of IPv6, with a lot of the standards still 
pretty fluent, we can still conceive of significantly altering the 
behavior of routers in this way.

I would see a definition of how to make BCP038 compliant ingress filters 
the default behaviour for IPv6 routers as a definite candidate for a 
SAVA draft. It's definitely within the scope. (May also be within scope 
for existing WGs)

2. This would certainly make a difference. There is in fact software out 
there that can do this, freely downloadable from
http://spoofer.csail.mit.edu/
and if you follow some links you can see some very interesting and maybe 
even surprising details of where you need to be if you want to spoof 
source addresses.

3. This is also an area included within the SAVA framework. It is 
non-trivial, however. How do you know when you trust a domain to be SAVA 
compliant, and what can you and can't you do when you know that?

There is quite a large body of research around this topic in existence 
and many solutions proposed, some as research papers and some already in 
I-D format. To date we have been reticent to put forward too much detail 
about the proposed solution, first because the body is large and 
potentially confusing, second because we don't want to give the 
impression that all the answers have been canvassed already and hence 
discourage people with ideas from putting them forward and third because 
the solutions are irrelevant to the discussion in hand at the moment, 
which is to ascertain consensus on:

1. Does the forum consider spoofed source addressing to be a problem?

2. If Yes, does the forum consider it to be a problem that the IETF 
should address?

If the first two answers are in the affirmative, then we would wish to 
invite people to take part in the mailing list and if possible to attend 
a BoF to go to the next question:

3. Does the forum regard this as a problem as one that should be 
addressed by a WG within the IETF? (At this point some discussion of 
potential solutions is of course relevant because the test fails if no 
solution is possible or if there is nobody prepared to work on it.)

cheers,

Mark

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Sep 26 22:46:45 2006

Curtis Villamizar wrote:
> > [What would one do with information about an attacking ISPs]
>   

> Not a solved problem.  Back in NSFNET days it was a "we don't want to
> do this but if we do it is going to hurt you a lot more than it will
> hurt us" situation.  Not always so today and DDoS makes the job
> harder (multiple upstreams, potentially millions of sources).
>   

Indeed.  For example (by close analogy): 
http://infosecon.net/workshop/pdf/emailblocking.pdf

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Sep 27 01:35:04 2006

Curtis Villamizar wrote:
> Spam blocking is blocking.  NSFNET used a threat of service
> termination but didn't need to follow through.  I do remember a
> regional network shutting down a university for 3 days due to lack of
> response to a complaint of being used to launch attacks.
>   

Heck, I came out of Rutgers where some general had our connection yanked
off the ARPANET probably because he had indigestion.  But that wasn't
the point.  The point is that with peering relationships being the way
they are, nobody has the ability to make that threat anymore because
they'd be harming their own customers in the process.

Eliot

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed Sep 27 23:29:56 2006

On 26-sep-2006, at 17:04, Curtis Villamizar wrote:

> Enabling RPF by default may be a good idea.

You and me may find it a good idea. But networks on the tail end of  
the clue curve will not think so: don't enable it, you don't really  
have a problem, enable it incorrectly and you break your network.  
This is really a no-brainer.

Any "solution" that requires 99% of the internet to do something that  
is beneficial to you is a non-starter.

Now if this proposed wg can find a way for me to recognized spoofed  
packets when they enter my networks without cooperation from the  
source and intermediate networks, I'm all ears.

---

From: rbonica at juniper.net (Ron Bonica)
Date: Thu Sep 28 00:21:24 2006

> packets when they enter my networks without cooperation from the  source
> and intermediate networks, I'm all ears.
> 

Iljitsch,

Would it be useful if upstream networks that validated source addresses
somehow signed* the packet? If they did that, when the packet enters
your network, you will know which packets come with an assurance of
source address validity from the upstream network.

                            Ron

* Don't read too much into the word "sign". We may not be talking about
cryptographic strong authentication of every packet.

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu Sep 28 00:54:47 2006

> source address validity from the upstream network.

Assuming the obvious difficulties with such an approach can be worked  
out: sure. But I'm afraid we'll again see that a significant number  
of people won't implement these measures.

Something along the same lines: let me communicate back to a router  
in the source AS my permission to receive packets. People who send  
too much traffic to destinations that don't give permission are  
blocked or throttled.

---

From: fanye at us.ibm.com (Fan Ye)
Date: Thu Sep 28 22:28:16 2006

> too much traffic to destinations that don't give permission are 

Cooperation from source or intermediate AS itself is not a problem, the 
issue is how much cooperation is needed.

For signing the packet, periodic re-establishing secret keys (assuming 
keyed hash functions are used) is needed. The period can be several weeks 
or months, depending on how paranoid ISPs feel. 

For sending back feedback, it sounds like happening all the time (a dest 
AS can see increased traffic from somewhere any time), need more tightly 
coupled control loop (dest AS is changing the behavior of source AS. how 
to secure that?), and require secret keys for authentication as well 
(otherwise this feedback control itself can be spoofed). 

So signing seems to me doesnt require too much cooperation. It may also be 
used as incentive: if a source AS dont sign, during emergence a dest AS 
may drop traffic from it with high probability.

Fan

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:49 2006

> customer that allowed it in. You only know it got to you.

Back to the future.

The NSFNET used to collect src/dst network pairs on all outfacing core
interfaces.  This was easier with classfull routing but doable with
classless routing.  If the set of source addresses started to vary
greatly there was a spoofing attack coming from that interface and the
peer provider (or customer) was notified (with threats to shut down
peering if no action was taken - the incentive).  Rarely making good
on that threat, but ready to do so.  If it was a customer, they were
simply shut down if they didn't respond right away which generally did
not draw complaints from the customer (acknowledged to be their fault).

Spoofing attacks through the NSFNET could be traced back to the source
if reported within 48 hours of the attack.  Most spoofed attacks could
be detected automatically due to a noticable change in the set of
source addresses in the collected data and then dealt with proactively
(no customer complaint needed before taking action).  This even worked
for intermittent senders intending to make it harder to trace.  This
was in the pre-RPF days.

The NSFNET didn't block this traffic, just made it very traceable to
the upstream.  RPF seems to have been a response to all the NOC
overtime resulting from upstream providers without this data
collection capability having a difficult time tracing the source
further upstream.  This was also before widespread DDoS.

UUNET used to advocate and practice a similar approach, identifying
the target of spoofed traffic and temporarily blackholing traffic to
affected destination(s) from offending peers.  Again the peer was
notified, but not as forcefully.

Data collection suitable for this use is still available on many core
routers but apparenly it is rarely if ever collected.  The only
incentive to doing something like this is that clued in customers want
something done by their provider when they are experiencing an attack.
Lack of response might mean loss of customer.

Initially there was good motivation for RPF.  What may have changed is
that no one in a decade has taken the same hard line approach that
NSFNET took in insisting that their peers trace each the problem
further upstream and fix it or fix it more permanently with RPF.

Those who don't bother with RPF are those that don't have the large
customers who are often the target of DDoS attacks.  Lack of RPF is
tough for providers with these sort of customers if those without them
don't bother to do RPF.  Its made worse if the problem can't easily be
traced to the upstream though that may be for lack of applying an
available solution.

Curtis

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:49 2006

In message <[email-masked]>
"James Kempf" writes:
>  
> Hmm, well sounds as if there may be a technical problem after
> all. First, an intrusion detection problem: does this stream of
> packets have forged source addresses? Then, a traceback problem: if so

Solved problem.  Solution is not being applied by those affected.  Far
from a zero cost solution.  Problem beat to death at IPMA meetings and
discussed at least in IETF going way back.  Two flavors of raw data
collection, netflow and 1-in-N packet sampling.  Most core routers
today (afaik) are capable of doing one or both of these at line rate
on 10 Gb/s interfaces (or concatenations of these).

> information? Go to the offending ISP and ask: "Someone is forging
> source addresses from your domain, can you please institute source
> filtering to stop them?"

Curtis

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:50 2006

> escapes me and I'm too lazy to go find the email) that some attacks  

An example of such an attack is resource related attacks such as TCP
SYN attacks to web servers.  Immunity to this type of attack is much
better than it used to be but not perfect.  Following with a SYN-ACK
has a 1 in 65K chance of creating an established connection.  There is
also the more dangerous TCP hijacking problem with sessions that are
authenticated but carry no payload validation (or encryption).  The
latter is nothing IPSEC, kerberos, or ssh couldn't solve if available.

Unpopular organization such as Microsoft, SCO, or the governemt of
China might find themselves targets of resource attacks but since
these attacks are now far less effective (and rather pointless) they
are far less common.  In the past AOL and Yahoo have been targets.  I
think whitehouse.gov was a target at one point (even when Al was
there).  Probably thousands more have been targets of small scale
attacks.  Some were even personal vendetas.

Curtis

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:50 2006

In message <[email-masked]>
Per Heldal writes:
> probes in their SW. [...]

Is this going to happen before or after said OS vendor fixes the many
security flaws in its OS.  How about back versions including now
unsupported versions which still have significant installed base.

Also how much will the upgrade cost and will it run on the old PC with
16MB of RAM that grandma turns on to pick up email once a week.

You've certainly hit on the source of the problem here and there is a
straightforward solution but not one that the end user seems willing
to use (erase disk, install Linux or *BSD).  Not something grandma
will want to try.

I often wonder what the effect would be of fining the end user if
their machine was used in an attack, even if through no fault of their
own other than using security flawed software and what market
reprocussions that might have on the source of this flawed software.

Tough medicine to swallow but it may be what the patient needs.  Some
side effects.

Curtis

ps - grandma has about as much clue as many "IT professionals".

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:51 2006

In message <[email-masked]>
> 2. If Yes, does the forum consider it to be a problem that the IETF 

IMHO what we are hearing is:

1.  Yes.  Technically solved.

2.  No.  Already technically solved.

btw- Tracing backscatter source was also used in finding source of
"spray attacks" such as virus propogation to random addresses.  Some
providers use the opposite - detection of non-routable source
addresses as a simple way to identify spoofed attacks and its source.

Enabling RPF by default may be a good idea.  There are three cases.

  1.  Clueless or clueful provider with no assymetric routing.  No
      problem.  RPF gets left on (on purpose or not).

  2.  Clueless provider with assymetric routing.  This change becomes
      a "clue hammer".  It hurts but only on a one time router
      software upgrade.  The provider is forced to think about which
      routers may be carrying assymetric routing.  Some may turn it
      off everywhere.  (Vendor can say IETF made me do it and the
      provider should have read the big warning on page one of the
      release notes).

  3.  Clueful provider with assymetric routing.  No problem - RFP
      cannot be applied and gets disabled hopefully only where it
      might be a problem and not everywhere.

The tradeoff is the gain realized by 1 (and maybe 3) vs the disruption
caused by 2.  I think it was Bill Manning or Randy Bush who first said
(paraphrased from memory from circa 1992 or 1993):

  The Internet is growing exponentially but the amount of clue is only
  growing linearly at best; theefore the "clue density" is decreasing
  exponentially.

That may be the underlying reason RPF is not enabled by default.

Curtis

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:51 2006

Curtis

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:52 2006

In message <[email-masked]>
> source and intermediate networks, I'm all ears.

Create a filter at each ingress to your network taking unassigned (and
optionally also unreachable) address space.  The minimal data
collection is incrementing a counter.  You may also want to blackhole
the traffic with invalid source address but you don't need to do that
to do the data collection.  Just counting the filter hits may be all
you want to do.  If you see a spike in that traffic, notify the peer.
If they do the same, it leads back toward the source of spoofed
attacks.  I think UUNET had a white paper on this and there may have
been something similar (more than once) at NANOG.

Note that if there is one destination (host or prefix) and many
sources it is an attack on a specific target.  You may discover this
in your data collection (if it is more than reading an SNMP counter).
If you divert traffic to a pizza box (could be remote) then you can
record destinations being attacked.  You may (or may not) want to
blackhole traffic to that target from that ingress depending on
whether the traffic volume is high enough.  If the target is your
customer, then call them and have them make the call on this.  The
data collection should trigger a trouble ticket and this notification
should be NOC procedure.

Both ANS and UUNET had something along these lines though ANS used the
ARTS data collection (don't ask me what the acronym stood for, if
forgot).  Customer appreciated getting the call where the ISP had
noticed the problem, isolated the source, notified the peer, and was
asking the customer about further action.  If their link was flooded
or the DoS was causing trouble they often requested blackholing from
the source.  Legitimate traffic from the peer ISP was then lost until
the peer traced the problem further back.  Good NOC to NOC
communication helped and bothering the other NOC about it every so
often helped.  ANS bothered them every 15 minutes until they traced to
a peer and put a similar filter there (lessenning the impact on
legitimate traffic), then bothered that upstream, ... etc.  This
sometimes went on for a day or two with the need to escallate the
problem at less responsive providers.

This attack (TCP SYN with forged source) was popular for a while but
when BSD and Linux were hardenned against it (with most major web
servers running on these OS) and appache hardenned, it became far less
effective and is not so common.  DoS attacks on DNS servers was
another fad.  Both still occur but afaik are less common now.

This is the simplest.  The ANS ARTS collection could recognize a
change in the net to net traffic and new source addresses stuck out
even if the attacker used a range of reachable addresses.  If they
used their own addresses (unused host addressses or otherwise
blackholing the SYN-ACK, or some other type of attack) then that could
be detected (lots of traffic to that dest with a specific source
range).  ARTS software was put in the public domain and ARTS
collection may be feasible on some routers but I don't think anyone at
all does it anymore.  UUNET did something in between, only collecting
statistics on traffic with known bogus source addresses.

Curtis