Subject: [SAVA] SAVA problem statement comments

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 6 22:24:18 2007

In general, I felt that the problem statement was not clear enough on 
the actual goal (increasing traceability, instead of preventing 
attacks), and justification why the existing solutions are not 
adequate (especially, I'd like to see more focus on the problems in 
inter-domain scenarios) was not good enough.

substantial
-----------

4.  Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach
..
    2.  uRPF does not work well in places where assymetric routing
        happens.  This constitutes a large part of the Internet

==> (is something missing at the end?)  This is insufficient and
superficial.  As the deficiencies of existing methods form the core of the
problem statement, this needs to be better justified.

In particular, uRPF with asymmetric routing is *NOT* problematic in many
relevant scenarios (e.g., multihomed or multiconnected stub networks).

A better characterization would be that in more complex interconnections
between ISPs there are issues because ISPs do not necessarily advertise all
the prefixes they're forwarding traffic from, or if they do, they advertise
the prefixes incompletely or inconsistently due to TE (e.g., a subset at one
peering point, another subset at another peering point).

Given that the focus must be on inter-ISP spoofing prevention, the reasons
why filtering fails between ISPs are the real problems and need to be
identified.

    Whereas IPSEC solves end-end security problems and allows endpoints
    in a connection to verify the identity of 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 to either
    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).

==> this is incomplete and requires better justification.  First of all I do
not understand the justification in the last sentence of the first
paragraph.  What does 'cause the network infrastructure .. attack itself'
mean?  It seems to me that if you're concerned about attacks against the
infrastructure, you will need to block access to the infrastructure from the
outside and just allow it from the management.  Or are you referring to the
network capacity as well?

==> The second paragraph is also weak.  Source spoofing prevention
mechanisms do very little to protect from 'poorly-secured endpoints'.
Source spoofing is just one technique to use, e.g., to make it more
difficult to track the poorly-secured endpoint.  However, even if you
eliminate source spoofing, the security or lack thereof of these
'poorly-secured endpoints' is roughtly equal.  The only thing you've
done is made the network activity more traceable.

Therefore SAVA should not marketed as a solution against poorly-secured
endpoints, network infrastructure attacks, etc. because it's doubtful
whether it'll help significantly with that.  Instead more focus should be
put in emphasizing traceability of attacks or other bad behaviour.

6.5.  Multiple-Fence Solution

    Ingress filtering is a single fence solution, in that it is only
    applicable only at the access network or at the boundary between an
    attached private network and a network provider.  Where the attached
    network is not a stub, it cannot be deployed effectively.

==> this text is misleading.  Ingress filtering can be applied many times in
a row.  The main thing is that setting it up at more densely meshed
scenarios (e.g., peering links between bigger ISPs) gets more troublesome.

8.  Security Considerations

    For this document, no specific security considerations. [...]

==> Framework requirements or here you should probably discuss privacy
issues with addresses whose authority may or may not be globally traceable.

editorial
---------

    seperated sub-problems, refered as "inter-AS AIAA problem", "intra-AS
    SAVA problem" and "access network SAVA problem".  The primary
    difference between these three problems is the different level and
    scope in network topology.  The "inter-AS SAVA problem" considers the
    source address spoofing involved with more than one ASes.  The
    "inter-AS SAVA problem" considers the source address spoofing inside
    one AS.

==> "AIAA problem" ?  What's that?
==> s/inter-AS/intra-AS/ in the last sentence

    SAVA solutions should be feasible for network sizes and no-default
    prefix tables

==> reword 'no-default prefix tables'.

-- 
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: jari.arkko at piuha.net (Jari Arkko)
Date: Mon Mar 19 00:01:37 2007

Pekka,
> why filtering fails between ISPs are the real problems and need to be

I agree with this. Does anyone care to write new text for this?

> put in emphasizing traceability of attacks or other bad behaviour.

I agree with this too.

> issues with addresses whose authority may or may not be globally
I think there is a distinction between ensuring that source addresses
are topologically correct and finding out additional information about
the individual hosts. I'm not sure I see specific privacy concerns in
making addresses valid, as long as no additional information was
revealed.

Jari

---

From: miw at juniper.net (Mark Williams)
Date: Mon Mar 19 02:52:19 2007

Pekka,

> inter-domain scenarios) was not good enough.
I agree that not enough was said about increasing traceability 
(actually, guaranteeing traceability to the extent that traceability is 
required at a specific point in the network.). Preventing a certain 
class of attacks is also an important goal, though.
> substantial
You are right.
> why filtering fails between ISPs are the real problems and need to be
I don't agree that the focus necessarily has to be on inter-ISP spoofing 
prevention. For example, if a mechanism could be found to force the 
deployment of BCP38 and loose uRPF in all providers and to verify that 
it had been deployed, then the need for inter-provider anti-spoofing 
would go away. I'm not saying I have any better ideas about how to make 
this happen, but if such a solution could be found then we could declare 
victory and go home.
> network capacity as well?
The point being made is that SAVA's primary objective is to protect 
infrastructure rather than to protect endpoints from spoofed packets. An 
example of infrastructure being leveraged to attack itself would be a 
large number of spoofed requests for game listings from many game 
servers, with the spoofed address chosen to attack a particular other 
piece of infrastructure (e.g. DNS servers, a crucial link, etc.). The 
word "infrastructure" probably needs clarification here, because it 
doesn't just mean routers.
> done is made the network activity more traceable.
The security or lack thereof of the compromised endpoints is, as you 
say, totally unaffected. However, one form of attack that can be 
launched from them is blocked and the traceability of the remaining 
attacks is greatly enhanced.
> scenarios (e.g., peering links between bigger ISPs) gets more 
I think we are splitting hairs a little here. The domain in which 
ingress filtering works can be seen as one "fence". Once you move into 
the more densely-meshed areas, you are at another "fence".
> issues with addresses whose authority may or may not be globally 
Maybe it should be made clear that it is not the intent or scope of SAVA 
to make any more information available at any point than that which 
would be available today if you could assume the packet does not hold a 
spoofed source address. More specifically, when I send a packet from 
home, today only my provider knows that it was Mark Williams who sent 
that packet and not, for example, any peering provider. That is not 
changed by SAVA.
> ==> s/inter-AS/intra-AS/ in the last sentence
Poor search and replace. AIAA is an early acronym for SAVA. both fixed.
> ==> reword 'no-default prefix tables'.
"Internet core prefix tables"?

cheers,

Mark

-- 
"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: pekkas at netcore.fi (Pekka Savola)
Date: Mon Mar 19 03:27:36 2007

On Mon, 19 Mar 2007, Mark Williams wrote:
> deployment of BCP38 and loose uRPF in all providers and to verify that it had 
> been deployed, then the need for inter-provider anti-spoofing would go away. 
> I'm not saying I have any better ideas about how to make this happen, but if 
> such a solution could be found then we could declare victory and go home.

That's a huge if.  But even if it was true, what else do you think 
would require working on?  I haven't been able to figure that out.

>>  ==> this is incomplete and requires better justification.  First
>>  of all I do not understand the justification in the last sentence
>>  of the first paragraph.  What does 'cause the network
>>  infrastructure .. attack itself' mean?  It seems to me that if
>>  you're concerned about attacks against the infrastructure, you
>>  will need to block access to the infrastructure from the outside
>>  and just allow it from the management.  Or are you referring to
>>  the network capacity as well?

> example of infrastructure being leveraged to attack itself would be a large 
> number of spoofed requests for game listings from many game servers, with the 
> spoofed address chosen to attack a particular other piece of infrastructure 
> (e.g. DNS servers, a crucial link, etc.). The word "infrastructure" probably 
> needs clarification here, because it doesn't just mean routers.

By 'infrastructure protection' do you only consider reflection attacks 
(from the attacker via 3rd party to target) as the problem, or also 
direct attacks (from the attacker to target) with the spoofed 
addresses?

While the open DNS recursive server attacks have shown that reflector 
attacks may be somewhat troublesome, it seems more focus is being put 
to designing and operating services in such a manner that the threat 
is getting smaller.

One could also ask how these attacks cannot be done with a botnet full 
of attacking hosts.  In particular this applies to the second 
category.

> The security or lack thereof of the compromised endpoints is, as you say, 
> totally unaffected. However, one form of attack that can be launched from 
> them is blocked and the traceability of the remaining attacks is greatly 
> enhanced.

I do not see how this would help significantly as 1) the attackers 
would still be able to do spoofing attacks from the rest of the 
internet which doesn't implement this mechanism, and 2) attackers 
could still attack infrastructure directly without any spoofing (which 
seems to be the typical attack method today).

Also, all of this is already doable with mitigation mechanisms (e.g., 
rate-limiting) that whitelist packets from direct peerings from 
networks where ingress filtering has been implemented.

>>     Ingress filtering is a single fence solution, in that it is
>>     only applicable only at the access network or at the boundary
>>     between an attached private network and a network provider.
>>     Where the attached network is not a stub, it cannot be deployed
>>     effectively.
>>
> I think we are splitting hairs a little here. The domain in which ingress 
> filtering works can be seen as one "fence". Once you move into the more 
> densely-meshed areas, you are at another "fence".

I'm not sure if I agree.  For example, we provide transit to some 
end-sites and networks.  At least some of them perform ingress 
filtering on their customers and/or LAN interfaces.  Even if they 
don't, we still ingress filter those networks.  Even if we missed that 
for a single customer, we still have (output) filters at the peering 
and upstream borders which drop all packets which try to leave our 
network with source addresses that are not in our network.  That's 
about 3 layers of defence in depth already.  Our transits and peers 
could also be filtering us based on our advertisements (but at least 
currently don't).

> "Internet core prefix tables"?

"DFZ" is usually used though that may trigger Bill Manning to ask 'DFZ 
where?'...

---

From: miw at juniper.net (Mark Williams)
Date: Mon Mar 19 03:58:09 2007

> would require working on?  I haven't been able to figure that out.

Actually, I agree that it is a huge if. I'm just saying that at this 
stage in the game I'd not like to close off possible avenues for 
solution. Let's get the problem definition straight first.

> of attacking hosts.  In particular this applies to the second
DNS reflection attacks are just one kind of reflection attack. They work 
wherever you can get a big response from a small query that doesn't 
require a full TCP connection. I'm not optimistic that this opportunity 
will ever be designed out.

Good question about the attacking botnet. I've just been working with a 
site that had a key webserver taken off the air by a botnet attack. The 
attack took the form of about 5000 individual hosts requesting a single 
page repeatedly. Now, by going through the logs manually we were able to 
separate the attackers from the "real" requesters and it's my opinion 
that this process could be automated in real time and an appropriate 
filter could be developed against 5000 hosts. Should this kind of 
defence become prevalent, the logical response from botnet controllers 
would be to start spoofing addresses, giving them essentially an 
infinite number of hosts that each request once. Of course they would 
need to have more bots, because a spoofing bot cannot create as much 
load as a non-spoofed bot.

No silver bullets here, but raising the bar helps and the more holes you 
close the better.
> say,

In fact, one of the goals of SAVA is to extend the number of Domains 
which you can whitelist because they deploy appropriate ingress 
filtering from your peer domains to all domains within a trust alliance 
who have implemented appropriate ingress filtering. If there was a way 
for the 75% of the internet that does not allow spoofing to de-prefer 
packets coming out of the 25% of the Internet that does allow spoofing, 
then we would really be getting somewhere. A proof-of-concept protocol 
that would allow this has been deployed on CERNET-II with success, at 
least among a small community of domains of control.

cheers,

Mark
> >>  ==> this text is misleading.  Ingress filtering can be applied 
> many times
> >>  in
> ingress

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon Mar 19 05:46:23 2007

> Good question about the attacking botnet. I've just been 
> working with a site that had a key webserver taken off the 
> air by a botnet attack. The attack took the form of about 
> 5000 individual hosts requesting a single page repeatedly. 
> Now, by going through the logs manually we were able to 
> separate the attackers from the "real" requesters and it's my 
> opinion that this process could be automated in real time and 
> an appropriate filter could be developed against 5000 hosts. 
> Should this kind of defence become prevalent, the logical 
> response from botnet controllers would be to start spoofing 
> addresses, giving them essentially an infinite number of 
> hosts that each request once. Of course they would need to 
> have more bots, because a spoofing bot cannot create as much 
> No silver bullets here, but raising the bar helps and the 
> more holes you close the better.

What you are describing already done (i.e log -> to list of BOTs ->
action). This is done many many times a day coordinated by several
operational security mitigation communities. The logical next step you
suggest "start spoofing addresses" is just not done today. It is too
hard for the miscreant to figure out how to reengineer a BOT to get by
the mix of BCP38 and BCP38++ (where L2 anti-spoofing is added). It is
far easier for the miscreant to grab a new BOTNet or rotate their attack
profile on their existing BOTNet.

I've mentioned this in the past. The 'SAVA Problem Statement' is a 2000
problem statement, not a 2007 nor a 2010 problem statement.

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Mon Mar 19 06:29:48 2007

...
> In fact, one of the goals of SAVA is to extend the number of Domains which 
> you can whitelist because they deploy appropriate ingress filtering from your 
> peer domains to all domains within a trust alliance who have implemented 
> appropriate ingress filtering. If there was a way for the 75% of the internet 
> that does not allow spoofing to de-prefer packets coming out of the 25% of 
> the Internet that does allow spoofing, then we would really be getting 
> somewhere. A proof-of-concept protocol that would allow this has been 
> deployed on CERNET-II with success, at least among a small community of 
> domains of control.

First of all, the 'trust alliance' is exactly that -- a federation of 
networks that _trust_ everyone filters properly.  You cannot guarantee 
that they will actually do so.  If this were to take up, I could see 
networks having significant benefit in claiming to be "spoofing 
prevention compliant" while actually taking shortcuts (e.g., omitting 
some bigger customer networks who have complex topologies) in doing so 
in order to get to the 'good boys club'.

Also, the effort you describe (extending trust alliance across third 
parties across the non-conforming Internet) requires a more 
complicated protocol than the one tested.  In particular, nothing at 
present prevents a transit system from modifying the packets (e.g., 
adding signatures, modifying source addresses, etc.), and nothing also 
prevents an attacker from learning the secret and hence adding the 
'secret password' in the packets (up to key expiry).  Nothing also 
prevents replaying (up to the next event when the key changes) 
legitimate packets. These could maybe be solved by more efficient 
signature mechanisms (e.g. HMAC on selected parts of the packets 
instead of just adding a password in clear text) but personally I'm a 
bit wary of extending the trust domain across the Internet and 
potentially to parties you don't have a direct association with.

I suspect trying to do so would bring up some of the issues which were 
slowly experienced when people thought creating a global PKI would be 
a good idea.

No matter how one tries to go about this, I'm having difficulty 
imagining that practically all spoofing will go away, or that you will 
be able to block or drastically deprefer 'non-ingress filtering' 
networks due to the vastness of Internet.  However, I'm optimistic 
that you would be able to do similar 'trust federations' on a local 
scale (e.g., in the country, all the members of an internet exchange 
point, etc.) which might allow (by rate-limiting etc.) more reliable 
_local_ communication when experiencing an outsider, spoofed attack. 
This wouldn't help with non-spoofed or reflection attacks though so 
the benefit not be that big in the end.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Mon Mar 19 06:53:22 2007

----- Original Message ----- > 
> in order to get to the 'good boys club'.

The basic idea is, if an AS join the trust alliance, it must make sure the 
Intra-AS source spoofing prevention method is deployed (e.g., a fully deployment of 
ingress filtering inside the AS or other new Intra-AS methods), and be responsble 
for the results. 
A alliance policy would be made if an member AS fails to be 'good guy', e.g. be removed from the alliance 
or be punished. 

And thank you for pointing out the following working items.
I think that's why we need a WG to bring more people to discuss new protocols so that good 
protocols can be designed to solve the problems.

To enhance the end-to-end method, one candidate way could be a key chain share 
by peers who know key changing sequence by an algorithm.

> _______________________________________________
> SAVA mailing list
> [email-masked]
> http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon Mar 19 07:14:58 2007

What is the economic model that will allow an Engineer in an SP to get
the money from their product manager to authorize them deploy anything
that is being suggested?

Reality checks need to be put into this effort. Dig into the economic
reality of BCP38 before you start making grand projections of the
effectiveness of "alliances."

If people want to get into the details of this, let me know. I can set
up a conference call so you can talk to key "Security Operations" people
in SPs that will walk you through their business realities.  I'm not in
IETF this week (in China), but put this down as one of the core things
that need to be addressed as why things like BCP38 are not deployed
today and how just a few deployments impact the economics of the
miscreants/criminals.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jun Bi
> Sent: Sunday, March 18, 2007 3:53 PM
> To: Pekka Savola; Mark Williams
> Cc: [email-masked]
> Subject: Re: [SAVA] SAVA problem statement comments
> 
> 
> The basic idea is, if an AS join the trust alliance, it must 
> make sure the Intra-AS source spoofing prevention method is 
> deployed (e.g., a fully deployment of ingress filtering 
> inside the AS or other new Intra-AS methods), and be 
> responsble for the results. 
> A alliance policy would be made if an member AS fails to be 
> 'good guy', e.g. be removed from the alliance or be punished. 
> 
> I think that's why we need a WG to bring more people to 
> discuss new protocols so that good protocols can be designed 
> to solve the problems.
> 
> To enhance the end-to-end method, one candidate way could be 
> a key chain share by peers who know key changing sequence by 
> an algorithm.
>

---

From: bijun at bit-way.com (Jun Bi)
Date: Mon Mar 19 08:01:52 2007

The source address space of a member AS is protected within the alliance 
(because the destination AS will check the light-weight signature), 
which means one itself can be protected when it deploys sth. 
When serious spoofing traffic happens, the alliance can enable some diff-serv for members, 
to make sure the packets originated from alliance member ASes won't be dropped.
So that's somehow the incentive model of E2E solution for SP to deploy.  
At least we saw some SP showed interestes.

thanks,
Jun

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon Mar 19 08:50:31 2007

"interest" does not equal a business case for deployment. If it was,
BCP38 would be on every outward facing customer port on the planet. It
is not. If people are interesting to understanding why, speak up. If
not, continue down the academic exercise.  

> From: Jun Bi [mailto:[email-masked]] 
> Sent: Sunday, March 18, 2007 5:01 PM
> To: Barry Greene (bgreene); Pekka Savola; Mark Williams
> The source address space of a member AS is protected within 
> the alliance (because the destination AS will check the 
> light-weight signature), which means one itself can be 
> protected when it deploys sth. 
> When serious spoofing traffic happens, the alliance can 
> enable some diff-serv for members, to make sure the packets 
> originated from alliance member ASes won't be dropped.
> To: "Jun Bi" <[email-masked]>; "Pekka Savola" 
> <[email-masked]>; "Mark Williams" <[email-masked]>

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Mon Mar 19 15:56:08 2007

CERNET2 is in the middle of deployment. I don't think SAVA is totally against BCP 38. 

But I don't think BCP 38 can resolves everything (e.g. problems of incremental deployment and incentive, as most of the community agrees).
So I may say, BCO 38 is good for some cases, but is not enough..
Beyond e2e solution for intra-AS case in our testbed, Ingress filtering is also part of our testbed for intra-AS cases, 
because it would be easy for one AS to fully deployed. 

You can still argue some technical details, but I think the most important at this stage is to have a WG to  identify the problem and 
define ta architecture/framework so that solutions can be designed following the framework and more protocols can 
be presented to resolve the problem. 
Since the problem is there, SAVA is a good place to identify the problems and push the solutions and deployments..

thanks,
Jun

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon Mar 19 18:58:43 2007

Barry,
> is not.
Right. But BCP38 has still been useful, and IMHO a good
thing for the Internet. The question in front of us is whether
SAVA has something that is good for the Internet, would
be deployed at least to some extent, and would be worth
more than the costs (such as having to modify router
forwarding path)?

There's rarely a possibility to get everyone to deploy something.
There will for sure be ISPs that simply do not care, or believe
(right or wrong) that botnets are the major issue, or whatever.
But I don't think its a requirement to get everyone on board.
We know what the situation is with BCP38. Will SAVA make
things better, or worse?

Jari