Subject: [savi] Suggested Voting Questions on Protecting Unused Addresses

From: Christian Vogt <[email-masked]>
Date: Sun, 5 Jul 2009 20:20:41 -0700

Folks -

Thank you for the good discussion on the protection of unused addresses.
While this discussion continues, I would like to agree with you on the
questions that we should eventually ask to conclude the discussion and
determine rough consensus.  I would like to suggest the following two
questions, plus the corresponding answer options, and I am asking for
your feedback on those:

(1) For which address configuration methods should SAVI protect unused
     addresses?

     (1a) For all address configuration methods, including SLAAC.

     (1b) Only when DHCP is the only permitted address configuration
          method.

     (1c) Unused addresses never have to be protected.

(2) If your answer to question (1) is (1a):  How should SAVI minimize
     the risk of classifying a legitimate address unused, thus
     preventing a legitimate host from communicating?

     (2a) By protecting unused addresses only on ports with directly
          attached hosts.  This requires manual configuration of SAVI
          devices.

     (2b) By synchronizing bindings across SAVI devices so that SAVI
          devices are reliably informed of which addresses are in use  
and
          which are unused.  This requires a dedicated new protocol.

     (2c) It is OK to occasionally prevent a legitimate host from
          communicating.

Please provide your feedback on these questions by Thursday, July 9.  Do
you think these questions are fine?  Would you like to make changes?

The final, potentially modified questions will be posted on Friday, July
10, for voting.

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 06 Jul 2009 00:00:03 -0400

Please first define "unused address".  It makes a big difference whether 
you mean "currently unused by any other machine on the savi net" vs 
"legitimately usable by this machine".
Also, please define what threat we are evaluating this against.  various 
combinations are viable against certain threats, and not against other.

Personally, rather than deciding on an abstract, I would find it 
sensible to decide on whether a particular strategy was worthwhile due 
to the protection it provided against specified threats.  Deciding to 
use or not use a mechanism in the abstract seems backwards to me.

Hence, my impression is that this is the wrong question.

Yours,
Joel

Christian Vogt wrote:
>          devices are reliably informed of which addresses are in use and
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 10:17:15 +0200

Hi,

As Joel commented, i think you need to define what do you mean by unused 
address, especially in the SLAAC case.

One definition is that the address is not configured as  preferred in 
any host. That would be an accurate definition imho, but it is difficult 
to evaluate from the perspective of a SAVI device.

So the definition that can be actually be verified by an external SAVI 
device and what i think it is actually being discussed here is that an 
unused address is an address for which there has not been a previous 
(succesuful) DAD procedure.

So in the SLAAC case, i think the question that should be asked is 
whether it is ok to block packets for which the SAVI device has not seen 
a successful DAD procedure.

Regards, marcelo

---

From: Frank Xia <[email-masked]>
Date: Mon, 06 Jul 2009 10:48:25 -0500

Hi Christian

Please check my choice...

BR
Frank
----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Sent: Sunday, July 05, 2009 10:20 PM
Subject: [savi] Suggested Voting Questions on Protecting Unused Addresses

>     (1c) Unused addresses never have to be protected.
Frank=>OK.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 6 Jul 2009 10:17:37 -0700

Joel -

> "legitimately usable by this machine".

It is the former:  An "unused address" is an address that is currently
not in use by any host on the SAVI network.

> combinations are viable against certain threats, and not against  

Protecting unused addresses would help preventing attacks in which the
attacker needs to conceal its identity.  This includes certain
virus-spread distributed DoS attacks.

(In general, another reason for an attacker to grab unused addresses is
to conceal its location.  But this is irrelevant for our discussion
given that SAVI's use of ingress filtering makes location concealment
impossible.)

> use or not use a mechanism in the abstract seems backwards to me.

Please clarify:  By "strategy", do you mean a particular mechanism?
Would you like to rather vote on, say, Marcelo's proposal [1], which
does not protect unused addresses, in combination with a mode for
DHCP-only networks that does protect unused addresses [2]?

- Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html
[2] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jul 2009 11:58:47 -0700

> not in use by any host on the SAVI network.

Personally, I think the question has to be about the addresses we know  
that a host is authorized to use, as opposed to "excluding all  
others". Either has the effect of excluding all others, but the  
addresses a host is known to be authorized to use is something that  
the SAVI switch can honestly know.

If we are not preventing hosts from using addresses that they aren't  
authorized to use, I don't know what we are doing here.

To my way of thinking, if a network is using DHCPv6, the only  
addresses a host should transmit from are those it has been assigned.  
Cold stop.

To my way of thinking, if a network is using SLAAC, the switch should  
be able to observe that it has used the procedure. If the host has not  
used the procedure with respect to an address it emits, a SAVI switch  
should not just learn it, it should stop it. If it does not do so,  
consider all the attacks in which a host uses a foreign address once  
and tell me that SAVI has been helpful in any way in attack management.

As for manual configuration, I don't think there is an obvious way to  
detect that apart from manually configuring the switch as well. So if  
a SAVI switch is used in a network, that is a side-effect of that  
decision.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 21:35:34 +0200

> addresses a host should transmit from are those it has been assigned. 
i agree with this
DHCP can be seen as an device to authorize a node to use an address and 
if by default (i.e. if the node cannot communicate with the dhcp server) 
then the node won't use any address.

(one concern with this is implementation wise, in particular i wonder 
what would happen if the savi switch reboots and looses the information 
it gathereed snooping dhcp messages, how it can recover it, but 
certainly we can think of ways to solve this)

> and tell me that SAVI has been helpful in any way in attack management.
the problem with this is that the node, if the DAD msg is lost, the node 
thinks the DAD procedure has been succesfull. So, as opposed to the dhcp 
case, the default action here is to use the address. So this is why i 
think it is not possible for an external device like the savi switch to 
know if a node is authorized to use an address

Besides, if an attacker wants to use an address, it only needs to do a 
DAD procedure and the savi will let it use it, so i fail to see what 
attack we are preventing by this.

> a SAVI switch is used in a network, that is a side-effect of that 
manually configured addresses (as well a dhcp assigned addresses must 
also perform the DAD procedure i think, so the same could apply here i guess

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jul 2009 13:05:05 -0700

On Jul 6, 2009, at 12:35 PM, marcelo bagnulo braun wrote:

> Besides, if an attacker wants to use an address, it only needs to do  
> a DAD procedure and the savi will let it use it, so i fail to see  
> what attack we are preventing by this.

If it uses a DAD procedure, it has allocated the address to itself. In  
such a case, SAVI *should* allow it.

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jul 2009 13:20:04 -0700

If it has correctly allocated the address, and then uses it to  
perpetrate an attack, we can track the attack to the source. Remember,  
the fundamental issue SAVI was trying to prevent was perpetration of  
attacks that could not be racked to their source, generally due to  
address spoofing.

Not all attacks use improper addresses; those that use proper  
addresses can be tracked to their source. We're trying to prevent  
improper use of addresses.

Just letting the thing fly fails to ensure that it can be tracked to  
its source.

On Jul 6, 2009, at 1:06 PM, marcelo bagnulo braun wrote:

>>> Besides, if an attacker wants to use an address, it only needs to  
>>> do a DAD procedure and the savi will let it use it, so i fail to  
>>> see what attack we are preventing by this.
>>
>> If it uses a DAD procedure, it has allocated the address to itself.  
>> In such a case, SAVI *should* allow it.
>>
> Right, so what kind of attack are we preventing by requiring an  
> attacker to perform a DADprocedure before using an address?
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 22:30:13 +0200

Fred Baker escribió:
> perpetrate an attack, we can track the attack to the source.

but we can track it even if it didn't performed the DAd. Moreover, an 
address that we have not seen a previous DAD, it would look more 
suspicious and would trigger the logging capabiltiies easier.

I mean, the SAVI device can perfectly let the packet through (in case 
the user is legimtate usingt he address but the DAD msg got lost) but 
still logging the packet, so it can be traced back in case it is an 
attacker.

> Remember, the fundamental issue SAVI was trying to prevent was 
> perpetration of attacks that could not be racked to their source, 
> generally due to address spoofing.
>
the option that would then accomplish all the goals would be to let the 
packet through and log these packets as well, i guess

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 22:06:46 +0200

> such a case, SAVI *should* allow it.
Right, so what kind of attack are we preventing by requiring an attacker 
to perform a DADprocedure before using an address?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 06 Jul 2009 19:18:44 -0400

I believe that there is a disconnect here.
Assume a wireless infrastructure.
Assume SLAAC / DAD.
Assume that the malicious host has some way to guess when some other 
node is turn off / unavailable, etc.

In that case, the malicious host
1) Switches its MAC address to that of some other host
2) uses DAD
3) Does bad things
4) turns off

Note that if the site is not providing persistent logs of the IP 
anchoring, then step 1 (and the concomitant knowledge of some other MAC 
address) is also not needed, as after th attack there is no traceability.

For a wired infrastructre, if logs are generated at the edge SAVI 
switch, then the log of the DAD binding, and what port it was received 
on, is indeed sufficient.
That assumes logs and wired infrastructure.

This is why I am asking that folks provide clarity on both the threats 
they believe need to be dealt with, and the assumptions that they are 
prepared to make.

Yours,
Joel

PS: I tend to like combinations like logs+802.1x (plus simultaneous 
usage prevention), or logs+CGA.  But I can not tell what assumptions the 
WG is prepared to make.

Fred Baker wrote:
> Not all attacks use improper addresses; those that use proper addresses 
> can be tracked to their source. We're trying to prevent improper use of 
> addresses.
> 
> Just letting the thing fly fails to ensure that it can be tracked to its 
> source.
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jul 2009 22:21:40 -0700

> Assume a wireless infrastructure.

The first disconnect is that we aren't allowed to work on wireless  
infrastructures.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 07 Jul 2009 09:06:17 +0200

Joel,

SAVI will provide security of data packets by creating a binding between 
the IP source address and a L2 anchor. This means that the SAVI will 
learn that a given IP source address corresponds to a given L2 anchor 
and will make that binding and after that will only accept packets 
containing that IP source address when coming from that L2 anchor.

Now, it is clear that the security of any SAVI solution will be as 
strong as the L2 anchor.

There are many different L2 anchors we can use.
One of them are L2 source addresses i.e. MAC source addresses.
The problem with these is that they can be forged easily, so the 
resulting solution is not very secure. I think this is orthogonal to the 
fact we use DAD or SLAAC. The same thing can happen with dhcp. I 
understnad that this is a problem of the strength of the L2 anchor.

OTOH, we can use switch ports as L2 anchors. These are much more secure 
imho. We can use them in wired netwroks and i understand that in some 
wireless networks, where crpto is used a each host has different crypto 
material, the result is similar.

So, i agree with you, in some cases the attacks are very easy, but the 
solution of this rely on using better L2 anchors imho

So about the assumptions you mention below, i think our default case 
should be the case where we use ports as L2 anchors.
Do you think we need to make more assumptions? I don't feel at this 
point we need to assume CGAs. I do think logging will be an essential 
part of SAVI, cause it is what will allow to trace back attackers

Regards, marcelo

Joel M. Halpern escribió:
> anchoring, then step 1 (and the concomitant knowledge of some other 
> MAC address) is also not needed, as after th attack there is no 
> traceability.
>
> usage prevention), or logs+CGA.  But I can not tell what assumptions 
> the WG is prepared to make.
>
> Fred Baker wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Jul 2009 07:46:06 -0400

I rechecked the charter.  There is nothing I could find in there which 
says that SAVI shall build solutions which address only wired ethernet. 
   (It also does not say we will avoid thicknet, but I am prepared to 
assume that, since it just is not in use anywhere.)

Given that many corporations use wireless in their office environments, 
without an explicit statement saying that is out of scope, I do not see 
how I can assume that.

I will readily agree that if that is out of scope, then we have 
different assumptions that can be made.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Jul 2009 08:03:59 -0400

I do understand that SAVI needs to work with different binding anchors.
I can live with a description that says that the SAVI binding anchor 
will have property "X".
For example, declaring that the bindings will have the property of 
reliably selecting a specific physical machine is one way to separate 
the problems.  I am concerned because with the different assumptions 
folks are prepared to make, this may be harder than it looks. The 
realities needed to meet that constraint, and the tightness of the 
applicability statement required to meet that, may be more than people 
would assume.  (Physically moving machines is commonly doable in 
commercial environments.)

Yours,
Joel

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Jul 2009 08:31:54 -0700

OK, I must be remembering an earlier version of the charter. At one  
point we were told that we were only working on switched Ethernet.  
That fact was used to shut me up during one of the BOFs.

On Jul 7, 2009, at 4:46 AM, Joel M. Halpern wrote:

> I rechecked the charter.  There is nothing I could find in there  
> which says that SAVI shall build solutions which address only wired  
> ethernet.   (It also does not say we will avoid thicknet, but I am  
> prepared to assume that, since it just is not in use anywhere.)
>
> Given that many corporations use wireless in their office  
> environments, without an explicit statement saying that is out of  
> scope, I do not see how I can assume that.
>

---

From: Dong Zhang <[email-masked]>
Date: Sat, 11 Jul 2009 09:54:10 +0800

>usage prevention), or logs+CGA.  But I can not tell what assumptions the 
Imho, CGA makes it easier to do the source address check.:) 
I agree CGA is a good thing used here when the source address is configured 
by CGA.

------------------				 
Dong Zhang        
2009-07-11

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 11 Jul 2009 09:55:35 +0200

> I agree CGA is a good thing used here when the source address is configured 

please check the send savi draft about how to use CGAs and SeND for SAVI

Regards, marcelo

---

From: Dong Zhang <[email-masked]>
Date: Sat, 11 Jul 2009 16:29:20 +0800

marcelo bagnulo braun 2009-07-11 Wrote:
>Dong Zhang escribi?
I mean CGA provides good features for savi.
Yse, after you published this draft, I already have read it. 
Thank you for the reminder.:)

------------------				 
Dong Zhang
2009-07-11