Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

From: "Guang Yao" <[email-masked]>
Date: Mon, 27 Oct 2008 15:28:11 +0800

WARNING: contains banned part

Subject: RE: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]
From: "Guang Yao" <[email-masked]>
To: <[email-masked]>
Date: Mon, 27 Oct 2008 15:28:11 +0800

Dear Marcelo,

It's a good effort. This mechanism greatly conforms to the charter. 
But I still have some questions on your method:
1 Once there is an entry in the SAVI DB, and the LIFETIME has not expired,
there is only a check on the binding of layer2 and IP address. 
But the layer2 information is not secure. In this period, an attacker can
spoof its layer2 address and the IP address to pass the verification.
So I think there may need some enforcement to improve the security during
this period. And how does this mechanism handle two interfaces of a host
using same addresses to do flow balancing?

2 It may happen that during a LIFETIME, the host with an address changed its
address, which meaning it abandons the ownership of this address. But
the address still cannot be used by other hosts, though this behavior cannot
be regarded as spoofing. It may trouble if the LIFETIME is long. But too
short
LIFETIME means frequent NUD processes. So it is better to choose a proper
LIFETIME.

3 Maybe the cost to decide whether a packet is spoofing in "If an entry is
found and the layer-2 information of the received
data packet does not match the information contained in the existing
matching entry" is too heavy? It seems rather easy to launch DoS attack
at this procedure, just by spoofing a lot of layer 2 addresses.

4 As I know, when SeND is used, the CGA address must be used. Maybe this
mechanism must be modified to adapt DHCP and manual configuration.

Guang Yao
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
[email-masked]
发送时间: 2008年10月27日 3:00
收件人: [email-masked]
主题: savi Digest, Vol 5, Issue 13

Send savi mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/savi
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of savi digest..."

Today's Topics:

   1. [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]
      (marcelo bagnulo braun)

----------------------------------------------------------------------

Message: 1
Date: Sun, 26 Oct 2008 17:20:21 +0100
From: marcelo bagnulo braun <[email-masked]>
Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]
To: SAVI Mailing List <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Hi,

I have submitted a draft describing how to build a SAVI solution using 
the SeND protocol without any change to the hosts nor to the SeND 
protocol. I think the resulting security level is pretty good.

Comments would be appreciated.

Regards, marcelo

-------- Mensaje original --------
Asunto: 	I-D Action:draft-bagnulo-savi-send-00.txt
Fecha: 	Sun, 26 Oct 2008 09:15:01 -0700 (PDT)
De: 	[email-masked]
Responder a: 	[email-masked]
Para: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : SeND-based Source-Address Validation
Implementation
	Author(s)       : M. Bagnulo
	Filename        : draft-bagnulo-savi-send-00.txt
	Pages           : 10
	Date            : 2008-10-26

This memo describes SeND SAVI, a mechanism to provide source address
validation using the SeND protocol.  The proposed mechanism is
intended to complement ingress filtering techniques to provide a
higher granularity on the control of the source addresses used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bagnulo-savi-send-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-------------- next part --------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Parte del mensaje adjunto
Url:
<http://www.ietf.org/pipermail/savi/attachments/20081026/55b87e02/attachment
-0001.bat>

------------------------------

_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi

End of savi Digest, Vol 5, Issue 13
***********************************

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Oct 2008 09:09:43 +0100

Hi,

thanks for your comments, see replies below...

Guang Yao escribió:
>
> ------------------------------------------------------------------------
>
> Asunto:
> RE: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]
> De:
> "Guang Yao" <[email-masked]>
> Fecha:
> Mon, 27 Oct 2008 15:28:11 +0800
> Para:
> <[email-masked]>
>
> Para:
> <[email-masked]>
>
>
> Dear Marcelo,
>
right SeND provides security of the ND messages not of actually data packets
So the trust chain isIP address to MAC address using sned security and
then we trust the mac address

> But the layer2 information is not secure. 

well, depends right?
If you are using a switched ethernet, i would say that it is pretty
secure, right? I mean, if you have associated the IP address using send
with the mac address AND the port, then the resultng security is quite
strong imho. I mean an attacker needs to know the MAC address AND be
physically connected to the port, whoc seems quite hard.

OTOH, if you are using a plain hub (i am not sure where you are going to
get those, i use them for teaching and they are extremely hard to find)
then anyone in the link could spoof you mac address and reconfigure
their lan card to use the same mac address than you and then use your ip
address.

If you are using other layer2, we need to consider it. I mean, i agree
that this relies on the layer 2 security, indeed.
> In this period, an attacker can
depends on how easy to trick the layer 2 is

> this period.

well, we do, depending on the layer 2. As i said, switched ethernet does
provides this
>  And how does this mechanism handle two interfaces of a host
there is no problem with that, this case is explicitly covered in the
draft, please check it out there
but the main idea is that since address ownership is provided by cgas,
we can creat multiple bindings between the CGA and a layer 2 address in
a secure manner, no problem here afaict

> be regarded as spoofing.

are you talking about two hosts having the same IPv6/CGA address? I
don't think this is very likely....the whole idea of cgas is that the
probability of collision is extremely low

>  It may trouble if the LIFETIME is long. But too
> short
well, i don't think lifetime in this case is that critical, as it only
affects the nud frequency

> at this procedure, just by spoofing a lot of layer 2 addresses.

No, cause the key to perfrom the search is the IP address NOT the MAC
address. So using many mac address is not a problem, since they can be
repeated in the SeND SAVI DB

> mechanism must be modified to adapt DHCP and manual configuration.

sure, CSI wg is chartered to do exactly that

Regards, marcelo

> ------------------------------------------------------------------------
>

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 27 Oct 2008 17:41:12 +0800

Hi,

Thanks for your replies. I made my comments below.

Best Regards,
Guang Yao

-----邮件原件-----
发件人: marcelo bagnulo braun [mailto:[email-masked]] 
发送时间: 2008年10月27日 16:10
收件人: Guang Yao
抄送: [email-masked]
主题: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

Hi,

well, depends right?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you choose a switched ethernet and the MAC address has been bound to the
switch port,
IP Source Guard is enough. IP Source Guard checks binding of
IP-MAC-Port, and the binding of MAC and port is used to ensure the security
of MAC.
Your mechanism checks IP-MAC, and supposes the MAC is secure. I think there
is not much difference in a switched ethernet.
Your mechanism can handle the mobility of layer 2 easily, which is an
advantage over IP Source Guard.
But actually I think IP Source Guard is able to handle mobility, too, by
enforcing SeND or making some other modification.

well, i don't think lifetime in this case is that critical, as it only
affects the nud frequency
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I see.:) 

No, cause the key to perfrom the search is the IP address NOT the MAC
address. So using many mac address is not a problem, since they can be
repeated in the SeND SAVI DB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I cannot quite understand your explaination...
I mean, if an attacker is sending a lot packets with spoofed mac but proper
IP, the check point has to
keep a state of all the spoofing packets and perform a lot of NUD. The cost
of discarding a single packet
is not much, but it is vulnerable under DoS attacks. Why not discard the
packets directly and use other
mechanisms to handle special issues?

sure, CSI wg is chartered to do exactly that
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Good, I will check their documents.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Oct 2008 11:42:00 +0100

but how do you actually prove that the sender is the owner of the IP
address then?
with CGA, SAVI knows for sure the owner of the address is in that port.
wihtout cgas, you just assue that right?
besdies, SeND based savi can support easily other confgurations such as
multiple interfaces with the same address, anycast and so on
In addition, with send, you can learn the prefixes in a secure manner
and the auhtorized routers, which are needed to properly perform the
savi validation

so, i think send provides quite a few advantages when doing this. Of
course the downside is that you need send deployed

i see, you mean that the savi function is susceptible to a DoS attack.
Yes, this is true indeed, as any function that requires state is subject
to this type of attack. I guess that if you are building such function,
you need to have enough memory and mange it well. OTOH, you know who the
attacker is, sicne you have it identified

regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 27 Oct 2008 22:50:37 +0800

Dear Marcelo,

Thank you for your contribution to the WG.

I fully support a solution with SeND. But a solution should handle the 
spoofable MAC address.
So if you want your solution work, please do more work to fix it.

CERNET (china education and research network) run 2000 university campus 
networks. We found the MAC address is spoofable, at least in 2 cases:
1) If you access with a WiFi AP, which is the common case in campus network,
2) MAC can be spoofed when using a HUB (multiple MAC addresses per link, as 
charter said). Using a hub is a common situation for at least 1/2 
universities for the dormitory network.

More comments below.

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Guang Yao" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 27, 2008 6:42 PM
Subject: Re: [savi] 答复: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

> you need to have enough memory and mange it well.

Could you please estimate how much the memory it requires?
Right now I don't mean it doesn't work, I mean in engineering, please give 
us the analysis or do an implementation and testing.
Giving the quantity analysis will be helpful to investigate the feasibility.

> OTOH, you know who the

In WiFi case and HUB case, if it is attacked with spoofed MAC address, then 
it world be hard to know who is the attacher.

thanks,
Jun Bi

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 27 Oct 2008 22:58:01 +0800

> sure, CSI wg is chartered to do exactly that

By running 200 IP v6 university campus networks in CERNET2, we mainly use 
stateless address and manual configuration,
sometimes consider DHCPv6.

As the charter required the solution should work with all address assignment 
mechanisms. I think at least it is mandatory to support manual 
configuration.

thanks,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Oct 2008 18:16:15 +0100

Jun Bi escribió:
> CERNET (china education and research network) run 2000 university
> campus networks. We found the MAC address is spoofable, at least in 2
> cases:
> 2) MAC can be spoofed when using a HUB (multiple MAC addresses per
> link, as charter said). Using a hub is a common situation for at least
> 1/2 universities for the dormitory network.
>
So any idea how would any solution would provide the level of security
you ask for and complies with the current charter, in particular with
the constraint of not changing the hosts?

I mean, it is not only because the charter says so, but because we need
to define a solution that is deployable. IMHO requiring hosts changes
for this is a non starter.
I think a solution like SeND SAVI or FCFS SAVI that don't requires host
changes is not perfect but styill is an increment of the current
situation and the deployment model seems to me quite strong.

> Right now I don't mean it doesn't work, I mean in engineering, please
> give us the analysis or do an implementation and testing.

Well, i would argue that this is similar to an ARP cache actually.
I mean the attacker could send more packets with different mac
addresses. The result is that the DB will overflow. No problem, since
the SAVI function will ask for a new NA again. This result in more
traffic, but there is no amplification.

regards, marcelo

> In WiFi case and HUB case, if it is attacked with spoofed MAC address,
> then it world be hard to know who is the attacher.
>
> thanks,
> Jun Bi
>
>
>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Oct 2008 18:20:16 +0100

Jun Bi escribió:
> By running 200 IP v6 university campus networks in CERNET2, we mainly
> use stateless address and manual configuration,
if you are interested in doing some work about CGAs and dhcp, please
contribute to the CSI wg
http://www.ietf.org/html.charters/csi-charter.html

> As the charter required the solution should work with all address
> assignment mechanisms. I think at least it is mandatory to support
> manual configuration.
>
sure, the same that i don't think it is reasonable to require send for
the solution.

the way i see it is if you happen to have send and cgas, then you can
achieve a higher level of security.
by no means i think a send based solution should be the only savi
solution. I only think that it makes sense to have a savi solution for
the case that send is available

regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Oct 2008 02:10:40 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 28, 2008 1:20 AM
Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

> the case that send is available

So you also agree that in some senarios required in savi charter, we need to 
consider other solutions.

thanks,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Oct 2008 19:27:41 +0100

Jun Bi escribió:
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
> So you also agree that in some senarios required in savi charter, we
> need to consider other solutions.
>

indeed!
however, i do think that these solutions should not require host changes
as it is stated in the charter

please check draft-bagnulo-savi-fcfs-00 recently posted for what i have
in mind about how other solutions could be

regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 28 Oct 2008 03:11:43 +0800

-----邮件原件-----
发件人: marcelo bagnulo braun [mailto:[email-masked]] 
发送时间: 2008年10月27日 18:42
收件人: Guang Yao
抄送: [email-masked]
主题: Re: 答复: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

so, i think send provides quite a few advantages when doing this. Of
course the downside is that you need send deployed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't mean SeND is not good. I mean IP Source Guard can also take
advantage of SeND.

i see, you mean that the savi function is susceptible to a DoS attack.
Yes, this is true indeed, as any function that requires state is subject
to this type of attack. I guess that if you are building such function,
you need to have enough memory and mange it well. OTOH, you know who the
attacker is, sicne you have it identified
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is much difficult for me to understand this point. How can I know who the
attacker is?

regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 28 Oct 2008 10:57:26 +0800

-----邮件原件-----
发件人: marcelo bagnulo braun [mailto:[email-masked]] 
发送时间: 2008年10月28日 3:25
收件人: Guang Yao
主题: Re: 答复: [savi] 答复: [Fwd: I-D
Action:draft-bagnulo-savi-send-00.txt]

Guang Yao escribió:
> 发送时间: 2008年10月28日 1:16
> 收件人: Jun Bi
> 抄送: Guang Yao; [email-masked]
> 主题: Re: [savi] 答复: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]
>
> Jun Bi escribió:
>   
>> Dear Marcelo,
>>
> I don’t think so. You forget the attack can make the DB overflow all the
> time and disable the mechanism totally.
> Some other mechanism must be used to protect the DB.
>   

No this is not true
If the db is overflowed, then the savi function will simply ask for NS
again, exactly the same when the ARP cache is overflowed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You must cache the spoofing packets and normal packets before NUD reply. 
This cache can be overflowed. Then you must choose either to drop all
packets 
or transmit all packets. Both of them are dangerous. The former will stop
the normal
communication and the later will allow spoofing.
Even you use a huge cache, the normal communication will be delayed greatly.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 28 Oct 2008 09:34:55 +0100

> again, exactly the same when the ARP cache is overflowed
but again, this is similar to the case of the ARP cache. I mean, when i
send an ARP request to a host, the target host will include the
information of the sender in the arp cache, so it is suceptible to the
same type of attacks. there are other ways you can achieve the same type
of attacks.
Moreover, in SeND it is even harder for the attacker to launch such
attach. In send, the good thing is that the verification of the CGA is
quite cheap (only verify a hash)
So, consider an attacker wants to launch an attack as the one you
mention. It will start sending packets. If the packets carry the same
source IP address, it is easy to detect and prevent (i.e. the SAVI
function only accepts 10 entries with a given source IP address or so)
If the packets carry different source IP address, then the attacker
needs to generate different IP address. Since the source addresses are
CGAs, the attacker needs to generate new CGA, which is an expensive
procedure (at least it is more expsnive to generate them than to verify
them, so the balance is reasonable to enable good defense)
You can next get a bit deeper into what information you store about the
CGAs in order to detect the same cga was used. It really depends on the
SEC value you are using. If you are using a sec value other than 0, then
you are probably ok, cause the CGA generation even with the same key is
expensive. If you use a SEC value of 0, then just changing the modifier
would do it. But in that case, you could actually store a hash of the
key itself and you are in good shape.

So, again, i don't see this attack as problematic

Regards, marcelo