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

From: miw at juniper.net (Mark Williams)
Date: Tue Sep 12 16:33:30 2006

All,

We are calling for interest and participation in a project to devise a 
framework architecture and solutions to the problem of validation of 
source addresses in IPv6 networks in order to protect network 
infrastructure from address spoofing attacks.

The effort is based on the current situation that it would seem that, at 
least as things currently stand, it is unlikely that spoofed source 
addresses will be able to be excluded from the Internet backbones unless 
some further solutions and practices are put into place.

The SAVA effort has roots in research and development to that end for 
IPv6 networks currently being undertaken at Tsinghua University in 
Beijing. A number of papers have been published and code has been 
written, which will be going into test on the CERNET-II backbone in the  
not-too-distant future. We seek the participation and assistance of the 
wider Internet community in order to create a framework of practices and 
solutions which will be deployable on a much wider basis.

A (condensed) draft problem statement is included inline below, and a 
framework document is in early draft.

We will be proposing a BoF session at the upcoming San Diego meeting.

A document repository for drafts and other documents is available at:
http://narl.tsinghua.edu.cn/sava/

An interim mailing list
[email-masked] <mailto:[email-masked]>
has been created and can be joined by going to:
http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
an archive is also available at the same address.

cheers,

Mark
-----------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------

    Problem Description:

      Introduction

In the MIT Spoofer Project, the authors found that approximately 
one-quarter of the observed addresses, netblocks and autonomous systems 
(AS) permit full or partial spoofing.  And they suggested that a large 
portion of the Internet is vulnerable to spoofing. Concerted attacks 
employing spoofing remain a serious concern.

The current method of avoiding packets with spoofed source addresses 
entering and being propagated on the Internet relies on two methods:

a)       Ingress Filtering as per BCP0038 [RFC2827].  This method 
requires    ISPs and organisations at the edge to apply filters limiting 
the    source addresses allowed on incoming packets to those    
specifically allowed in the stub networks.  If BCP0038 were    followed 
at all ingress points to the Internet, then there would    be no spoofed 
packets on the Internet.

b)       Unicast Reverse Path Forwarding (uRPF) filtering.  This is a 
feature available on routers that can be used to block incoming packets 
if, in the case a packet were constructed with the incoming packet's 
source address as its destination address, the constructed packet would 
NOT be routed back along the ingress link for the incoming packet.

Ingress filtering is definitely to be recommended, and uRPF filtering 
certainly does have its uses, but, at least in the current state of the 
Internet, they are insufficient as a protection for the routing 
infrastructure.

a)       Ingress filtering works, but it only works if all, or at least 
the vast majority of ingress points apply ingress filtering.  As can be 
seen in the Internet today, even when 25% of the Internet is unsecured, 
those elements that want access to "spoofable" connections simply move 
their connection to unsecured attachment points.

b)       uRPF does not work well in places where asymmetric routing 
happens.  This constitutes a large part of the Internet

There are many proposed  mechanisms related to the validation of source 
IP addresses, but few of them are widely deployed by the current 
Internet. While it is possibly too late to introduce adequate source 
address checking in the current IPv4-based Internet, the development of 
the next generation Internet using IPv6 gives us the opportunity to 
implement an architecture for effective source address checking.

      Why IPSEC is not the Solution to This Problem

IPSEC is a solution to many problems, and it is not the intention of the 
authors to suggest that it should not be deployed.  It is just not the 
solution to this particular problem.

Whereas IPSEC solves end-end security problems and allows endpoints in a 
connection to verify the identity of other connected endpoints, there is 
also a need for the infrastructure of the Internet to be able to protect 
itself. Many attacks employ spoofed IP addresses either to conceal the 
source of an infrastructure attack or to cause the network 
infrastructure to, in effect, attack itself.

The network must be able to secure itself from poorly-secured 
endpoints.  The goal of the solution to the problem must be to discard 
spoofed traffic as close to the source of the attack as possible. (i.e. 
within the infrastructure rather than at the other endpoint(s).

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Sep 12 18:11:44 2006

I tailed down ipv6 from the Cc:.

> http://narl.tsinghua.edu.cn/sava/

Could the drafts be posted to [email-masked] as well? 
Currently I see none (with 'sava' search).

A few comments on the introduction/problem statement below.  There is 
need to make the statement a bit more explicit.

> Internet, they are insufficient as a protection for the routing 

You should clarify what you mean by 'protection for the routing 
infrastructure'.  What are you protecting against?  What do you mean 
by 'protect'?  What do you mean by 'routing infrastructure' -- all 
routers in the internet, or just the router in a particular service 
provider's network?

If this refers to ensuring that your own routing infrastructure is 
secure, I argue this can already be achieved by appropriate edge 
filtering at your own borders.  See 
draft-savola-rtgwg-backbone-attacks-02.txt and OPSEC WG documents for 
more.

On the other hand, if this refers to generic routing infrastructure 
security, it isn't obvious how a source address validation proposal 
would significantly improve the current situation.

> a)       Ingress filtering works, but it only works if all, or at least the 
> vast majority of ingress points apply ingress filtering.  As can be seen in 
> the Internet today, even when 25% of the Internet is unsecured, those 
> elements that want access to "spoofable" connections simply move their 
> connection to unsecured attachment points.

It is not clear what you mean by 'works'.  You can protect your own 
infrastructure just fine by applying the protection at all of _your_ 
borders.  In most scenarios, that's sufficient, and could be phrased 
as "works".  Or do you have "every packet that enters your network has 
a provably correct source address" as a goal here?

> b)       uRPF does not work well in places where asymmetric routing happens. 
> This constitutes a large part of the Internet

This is a common misconception.  Maybe you haven't seen RFC 3704 (BCP 
84) which describes how to do it. For more detail, also look at 
draft-savola-bcp84-urpf-experiences-01.txt.

-- 
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: junbi at cernet.edu.cn (Jun Bi)
Date: Tue Sep 12 23:18:58 2006

Thank you for your valuable comments. 
I am trying to give some explain.

> routers in the internet, or just the router in a particular service 

    In my mind, the goal of SAVA is to provid new mechnisms that can be implemented in 
    the network equiments (rather than in the end systems) to provent  source address spoofing. 
    The word "protect" here means providing a way for spoofing prevention.
    Depending on the solutions, the protection could be in different level.
    The partial network (One or multiple ISP networks/enterpise networks ) who deployes SAVA should be protected. 
   Therefore, providing incentives to deploy and supporing the incremental deployment (partial deployment still works) and  should be mandoary requirements when we design new solutions.

> draft-savola-rtgwg-backbone-attacks-02.txt and OPSEC WG documents for 

The doucment is related, but I think the problem we stated in SAVA is not the goals that thoes document wants to resolve. 
(at least in section 1.2 of draft-savola-rtgwg-backbone-attacks-02.txt, 
it "assumes that the service provider is doing at least
   some form of address filtering at its border devices, i.e., by
   ensuring that only the infrastructure nodes can use infrastructure
   source IP addresses to talk to the other nodes in the infrastructure.
". The assuption is exactly the problem we want to resoulve in SAVA.).

SAVA fouces on IP layer only, aims to reolve source spoofing, then provide a trustworthy infrastrucure,
DDoS attacks is a cross-layer problems, so the DDoS prevention is out of SAVA's scope.
But I think outcome of SAVA WG, providing an infrastuure without source address spoofing, 
will defintely help thoes drafts that study how to prevent DDoS on routers or hosts.

For the OPSEC documents, see my commets below on ingress filtering and uRPF.

> a provably correct source address" as a goal here?

    The word "works" here means the edge network that deploys ingress filtering will be protected.
    Ingress filtering only benifits others, unless all edge networks are deployed, you can't protect yourselve (because you can't make sure 
the source address of packets coming from outside world is not forged). I think this problem is also indicated by OPSEC documents.
 
 Thelack of incentive will be a key problme for the golabl deployment of ingress filtering.
    Why an edge network deploys ingress filtering to benefit others, that might be why MIT 
spoofer project found lots of ASes are spoofalbe.

Thus, ingress filtiering is effective on edge network, but doesn't support the parial deployment and 
lacks of the incentives.

> draft-savola-bcp84-urpf-experiences-01.txt.

I disscussed with Prof. Lixia Zhang on routing table based methods. 
We think the routing table bas filitering methods (uRPF and variations) are somehow dangerous in backbone.
because it depends on the routing related problmes such as stablization/asymmetrion.
Routing table based forwarding is OK because if a packet is forwarded to a wroing path, 
it still has chances to be forwarded back to the right path by the next router. 
But wrong filtering table will make the packet dropped.
Therefore we think FIB based filtering can resolve part of the problem , but still doesn't work it all cases.
In SAVA, we  hope the  WG members can propose some new solutions in IPv6 to resovle the problem.

> _______________________________________________
> SAVA mailing list
> [email-masked]

---

From: fanye at us.ibm.com (Fan Ye)
Date: Wed Sep 13 00:15:53 2006

I'm curious exactly what is the problem definition for SAVA and what is 
the threat model. One definition is: given an IP packet at a destination 
AS, determine (at dest AS router?)  whehter the packet's source IP address 
is spoofed. This problem is related to several other problems including 
DDoS attack, IP traceback, but not exactly the same. The threat model and 
goals can be different. 

There're many types of threats: attackers control end hosts, attackers can 
sniffer edge router/backbone traffic, attacker control edge 
router/backbone router. There're different goals as well: simply determine 
whether the source IP is correct (what action to take is orthogonal), 
preventing DDoS attack traffic from reaching end-hosts, identifying the 
true source AS of such packet.

As a first step, it helps to clarify exactly what the problem is (and is 
not), what threats SAVA needs (and need not) to address, what goals it 
wants to achieve.

Fan

[email-masked] wrote on 09/12/2006 10:31:55 AM:

>     The partial network (One or multiple ISP networks/enterpise 
> networks ) who deployes SAVA should be protected. 
>    Therefore, providing incentives to deploy and supporing the 
> incremental deployment (partial deployment still works) and  should 
> be mandoary requirements when we design new solutions.
> 
> The doucment is related, but I think the problem we stated in SAVA 
> is not the goals that thoes document wants to resolve. 

>     Ingress filtering only benifits others, unless all edge networks
> are deployed, you can't protect yourselve (because you can't make sure 
> the source address of packets coming from outside world is not 
> forged). I think this problem is also indicated by OPSEC documents.
> 
> We think the routing table bas filitering methods (uRPF and 
> variations) are somehow dangerous in backbone.
> Therefore we think FIB based filtering can resolve part of the 
> problem , but still doesn't work it all cases.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Wed Sep 13 10:10:28 2006

Yes, I believe SAVA will have muilti-fence solution, to prevent source address spoofing in different grannality.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Wed Sep 13 10:12:14 2006

Yes, I believe SAVA framework would adapt muilti-fence solutions,
 to prevent source address spoofing in different granularity (AS, subnets, hosts).

Regards,
Jun Bi

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Wed Sep 13 14:19:22 2006

> ". The assuption is exactly the problem we want to resoulve in SAVA.).

Let me try to help by providing a more detailed listing of why address 
filtering is not done in some networks:
  a) there is legacy equipment which doesn't have line-rate filtering 
capability
  b) network is sufficiently large and complex that defining the border 
of your network is almost impossible (may apply to some Tier1 
networks)
  c) setting up some filtering solutions may be error-prone unless 
done carefully in some asymmetric/flapping routing etc. scenarios
  d) it isn't considered worth the time to do so, unless there is 
clearer benefit or e.g. law requirements

The assumption above is written a) in mind.  I observe that a) applies 
to SAVA as well -- such equipment is not going to have SAVA support 
either. So, I'm somewhat skeptic as to whether that situation is going 
to change in a foreseeable future by requiring that vendors implement 
something else than line rather filtering instead or in addition.

> filtering will be protected.

Do you mean 'protected' as in 'every packet received from outside the 
network has a provably correct source address' or 'the source address 
has not been forged to be one of the network's own addresses' ?

If the former, there is an issue how you deal with the legacy IPv6 
deployments which do not support the SAVA architecture (whatever that 
would end up being).

If the latter, this can already be achieved by ingress filtering and 
it isn't obvious how SAVA would make it easier.

> are deployed, you can't protect yourselve (because you can't make 
> sure the source address of packets coming from outside world is not 

We may have a misunderstanding here, which is why I'd like to use a 
more detailed term instead of 'protect'.

Let me make an example how infrastructure access-lists could help (see 
draft-ietf-opsec-infrastructure-security-00.txt section 3) in how you 
can make sure that source addresses of packets coming from the outside 
world do not have _YOUR_ addresses in them (source address may 
still be spoofed, but not from your addresses at least, which is 
deemed sufficient 'protection' by many):

Network has prefix 2001:db8::/32.

At all of its peer and upstream borders it adds the following inbound 
access list: "if source address is in 2001:db8::/32, drop the packet". 
At all of its customer borders it either uses the same as above (if 
the customers use a different prefix) or only allows the customer's 
addresses ("if source address isn't from 2001:db8:cccc::/32, drop the 
packet").

As a result, no one is able to send packets to the network 
infrastructure (e.g., TCP-RST packets intending to disrupt BGP 
sessions) which have a spoofed network infrastructure addresses in 
2001:db8::/32.

Therefore the network deploying this protection gains benefit that its 
infrastructure addresses cannot be spoofed from the outside. 
However, it's true that more extensive spoofing prevention (ensuring 
that your customers don't spoof some other address rather than your 
own infrastructure) does have a smaller benefit.

Also, this does not provide a proof that any given packet has a 
provably correct source address, but I'm not sure if you could 
(practically) get there anyway.

> In SAVA, we  hope the  WG members can propose some new solutions in IPv6 to resovle the problem.

I agree that FIB-based approaches may be inappropriate in some 
scenarios (for example, when applied between peerings between large 
ISPs) especially with regard to stabilization and prefix advertisement 
consistency.  However, it applies well in typical customer scenarios 
(even asymmetric and multihomed).

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu Sep 14 22:51:55 2006

On 12-sep-2006, at 11:25, Pekka Savola wrote:

>> Ingress filtering is definitely to be recommended, and uRPF  
>> filtering certainly does have its uses, but, at least in the  
>> current state of the Internet, they are insufficient as a  
>> protection for the routing infrastructure.

> filtering at your own borders.

All of this assumes that it's a good idea to authenticate  
correspondents in interactions such as routing protocols solely based  
on the IP address they present. The fact that this "authentication"  
is trivially subverted by source address spoofing which is something  
that's easy to do in today's internet, suggests to me that this is a  
fundamentally broken approach.

Even if we assume that all ISPs do source address validation on  
packets that they receive from their customers, there are many ways  
to work around this. You'd basically have to require SEND for ALL  
subnets connected to the internet, but since this is something that's  
handled locally there is no way an ISP or a real authority would be  
able to know for sure this is done correctly. And obviously it's  
possible to subvert ISP infrastructure. There are so many ISPs that  
this alone is enough of a risk to invalidate the assumption that  
source addresses can be trusted.

> would significantly improve the current situation.

Routing protocols and the like are generally run within  
administrative boundaries where it's possible to filter out unwanted  
packets coming from elsewhere so source address spoofing shouldn't be  
an issue today.

The exception is BGP, which is used to talk to external networks.  
Although there are some weak areas in implementations here that allow  
an attacker to run up CPU usage on most routers, techniques such as  
the BGP TCP MD5 password and GTSM should be sufficient to thwart  
spoofing attacks.

>> b)       uRPF does not work well in places where asymmetric  
>> routing happens. This constitutes a large part of the Internet

> This is a common misconception.  Maybe you haven't seen RFC 3704  
> (BCP 84) which describes how to do it. For more detail, also look  
> at draft-savola-bcp84-urpf-experiences-01.txt.

Current uRPF allows you to reject traffic that doesn't come from a  
single known "good" source, which isn't useful if legitimate traffic  
can come from more than one source (= interface), which is the most  
common situation in larger networks for non-customer sources. An  
alternative is "loose" uRPF which only rejects packets witch sources  
that don't appear in the routing table, which doesn't apply to  
attacks where the address of a working host is spoofed. I understand  
that there is work underway to allow uRPF with multiple sources but  
we'll have to see how well that works in practice. (One issue would  
be that it requires additional FIBs that could grow quite large.)

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu Sep 14 22:51:55 2006

> DDoS attacks is a cross-layer problems, so the DDoS prevention is  

So what's the use then? Non-DoS related source address spoofing is  
easily thwarted by doing a return routability check that contains a  
hard-to-guess nonce.

The way it looks here, the focus of SAVA is so narrow that I can't  
see how it's worth the effort.

---

From: rbonica at juniper.net (Ron Bonica)
Date: Fri Sep 15 04:54:00 2006

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

---

From: fanye at us.ibm.com (Fan Ye)
Date: Fri Sep 15 23:07:07 2006

Ron,

Thanks for clarifying the problem. Then what kinds of threats SAVA plans 
to address? Attackers spoofing addresses may control end-hosts (which is 
quite common and I guess SAVA should address), sniff traffic at the edge 
or the core, or control routers at the edge or the core. Is SAVA going to 
address all of them, or just a subset? 

Thanks,
Fan

---

From: rbonica at juniper.net (Ron Bonica)
Date: Fri Sep 15 23:56:40 2006

Hi Fan,

Ideally, SAVA would address all attacks that require the attacker to
spoof its source address.

                       Ron

Fan Ye wrote:
>>a) spoofed packets that are bound for routers (in the local or remote 
> 
> AS)
>

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sat Sep 16 00:29:15 2006

> spoof its source address.

Can someone  P L E A S E  tell me what this wg is trying to  
accomplish with source address validation?

Without a goal there is no way to measure success.

---

From: fred at cisco.com (Fred Baker)
Date: Sat Sep 16 00:30:31 2006

On Sep 13, 2006, at 9:23 AM, Jun Bi wrote:

> Yes, I believe SAVA will have muilti-fence solution, to prevent  
> source address spoofing in different grannality.

I should think that the simplest model would be based on neighbor  
discovery. When ND discovers that someone is a neighbor, it also has  
the option of determining whether they act as a router; if they do  
not, then the only addresses they should be using on a given  
interface are the address used in neighbor discovery on the  
interface, which is a very tight coupling between a MAC address and  
an IPv6 address. You can add other fences, but if the first hop  
router applies this rule, then you should cover a huge percentage of  
your cases.

Note that this does not imply a problem with privacy addresses or  
changing addresses - a system can be a neighbor to the router as many  
times as it likes. But no device needs to accept a packet from  
someone with whom they are not a neighbor (apart from ND), and in the  
case of traffic on a LAN that includes rejecting packets whose source  
IP address doesn't match their source MAC address.

This differs, of course, in the case that the neighbor in any sense  
forwards packets from another system (per RFC 2460, is a router). In  
that case, forwarded traffic will have differing source addresses.

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Sat Sep 16 04:45:09 2006

On Fri, 15 Sep 2006, Fred Baker wrote:
...
> You can add other fences, but if the first 
> hop router applies this rule, then you should cover a huge percentage of your 
> cases.
>
> Note that this does not imply a problem with privacy addresses or changing 
> addresses - a system can be a neighbor to the router as many times as it 
> likes.

It seems that one of the goals of SAVA was to be able to differentiate 
(in another AS) whether an address was spoofed or not, i.e., the 
first-hop router is not trusted to perform spoofing prevention. 
Above approach is not much different from (other) uRPF-like 
techniques, and at least on its own woould maybe be better classified 
as a more advanced last-hop uRPF implementation technique.

FWIW, having correctness proofs of each address also a high chance of 
having numerous privacy concerns which I don't think I've seen 
considered so far.

---

From: dthaler at windows.microsoft.com (Dave Thaler)
Date: Sat Sep 16 10:49:34 2006

> router applies this rule, then you should cover a huge percentage of

Note that there is no requirement today that a receiver (or router) have
a neighbor entry for a neighbor from which it receives packets, only
that it have one for a neighbor to which it sends packets.

So this would require a significant change in the receive model, not
just a change in the ND model so that you could learn whether the
neighbor is a router.

-Dave

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

---

From: fred at cisco.com (Fred Baker)
Date: Sun Sep 17 01:57:29 2006

On Sep 15, 2006, at 1:10 PM, Dave Thaler wrote:
> Note that there is no requirement today that a receiver (or router)  
> have a neighbor entry for a neighbor from which it receives  
> packets, only that it have one for a neighbor to which it sends  
> packets.

I can think of a wide variety of things receivers regularly do (like  
uRPF, and like a firewall applying filters or doing packet  
inspection) that no specification requires them to. So?

---

From: rbonica at juniper.net (Ron Bonica)
Date: Tue Sep 19 05:18:59 2006

Iljitsch,

I think that this is a fair question, and I apologize for taking so long
to answer it.

The SAVA WG seeks to develop some mechanism by which network equipment
can determine the degree of trust that it places in the validity of a
packet's source address. Having determined that level of trust, the
network will forward the packet as per its security policy. The
following is an example of a security policy that relies upon source
address validation:

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.

                                    Ron

Iljitsch van Beijnum wrote:
> Can someone  P L E A S E  tell me what this wg is trying to  accomplish
> with source address validation?
>

---

From: fred at cisco.com (Fred Baker)
Date: Tue Sep 19 06:34:42 2006

On Sep 18, 2006, at 1:29 PM, Ron Bonica wrote:
> 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.

I should think that the policy would not be changed under load.  
During non-congestive periods, I wouldn't expect to see any  
difference between traffic in the higher and lower priority queues;  
they would normally be empty when a packet arrived, and it would go  
out without delay. And if the classification can be done at line rate  
under load, doing the same classification when not under load won't  
hurt you.

So this simplifies to Sally Floyd's proposal of a few years back -  
traffic that is deemed "probably good" runs in a higher priority  
queue than traffic that is deemed "probably not so good", and under  
stress the latter class takes the brunt of losses. The same can be  
done with rate based queues (WFQ/WRR) by giving one queue 90% of the  
bandwidth and one taking the dregs.

I should think that addressing policy is also but one aspect of this.  
More generally, traffic that you are pretty sure is high value runs  
at high priority, and low value traffic runs at low priority.

---

From: rbonica at juniper.net (Ron Bonica)
Date: Tue Sep 19 06:48:31 2006

Fred,

Your probably right. Most networks probably wouldn't change their
forwarding policy when under attack.

However, my point wasn't to anticipate which forwarding policy a network
might deploy. It was merely to demonstrate that a network might deploy a
forwarding policy that somehow depends on source address validation.

                                   Ron

Fred Baker wrote:
>> 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.
> 
> 
> I should think that the policy would not be changed under load.  During
> non-congestive periods, I wouldn't expect to see any  difference between
> traffic in the higher and lower priority queues;  they would normally be
> empty when a packet arrived, and it would go  out without delay. And if
> the classification can be done at line rate  under load, doing the same
> classification when not under load won't  hurt you.
> 
> traffic that is deemed "probably good" runs in a higher priority  queue
> than traffic that is deemed "probably not so good", and under  stress
> the latter class takes the brunt of losses. The same can be  done with
> rate based queues (WFQ/WRR) by giving one queue 90% of the  bandwidth
> and one taking the dregs.
> 
> More generally, traffic that you are pretty sure is high value runs  at
> high priority, and low value traffic runs at low priority.
>

---

From: fred at cisco.com (Fred Baker)
Date: Tue Sep 19 20:16:27 2006

On Sep 18, 2006, at 2:59 PM, Ron Bonica wrote:

> my point was...to demonstrate that a network might deploy a  

no argument

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue Sep 19 20:55:46 2006

> following is an example of a security policy that relies upon source

Ah, ok, now we're getting somewhere.

The problem is that this approach has limited utility: it depends on  
being able to know whether a packet is desired based on the source  
address. In situations where a very limited number of correspondents  
are allowed this will be useful (i.e., in a routing protocol) but as  
a general purpose mechanism it's not really helpful: a WWW server  
doesn't have a list of addresses of approved clients.

A more general approach would be to create a mechanism that allows  
recognizing packets that belong to approved sessions. This can be  
because the session is towards an approved correspondent, which is  
easy to determine with a return routability check, or it can be after  
higher-layer authentication/autorization.