Subject: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document

From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com)
Date: Tue, 1 May 2007 10:41:44 -0700

Hello,

I've tried posting this to the list a few times already, but the SAVA
list seems to have been broken for a few days. I've been told that it is
fixed now, so let's try again.

If you haven't seen this yet, I think it is peripherally interesting to
some of our efforts here.

- ferg

p.s. If this message makes it through, I would like to ask Mark Williams
to post the notes from our SAVA meeting in Beijing on April 22, and
begin some active dialog on a game plan for Chicago...

[snip]

From: Daniel Karrenberg <daniel.karrenberg at ripe.net>
To: RIPE IP Anti-Spoofing Task Force <spoofing-tf at ripe.net>
Subject: [spoofing-tf] BCP38 Business Case Document
Date: Thu, 26 Apr 2007 16:14:31 +0200

Here is the latest draft of the "Network Hygiene Pays Off"
document.  The goal is to publish this after Talinn.

Daniel

----

"Network Hygiene Pays Off"

The Business Case for IP Source Address Verification

Joao Luis Silva Damas
Daniel Karrenberg

v0.3
Tue Apr 24 09:45:15 CEST 2007

Introduction

IP source address verification entirely prevents a class of prevalent
reflector-type DDoS attacks, helps to track down attacking hosts and
simplifies some network management tasks.  Yet a significant number of
ISPs do not deploy it at the edge of their networks.  Common wisdom
seems to be that doing so would be expensive and would only help they
"other guy" who is being attacked.  This memo tries to contrast common
wisdom with some facts. 

What is BCP38

BCP 38 is a "Best Current Practice" document of the IETF.
BCP 38, RFC 2827, is designed to limit the impact of distributed
denial of service attacks, by denying traffic with spoofed addresses
access to the network, and to help ensure that traffic is traceable
to its correct source network.  As a side effect of protecting the
Internet against such attacks, the network implementing the solution
also protects itself from this and other attacks, such as spoofed
management access to networking equipment. BCP 38 has been updated
by BCP 84, RFC3704. 

No Confidence in IP Source Addresses is Bad

Suppose you need to investigate some unusual traffic flows or you
just plain want to analyze current traffic load.  If you do not do BCP38
there is absolutely nothing you can get to know about the source of a
packet from the packet alone.  You cannot trust the source address at
all.  They packet could have entered your network *anywhere*.  Can that
be good? 

Suppose someone launches an attack on one of your customers with packets
that appear to come from another customer.  The victim will likely
request
that you take action and stop the harmful traffic that appears to
originate
from another customer of yours.  If you do not do BCP38 you will have to
tell the
victim that this traffic could come from anywhere and that you cannot
determine very quickly where the traffic is indeed coming from. 

Someone Can Pretend to be You 

Even worse, if you do not do BCP38 an attacker can launch an attack with
packets that appear to be coming from one of the machines you operate
yourself.  Imagine the reaction of a customer that gets attacked by such
packets.  Are they going to trust you when you explain it is not really
you?  What will they think if you tell them that your network operating
practices allow such masquerading?  Imagine the cost of that. 

Good Practice is Not Hard

It is not hard to prevent such a scenario.  You simply have to do BCP38
towards your customers and drop all packets with internal source
addresses
coming in from external peerings.  Once you have done that you
*know* exactly who has sent a packet with an internal source address
and you also know that any packet with an external source address must
have come in via one of the external peerings. 

Some multi-homing customers may require special configuration efforts.
However these are neither impossible or very costly if implemented
well. Our how-to documents explain the technical details.
Since large classes of customers cannot be multi-homed to start with,
you can gain a lot by starting to do BCP38 for them.

Doing BCP38 Helps A Lot and Builds Confidence

Doing BCP38  helps a lot with analyzing anomalies and makes
understanding 
normal traffic load very much more reliable. 

In case any attacks or anomalies do happen, you can determine with
any source within your own network or from any customer with
confidence, simply by looking at the traffic itself!  The decision about
any countermeasures can be made very quickly and without any involved
specialist traceback analysis. 

In case the source of the attack traffic is external, you can also state
that with confidence to your customers and take action.

Reflector Attacks Cannot Happen Between Customers

If you do not do BCP38 one customer can attack another with a DoS
reflector attack.  Consider your responsibility and possible liability
if this were possible.  If you do BCP38 your customers cannot do this to
each other and any reflector attack traffic has to come from outside
your network, thus form outside your direct responsibility. 

Doing BCP38 is Good Publicity

Showing that you operate your network responsibly and safely is good
publicity; stating that you do BCP38 is helps with that.  Showing
responsibility for operating safely discourages regulation and
legislation of operating practices.  Consider the difficulty to convince
policy makers that enabling users to lie about their "caller-ID" is your
normal operating practice. 

Consider All Costs

When considering the cost of implementing BCP38 in your network, you
should consider the costs of not doing so together with the costs for
implementation of BCP38 itself.  The savings in the network management
area and in mitigation of DoS attacks may well outweigh the
implementation costs.  The added good publicity and confidence in good
operating practices should not be neglected either. 

Testimonials of ISPs Who Do BCP38

[Add ISP statements about experiences, illustrating both cost and
benefits.]

[snip]

--
"Fergie", a.k.a. Paul Ferguson
Network Architect, Office of the CTO
Trend Micro, Inc., San Jose, CA
paul_ferguson at trendmicro.com 

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

---

From: rg03 at mails.tsinghua.edu.cn (Ren Gang)
Date: Wed, 2 May 2007 02:09:44 +0800

Hi,Paul.
This time I received the mail.
                         Ren Gang

-----????-----
???: sava-bounces at nrc.tsinghua.edu.cn
[mailto:sava-bounces at nrc.tsinghua.edu.cn] ?? Paul_Ferguson at trendmicro.com
????: 2007?5?2? 1:42
???: sava at nrc.tsinghua.edu.cn
??: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document

Hello,

- ferg

[snip]

Daniel

----

Joao Luis Silva Damas
Daniel Karrenberg

v0.3

Introduction

What is BCP38

Consider All Costs

[snip]

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or telephone and delete the original message from your mail system.

_______________________________________________
SAVA mailing list
SAVA at nrc.tsinghua.edu.cn
http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava

---

From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com)
Date: Tue, 1 May 2007 11:33:10 -0700

> From: Ren Gang [mailto:rg03 at mails.tsinghua.edu.cn]
> Sent: Tuesday, May 01, 2007 11:10 AM
> To: Paul Ferguson (RD-US); sava at nrc.tsinghua.edu.cn
> Subject: ??: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document
> 
> Hi,Paul.

Well, I have another external e-mail address that is subscribed to the SAVA list that hasn't received that message yet (or any others since this problem originally ocurred).

Also, the list archives still do not appear to be working properly:

 http://www.nrc.tsinghua.edu.cn/pipermail/sava/

FYI,

- ferg

TREND MICRO EMAIL NOTICE