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

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Wed, 13 Sep 2006 07:16:36 -0700

> 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

E) There isn't any perceived new revenue to the network generated from
turning on sources address policing.

"E" is the #1 reason I've run into with SPs for not deploying source
address policing. 

Comment on the draft - L3 source validation we OK 10 years ago - but not
today. It has to be a L2/L3 source check today. This is why there are
more ports configured with DHCP Lease Query and IP Source Verify (both
L2/L3 source checks) then with uRPF Strict. 

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

---

From: Mark Williams <[email-masked]>
Date: Thu, 14 Sep 2006 23:55:48 +0800

> "E" is the #1 reason I've run into with SPs for not deploying source
Agreed. In fact, if there was some way to make the application of source 
address policing in some way a /sine qua non/ for any ISP with end 
customer connections, then I think we would be most, if not all  of the 
way there. Indeed one of the goals of SAVA would be to significantly 
increase the incentive to apply source address filtering.
> L2/L3 source checks) then with uRPF Strict.
Agreed. In fact in the expanded framework that is being worked on, L2/L3 
source checks in access networks is part of the picture.
> routing-discussion mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/routing-discussion
>

-- 
"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: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Sep 2006 21:19:46 +0200

On 14-sep-2006, at 17:55, Mark Williams wrote:

> In fact, if there was some way to make the application of source  
> customer connections, then I think we would be most, if not all  of  
> the way there.

In security, there are no prizes for "almost".

I still don't know what this effort is supposed to accomplish. Can  
someone enlighten me?

Is the problem that the communication between network equipment can  
be subverted with source address spoofing? As I wrote in a previous  
message, source address spoofing shouldn't be an issue when the  
communication is between two internal systems, and the only protocol  
network elements use toward the outside is BGP which has its own  
mechanisms to protect against attacks based on source address spoofing.

What source address spoofing does is allow a third party to inject  
packets into the communication stream between two other systems.  
However, if these two systems use reasonable security practices  
(where reasonable can be as light-weight as using hard-to-guess  
initial sequence numbers and ephemeral port numbers for TCP sessions  
or as heavy-weight as full IPsec AH) then the only thing an attacker  
can do is some form of denial of service that is hard to filter out,  
either by overloading network links, buffers or processing capacity.

I don't think anyone can reasonably argue that we can get the  
internet to a state where the source address is so trustworthy that  
it's possible to base any kind of security on it. That leaves the DoS  
issue, which was declared out of scope earlier. Ignoring that, most  
denial of service can also be done WITHOUT source address spoofing,  
so I don't see the point of herculian efforts to rid the internet  
completely of places where a user can spoof a source address. This  
just isn't going to work.

> Agreed. In fact in the expanded framework that is being worked on,  
> L2/L3 source checks in access networks is part of the picture.

Doing per-packet work to make per-session life easier is  
fundamentally the wrong approach. A sad example is port 25 filtering.  
99.9% of all packets flowing over the internet are other protocols  
than SMTP. So installing port 25 filters to make life easier for mail  
servers that insist on using a protocol that takes everything it's  
told for true without any checks at all is completely backwards,  
especially as the power (processing and electricity wise) for all  
this filtering scales linearly or worse with the number of packets  
flowing over the internet, while improving SMTP scales order O(number  
of SMTP implementations).

Unfortunately, this kind of logic is found all over the place. For  
instance, with TLS and IPsec moderately heavy crypto must be executed  
for all packets: the ones that end up being legitimate, but also the  
ones that turn out to be spoofed. A better approach than rely on  
HMACs to authenticate the sender as well as the message integrity  
would be for the sender and the receiver to generate a stream of hard- 
to-guess bits and include part of this stream with every message so  
that the first check that must be done is a simple 4 or 8 or byte  
compare rather than a ~ 1400 byte MD5 or SHA-1.

I.e., we first check whether someone has a ticket before we X-ray his  
baggage.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Sep 2006 23:51:30 +0300

Iljitsch, Mark,

Iljitsch you wrote:

> Is the problem that the communication between network equipment can be
> subverted with source address spoofing? As I wrote in a previous
> However, if these two systems use reasonable security practices (where
> reasonable can be as light-weight as using hard-to-guess initial
> sequence numbers and ephemeral port numbers for TCP sessions or as
> heavy-weight as full IPsec AH) then the only thing an attacker can do
> is some form of denial of service that is hard to filter out, either
> by overloading network links, buffers or processing capacity.
>
> I don't think anyone can reasonably argue that we can get the internet
> to a state where the source address is so trustworthy that it's
> possible to base any kind of security on it. That leaves the DoS
> denial of service can also be done WITHOUT source address spoofing, so
> I don't see the point of herculian efforts to rid the internet
> ...
> Doing per-packet work to make per-session life easier is fundamentally
> the wrong approach. A sad example is port 25 filtering. 99.9% of all
> packets flowing over the internet are other protocols than SMTP. So
> installing port 25 filters to make life easier for mail servers that
> insist on using a protocol that takes everything it's told for true
> without any checks at all is completely backwards, especially as the
> power (processing and electricity wise) for all this filtering scales
> linearly or worse with the number of packets flowing over the
> internet, while improving SMTP scales order O(number of SMTP
> implementations).

In general I agree with the above. However, there is value
in applying low-cost measures such as ingress filtering
as a first layer of defense. Not the only defense, of course,
but the existence of these measures makes attacks against
other defenses harder, improves the ability to track down
ill-behaving nodes, etc.

But the crux of the matter is the part about the low
cost. This brings me to a question that I wanted to
ask Mark -- you wrote:

> Indeed one of the goals of SAVA would be to significantly increase the
> incentive to apply source address filtering.

I think we all agree that goverment policies, industry
self-regulation, etc. are all outside the scope for our work
at IETF. So, presumably, we are talking about incentives
that are of technical nature, advantages in new methods.
Such as methods that simply work better, require less
configuration, or provide more benefit to an early adopter
than, say, ingress filtering. Do you have ideas on what such
methods would be, or would the actual development effort
be left to the WG? Any pointers to papers etc?

To be clear, I do not want to engage in a detailed
discussion of any specific proposals. But I'd like to
read about them, and understand where we are in
terms of the technology -- do we need research
first or do we already have some possible tools that
we can use to build new standards.

--Jari