Subject: [savi] comments on draft-mcpherson-savi-threat-scope-00

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 22 Sep 2008 17:56:22 +0200

Hi,

I have read draft-mcpherson-savi-threat-scope-00 and i have some 
comments and questions.

In section 2.  Overview it reads:

   Solutions such as BCP 38 [RFC 2827] provide guidelines for one such
   technique for network ingress filtering.  However, if these
   techniques are not implemented on 32-bit prefix boundaries at the
   ultimate ingress point of the IP network then the validity of the
   source address can not be positively ascertained.  Furthermore, BCP
   38 only implies source address verification at the Internet Layer,
   and is most often implemented on IP subnetwork address boundaries.

Right, but also i think we need to point out that BCP 38 is far from 
universal, so there are a lot of spoofed addresses around
I mean, when i read the previous paragraph and the following one, i got 
the impression that the only problem is that BCP 38 allows hosts within 
the same IP subnet to spoof each other addresses, and that's it.

So i guess i have a question and a comment:
The question is, is the idea to assume that BGP38 is deployed and that 
we will perform the threat analysis and find solutions for residual 
threats that are not covered by bcp38, or are we supposed to deal with 
the source address spoofing in a orthogonal way to bcp 38? (i understadn 
this is not the case, cause later sections seem to be more general than 
this)
If the question is that we are supposed to deal with the general problem 
and not only with the bcp 38 residual threats, i would suggest to 
rephrase both the previous and the following paragraph in order to make 
this clearer cause at least to me was a bit confusing.

   There is a possibility that in an LAN environment where multiple
   hosts share a single IP port on a switch or router, one of those
   hosts may source address spoof the source addresses of other hosts
   within the local subnet.  Understanding these threats and the
   relevant topologies in which they're introduced is critical when
   assessing the threats that exists with source address spoofing.

Later on in section 4.1.1.  Single Packet DoS

First of all, i am not sure if the title is the best one cause, the 
section discusses attacks that involve crashing the system, which seems 
to me a bit more than what i would call DoS. I would suggest to call 
this simply Single packet attacks maybe?

I find the section a bit too general on spoofed information, rather than 
focussing and detailing the particular effects of source address 
spoofing, which should be the focus imho
I mean, sending a single packet with spoofed information can generate an 
attack, indeed, Now, i guess the question is how many of these attacks 
rely on spoofing the source address? In other words, if we prevent 
spoofing the source address, do all these attacks go away? or is a 
subset of these attacks that disapear. I think the document should go a 
bit deeper into this and describe more in detail which address are 
enable thanks to source address spoofing and which could be completely 
prevented if we implement some source address validation. Moreover, the 
document could try to analyse if we did something like the scope of 
savi, like a local first hop verification, what is the set of these 
attacks that can be prevented?

Later on in section 4.1.2.  Flood-Based DoS

I liked this section very much
I think however, i may be worth to summarize which of these attacks are 
more relevant to SAVi and what can be expected from savi
 From what i understand from this section, there are 3 types of attacks 
described:
- one or more attackers flooding using their own source address (i, this 
case, savi has nothing to do here, cause there is no source address 
spoofed involved)
- one or more attackers flooding using spoofed source addresses (SVAI 
can help here, cause if savi is in place we would end up with the 
previous bullet only)
- attackers sending an attack using spoofed source address, but the 
ultimate goal is to get those addresses filtered, creating a long term 
attack for those spoofed source addresses (actually this is DoS attack 
to the owners of the source addresses, which can no longer access to the 
server). this attack would be completely removed with savi

Later in section 4.1.3.  Poisoning Attacks

I couldn't understand what is the difference between this section and 
section 4.1.1
Morevoer, i also think the comment i made for section 4.1.1. applies 
here, i.e. that i think the content should focus in the specifics of the 
attacks of soruce address spoofing and maybe also in the savi limited 
scope, i.e. the case of the first hop

Later in section 4.1.4.  Third Party Recon

Right, this seems more like a preparation for an attack than an attack 
itself. I mean, do these attacks have a particular impact other than 
enabling the next attack?

Now, what is the effect of source address spoofing? I mean, do attcker 
need to spoof the source address for this? Or do they spoof the source 
address in order not to reveal themselves?  i don't think we can prevent 
these attacks with a mechanism to prevent source address spoofing. To 
what extent we can help with source address spoofing prevention? In with 
the limited scope of savi?

Later in section 4.1.6.  Reflective Attacks

This makes perfect sense to me
I guess that we could do the same with a download using a tcp connection 
from a server, with a spoofed address, so that the server download hits 
the victim which address was spoofed.

Later on, in section 4.1.7.  Accounting Subversion

Do you have any specific protocol in mind that can be used for this?

Later, in section 4.1.8.  Other Blind Spoofing Attacks

   Other Blind spoofing attacks might include spoofing in order to
   exploit source routing or other policy based routing implemented in a
   network.

i would also benefit from more text here, cause i fail to understand 
what you have in mind here

Finally, what about attacks that imply injecting false routing 
information in the IGP? Do these need to be considered? I mean, routing 
protocols usually use the source address of the message to determine 
which router the message came from so, it seems that it would be an 
attractive target for an attcker, would this fall out of the scope of 
this analysis? If so, it may be worth mentioning. If not it may be worth 
analysing if these attacks should be included in the analysis.

Later on 5.5.  Spoofing In Local Area Network Segments

   On Link Layer segments where multiple hosts reside, or a single MAC
   address can be associated with a port or interface, if a binding
   between a hardware address (e.g., MAC address) and corresponding IP
   address(es) are not provisioned via some means (either manual or
   dynamic mechanisms), then an attacker may exploit attack vectors that
   enable MITM or other spoof-based attacks.

This section is a bit strange, it reads more like a threat than as a 
solution....

In section 5.10.2.  Automated Binding

are you planning to discuss IPv6 stateless address autoconfig? I don't 
know, but when the iid is obtained from the mad address, it maybe be 
trivial to perform the mapping

Later in section

5.11.  Cryptographic Techniques

   Needless to say, MITM and replay attacks can typically be mitigated
   with cryptographic techniques.  However, many of the applications
   today either don't or can't employ cryptographic authentication and
   protection mechanisms.

I am not sure how this would help the source address spoofing problem
I guess the crypto technique that could help, would the IPSec AH, since 
the source address is protected, but  not clear how an intermediate wold 
would check that. Could be checked at the end point though
However, i can't see how other of the availble crypte techniques could 
help with this particular problem

   ARP and DNS are two examples.  DNSSEC does
   propose to assist, but until it's deployed ubiquitously, from
   clients, to resolvers, to authoritative roots, clients and resolvers
   are still vulnerable to replay, cache poisoning and MITM attacks.

How is ARP an example?
How DNSsec help with the problem of source address spoofing? I mean, it 
could mitigate some the attacks that can be generated with spoof source 
address, but i am uncertain how how dnssec can help with the problem of 
source spoofing

We could talke about send and cgas, that even though they don't really 
tackle this problem, they seem close enough...

later in section 6.1.  Address Provisioning Mechanisms

   In a strictly static environment configuration management for access
   filters that map Link Layer and Network Layer addresses on a specific
   switch port might be a viable option.  However, most networks,
   certainly, those that accommodate actual human users, are much more
   dynamic in nature.  As such, mechanisms that provide port-MAC-IP
   bindings need to accommodate dynamic address allocation schemes
   enabled by protocols such as DHCP.

i would explicitly mention IPv6 SAA
maybe i would also mention dhcp prefix delegation

Later in section 6.2.2.  NATs

   Prefix-based and multi-address NATs also become problematic, for the
   same reasons as routers.  Because they may forward traffic from an
   array of address, a priori knowledge must exist providing what IPs
   should be associated with a given port-MAC pair.

I fail to see why nats are problematic. I mean, from the private side, 
nat is just as a router, so i don't think it deserves special consideration
 From the public side, the NAT only generates packets from its pools of 
public addresses, so, it is like a host with multiple IP addresses, 
which i don't think it is more problematic than a host with one address. 
You only need to associated multiple IP addresses to the MAC address and 
you are ok. So i fail to see what is specific to a nat that makes it 
worth discussing separated.

6.2.3.  Multi-Instance Hosts

I am not sure i understand what this is... it may be worth to include a 
definition of this in section 3. same goes for a blade server

Later, 6.2.4.  Multi-LAN Hosts

How common is the usage of the loopback address? I am familair with its 
usage in bgp, but never heard it in other conext

6.2.6.  Mobile IP

   Need to say something here, I think...  Mobile IP

Ok, let me do a first analysis of this

MIP has 3/4 elements that need to be considered, the CN, the MN, the HA

MIP4 only works in tunnel mode while mip6 works both in tunnel mode and 
in ro mode

Let's think about the different cases

MN in tunnel mode. It sends and receives packet form the HA in an IPsec 
tunnel with the right source address. no problem here afaict. (Actually, 
there were discussions about letting the MN to send the packet directly 
to the CN, but i understand that this was not done cause it would break 
with ingress filters :-)

MN in ro mode. it also sends packets with the right source address, and 
includes the HoA in the HoA option, so no problem here

CN in tunnel mode acts like a normal fixed host.
CN in RO mode always sends packet with its won fixed address, so no 
problem here

The HA in tunnel mode (HA is not involved in ro mode). I guess here is 
where the problems can arise. The HA is doing proxy ND, in order to 
capture the packets for the MN. when the MN is back home, it will claim 
the address back and we will see a change in the binding between the IP 
address and the MAC address.

6.2.7.  Other Topologies

maybe talking about proxy ND?

Later in section 7.  Applicability of Anti-Spoofing Solutions

   What works where, what's needed?

   Ingress filtering is useful, even with botnets using real addresses

   Ingress filtering on the admin border is not sufficient, and more
   fine-grained filtering from savi is necessary.

i guess you are planning to expand on this? in particular, i am not sure 
i understand the second statement

Later in section 8.  Deployment Considerations

I guess that another problem is that ISPs get paid for inyecting 
traffic, and if a client is sending packets with spoofed source address, 
but still paying, they don't have much incentives to filter this traffic.
I guess that a solution to work, must put the right incentives in place, 
so that ISPs prefer droping packets with spoofed IP address from paying 
customers rather than forwarding them

---

From: Danny McPherson <[email-masked]>
Date: Thu, 2 Oct 2008 10:47:04 -0600

Great comments, thanks for taking the time to review
so thoroughly Marcelo.  IF/When we publish an updated
version, we'll be sure to incorporate your input.

Thanks!

-danny

On Sep 22, 2008, at 9:56 AM, marcelo bagnulo braun wrote:

> I mean, when i read the previous paragraph and the following one, i  
> got the impression that the only problem is that BCP 38 allows hosts  
> within the same IP subnet to spoof each other addresses, and that's  
> it.
>
> The question is, is the idea to assume that BGP38 is deployed and  
> that we will perform the threat analysis and find solutions for  
> residual threats that are not covered by bcp38, or are we supposed  
> to deal with the source address spoofing in a orthogonal way to bcp  
> 38? (i understadn this is not the case, cause later sections seem to  
> be more general than this)
> If the question is that we are supposed to deal with the general  
> problem and not only with the bcp 38 residual threats, i would  
> suggest to rephrase both the previous and the following paragraph in  
> order to make this clearer cause at least to me was a bit confusing.
>
>
> section discusses attacks that involve crashing the system, which  
> seems to me a bit more than what i would call DoS. I would suggest  
> to call this simply Single packet attacks maybe?
>
> I find the section a bit too general on spoofed information, rather  
> than focussing and detailing the particular effects of source  
> address spoofing, which should be the focus imho
> I mean, sending a single packet with spoofed information can  
> generate an attack, indeed, Now, i guess the question is how many of  
> these attacks rely on spoofing the source address? In other words,  
> if we prevent spoofing the source address, do all these attacks go  
> away? or is a subset of these attacks that disapear. I think the  
> document should go a bit deeper into this and describe more in  
> detail which address are enable thanks to source address spoofing  
> and which could be completely prevented if we implement some source  
> address validation. Moreover, the document could try to analyse if  
> we did something like the scope of savi, like a local first hop  
> verification, what is the set of these attacks that can be prevented?
>
>
> I think however, i may be worth to summarize which of these attacks  
> are more relevant to SAVi and what can be expected from savi
> From what i understand from this section, there are 3 types of  
> attacks described:
> - one or more attackers flooding using their own source address (i,  
> this case, savi has nothing to do here, cause there is no source  
> address spoofed involved)
> - one or more attackers flooding using spoofed source addresses  
> (SVAI can help here, cause if savi is in place we would end up with  
> the previous bullet only)
> ultimate goal is to get those addresses filtered, creating a long  
> term attack for those spoofed source addresses (actually this is DoS  
> attack to the owners of the source addresses, which can no longer  
> access to the server). this attack would be completely removed with  
> savi
>
> I couldn't understand what is the difference between this section  
> and section 4.1.1
> here, i.e. that i think the content should focus in the specifics of  
> the attacks of soruce address spoofing and maybe also in the savi  
> limited scope, i.e. the case of the first hop
>
>
> Right, this seems more like a preparation for an attack than an  
> attack itself. I mean, do these attacks have a particular impact  
> other than enabling the next attack?
>
> Now, what is the effect of source address spoofing? I mean, do  
> attcker need to spoof the source address for this? Or do they spoof  
> the source address in order not to reveal themselves?  i don't think  
> we can prevent these attacks with a mechanism to prevent source  
> address spoofing. To what extent we can help with source address  
> spoofing prevention? In with the limited scope of savi?
>
> I guess that we could do the same with a download using a tcp  
> connection from a server, with a spoofed address, so that the server  
> download hits the victim which address was spoofed.
>
> information in the IGP? Do these need to be considered? I mean,  
> routing protocols usually use the source address of the message to  
> determine which router the message came from so, it seems that it  
> would be an attractive target for an attcker, would this fall out of  
> the scope of this analysis? If so, it may be worth mentioning. If  
> not it may be worth analysing if these attacks should be included in  
> the analysis.
>
>
> are you planning to discuss IPv6 stateless address autoconfig? I  
> don't know, but when the iid is obtained from the mad address, it  
> maybe be trivial to perform the mapping
>
>
> Later in section
>
>
> I guess the crypto technique that could help, would the IPSec AH,  
> since the source address is protected, but  not clear how an  
> intermediate wold would check that. Could be checked at the end  
> point though
> However, i can't see how other of the availble crypte techniques  
> could help with this particular problem
>
>
>
> How DNSsec help with the problem of source address spoofing? I mean,  
> it could mitigate some the attacks that can be generated with spoof  
> source address, but i am uncertain how how dnssec can help with the  
> problem of source spoofing
>
> We could talke about send and cgas, that even though they don't  
> really tackle this problem, they seem close enough...
>
> I fail to see why nats are problematic. I mean, from the private  
> side, nat is just as a router, so i don't think it deserves special  
> consideration
> From the public side, the NAT only generates packets from its pools  
> of public addresses, so, it is like a host with multiple IP  
> addresses, which i don't think it is more problematic than a host  
> with one address. You only need to associated multiple IP addresses  
> to the MAC address and you are ok. So i fail to see what is specific  
> to a nat that makes it worth discussing separated.
>
>
> I am not sure i understand what this is... it may be worth to  
> include a definition of this in section 3. same goes for a blade  
> server
>
> How common is the usage of the loopback address? I am familair with  
> its usage in bgp, but never heard it in other conext
>
> 6.2.6.  Mobile IP
>
>
> MIP4 only works in tunnel mode while mip6 works both in tunnel mode  
> and in ro mode
>
> MN in tunnel mode. It sends and receives packet form the HA in an  
> IPsec tunnel with the right source address. no problem here afaict.  
> (Actually, there were discussions about letting the MN to send the  
> packet directly to the CN, but i understand that this was not done  
> cause it would break with ingress filters :-)
>
> MN in ro mode. it also sends packets with the right source address,  
> and includes the HoA in the HoA option, so no problem here
>
> The HA in tunnel mode (HA is not involved in ro mode). I guess here  
> is where the problems can arise. The HA is doing proxy ND, in order  
> to capture the packets for the MN. when the MN is back home, it will  
> claim the address back and we will see a change in the binding  
> between the IP address and the MAC address.
>
>
> 6.2.7.  Other Topologies
>
>
> i guess you are planning to expand on this? in particular, i am not  
> sure i understand the second statement
>
> traffic, and if a client is sending packets with spoofed source  
> address, but still paying, they don't have much incentives to filter  
> this traffic.
> I guess that a solution to work, must put the right incentives in  
> place, so that ISPs prefer droping packets with spoofed IP address  
> from paying customers rather than forwarding them
>
>
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: Christian Vogt <[email-masked]>
Date: Sun, 12 Oct 2008 03:23:32 +0300

Marcelo,

thanks a lot for reviewing the Threats document so carefully.  I agree
with your comments and think that the next version of the document
should reflect them.  In many of your comments, you are suggesting that
the treats identified in the document should be accompanied by analyses
on whether/how SAVI could eliminate the threats.  These analyses should
definitely be added to the document in my opinion.  One of the roles of
the Threats document is to serve as a problem statement and motivation
for SAVI, and the analyses you are suggesting would come up to this.

Fred and Danny:  Do you guys think you can address Marcelo's comments
and questions with a revision of the Threats document before IETF 73?
Optimally, we would have a ready-to-publish version of the Threats
document by then.

Finally, my responses to some of Marcelo's comments:

> Marcelo bagnulo braun wrote:
>
> universal, so there are a lot of spoofed addresses around I mean,  
> when i
> read the previous paragraph and the following one, i got the  
> impression
> that the only problem is that BCP 38 allows hosts within the same IP
> subnet to spoof each other addresses, and that's it.
>
> So i guess i have a question and a comment: The question is, is the  
> idea
> to assume that BGP38 is deployed and that we will perform the threat
> analysis and find solutions for residual threats that are not  
> covered by
> bcp38, or are we supposed to deal with the source address spoofing  
> in a
> orthogonal way to bcp 38? (i understadn this is not the case, cause
> later sections seem to be more general than this) If the question is
> that we are supposed to deal with the general problem and not only  
> with
> the bcp 38 residual threats, i would suggest to rephrase both the
> previous and the following paragraph in order to make this clearer  
> cause
> at least to me was a bit confusing.

Since the document is an analysis of the current security state of the
Internet regarding spoofed source addresses, it cannot assume that BCP
38 is universally deployed.  So you are right that we are supposed to
deal with the general problem, as you call it.

> seems
> than
> spoofing, which should be the focus imho I mean, sending a single  
> packet
> with spoofed information can generate an attack, indeed, Now, i guess
> the question is how many of these attacks rely on spoofing the source
> address?

The attacks described in this section do indeed rely on source address
spoofing.  But I agree that this could (and should) be clarified.

> I liked this section very much I think however, i may be worth to
> summarize which of these attacks are more relevant to SAVi and what  
> can
> be expected from savi From what i understand from this section, there
> are 3 types of attacks described:
>
> - one or more attackers flooding using
> their own source address (i, this case, savi has nothing to do here,
> cause there is no source address spoofed involved)
>
> - one or more
> attackers flooding using spoofed source addresses (SVAI can help here,
> cause if savi is in place we would end up with the previous bullet  
> only)
>

I like this categorization of flooding attacks.

> section 4.1.1 Morevoer, i also think the comment i made for section
> 4.1.1. applies here, i.e. that i think the content should focus in the
> specifics of the attacks of soruce address spoofing and maybe also in
> the savi limited scope, i.e. the case of the first hop

Perhaps section 4.1.3 could be merged with section 4.1.1?

> This makes perfect sense to me I guess that we could do the same  
> with a
> download using a tcp connection from a server, with a spoofed address,
> so that the server download hits the victim which address was spoofed.

I agree with your comment.  In addition, maybe this section could be
merged with section 4.1.2, "Flood-Based DoS"?  The attacks described in
both sections seem to fall into the same class.

> routing

This is an excellent suggestion.  If SAVI could protect against such IGP
attacks, then this would be an excellent motivation to deploy SAVI.
Note that ingress filtering offers no protection against IGP attacks
unless it is deployed on (or very close to) access links -- which in
most deployment cases it is not.

- Christian