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

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Mon, 18 Sep 2006 15:19:54 -0700

Now this is making no sense. Today attacks use valid addresses. Spoofed
is not needed. So how do I determine the difference between a good
packet and a bad packet based on rules of trust when my classifiers in
the network devices cannot determine the difference between a good
packet and a bad packet (i.e. all you have is IP header classification
in network devices)? Where are you determining this trust? Host to CE?
CE to PE? PE to P? P to P? Interprovider to Interprovider?

So lets walk through this:

1. Define the Problem. You should not send out IP source addresses which
are not allocated to you. The source address spoofing problem has been
defined. That is BCP38. 

2. Define the Goal. Keep spoof IP Source addresses off the Internet.
That is BCP 38's goal. That is why it is a 'BCP.' 

3. Define the Framework. Done. BCP 38 pushes the source check as close
to the origin as possible. This reduces issues with asymmetry AND gets
you as close to the origin of the packet as possible. This allows some
measure of 'trust' to be established within an administrative boundary
at the boundary.

4. Develop Mechanisms. Done. Looking for more. As mentioned in previous
post, there are a whole range of mechanisms available to enforce the
policy defined in BCP 38. All the IPv4 'mechanisms' will work with IPv6.

> During periods of normal operation, the network will forward 
> all packets without regard to source address validation 
> status. However, during periods of congestion cause by 
> malicious attacks, the network will grant preferential 
> treatment to packets, depending upon the degree of trust that 
> the network has in the source address.

Isn't this Diff-Serv? With Diff-Serv + BCP38 you are suppose to apply a
policy to a packet (include source checks with BCP 38), color the DSCP
area of that packet, and forward that packet. The 'trust' value is
carried through the network via the DSCP value. During times of
congestion, policies can be set up to triage which DSCP values get
through.

As I mentioned in a previous post, a couple of SPs have had really
interesting 'security' resiliency added to their network by doing DSCP
re-marking (everything goes to 0 unless the policy is matched) and
BCP38. While revenue was their motivation for deployment (new DSCP
markings for voice services), security resiliency and adding 'trust' to
packets were a secondary gain. All of this "IPv4" experience translates
to "IPv6."

So what would the purpose of the WG be? I'm still not getting it.

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Sep 2006 08:45:02 +0200

The nature of a DDOS attack involves zombies, and zombies may behave in
very different ways, depending on the code.  If I wore a black hat, my
zombies would likely to not use spoofed source addresses, lest their
traffic be blocked by simple source filters at the edge.

Also, if this is truly about source address authentication, then what is
the difference between this and AH?

Eliot

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 Sep 2006 11:57:13 -0400

Eliot,

Agreed. It was a bad example. But my intent was not to recommend this
forwarding policy. It was only to show that an ISP might deploy a
forwarding policy that includes source validation.

                              Ron