Subject: Re: [savi] On the Protection of Unused Addresses

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 19:16:04 +0200

Christian,

Christian Vogt escribió:
> On Jun 23, 2009, Fred Baker wrote on thread "Your opinion on a different
> tradeoff for SAVI":
>
>> SAVI without protecting unused addresses is pointless.
>
>
> Fred and all -
>
> Protection of unused addresses would, of course, be a useful feature.
> But before making this mandatory, we should do a benefit-cost analysis.
> Here is one, along with a proposal of how to move forward:
>
> The benefit of protecting unused addresses is that it prevents an
> attacker from hiding its identity or location.
i am not sure what do you mean by this...
I mean, the attacker will need to use a topologically correct address, 
since we are asuming ingress filtering
then within the prefix, it can use any unused address, if not SAVI will 
drop it. The only question is whether it shoudl perform a DAD previously 
doing it or not
So, i fail to see what is the concept of protecting unused addresses...

>   An attacker who wants to
> do this can use any source address as long as it is not its own address.
> Protecting unused addresses is especially useful in networks where DHCP
> is the only permitted method for address configuration, since those
> networks are in control of which addresses are used.
right, i can see that having value in a dhcp based network

>   On the other hand,
> in networks where Stateless Address Autoconfiguration is permitted, it
> is up to the (potentially malicious) hosts which addresses are used.
> Protecting unused addresses then has little benefit:  All it achieves is
> requiring an attacker to formally turn an unused address into a used
> address by sending a DAD solicitation.
exactly

morevoer, it does has a problem, that if the DAD packet gets lost, the 
host is blocked, even if from the host perspective, the DAD was succesfull

>
> The cost of protecting unused addresses is a need to coordinate multiple
> SAVI devices on the same link.

well for me the major (and unacceptable cost) is that we require that 
the SAVI device sees a DAD before letting the a source address flow

what if the DAD packet was lost? from the host perspective, it was 
succesful, cause there were no replies, but the SAVI device will block 
it from the network, and only because the DAD packet was lost. It seems 
hardly a good design to me

>   If this coordination does not exist, or
> is insufficient, legitimate packets may get dropped, because one SAVI
> device may consider unused an address that is in fact in use at another
> SAVI device.  Coordination between SAVI devices, in turn, can be
> accomplished in one of two ways:
>
> - By partitioning the scope of SAVI protection into one area per SAVI
>   device.  This requires manual configuration of SAVI devices, since
>   switch ports that connect to other SAVI devices must be labeled as
>   such. Link partitioning is the approach of the CPS solution.
>
> - By synchronizing binding state across SAVI devices so that each SAVI
>   device can validate addresses from anywhere else on the link.  This
>   requires an extra binding distribution protocol, plus extra memory
>   for binding state copied from other SAVI devices.  Synchronization
>   was proposed as an add-on to the original FCFS solution.
>
> Either form of coordination implies an undesired cost for protecting
> unused addresses.  Given this cost, and given that the main benefit is
> in networks where DHCP is the only permitted address configuration
> method, a potential way to move forward may be to make the protection
> of unused addresses optional and limited to those DHCP-only networks.

i think i can live with that
i would like to understand the implications on a dhcp based solution
> More specifically, we could add an optional "DHCP-only mode" to SAVI,
> in which SAVI devices would permit only those addresses that have been
> explicitly assigned via DHCP.  In DHCP-only mode, SAVI devices would:
>
> - Create bindings only based on DHCP address assignments, but not based
>   on DAD solicitations.
>
> - Drop packets with unused source addresses.
>
> As a method for inter-SAVI-device coordination, I suggest partitioning
> the scope of SAVI protection.  Thus, network administrators who enable
> DHCP-only mode may also have to manually designate switch ports that
> connect to other SAVI devices.  This extra manual configuration should
> be acceptable given that the DHCP-only mode already needs to be turned
> on manually.  At the same time, link partitioning avoids the extra
> complexity and manufacturing cost that synchronization would entail.
>
mmm, i think it may be possible to achieve similar benefits without 
configuring port per port. I actually think it would be easier to 
configure a shared secret in every savi device than to manually define 
device by device which port is used for what function

Regards, marcelo

> What do folks think?  Would this be a reasonable approach?
>
> - Christian
>
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 19:20:32 +0200

Christian Vogt escribió:
> Folks -
>
> I would like to solicit more feedback on the benefit-cost analysis
> (below) for protecting unused addresses. How valuable do people consider
> protection of unused addresses, how much cost do they think is OK?  Is
> there something that the analysis overlooks?  We already got several
> very useful comments from a few people.  What do the others think?
>
> To recap:  We need to decide between the following three options of
> dealing with unused addresses:
>
i think you need to define what is an unused address
In dhcp, it is clear and i think it makes sense
In statelsss address autconfiguration, it means an address for which the 
savi device has not seen a DAD? If so, i think the definition is broken, 
cause the address can be legitmatelly assigned to a host but still 
fulfill the definition of unused.

> - Not protect unused addresses, i.e., forward packets without a binding.
>   Logging is still possible, though.
>
> - Protect unused addresses, and coordinate SAVI devices on the same link
>   by manually disabling SAVI protection on ports connecting to other
>   SAVI devices.
>
> - Protect unused addresses, and coordinate SAVI devices on the same link
>   with a dedicated binding synchronization protocol.
>

I personally don't think it is feasible to define what an unused address 
is from the SAVI perspective. I don't agree with the definition of an 
address being unused if there was no DAD before as seen by the SAVI 
device. So i think the SAVI device has no means to figure out if an 
address is legitiamlly used or not in the case stateless addres autoconf 
is being used

About the other options, i don't know....

> Please send your feedback by Sunday, July 5.  We will vote after that.
>
> - Christian
>
>
>
> On Jun 24, 2009, Christian Vogt wrote:
>
>> attacker from hiding its identity or location.  An attacker who wants to
>> networks are in control of which addresses are used.  On the other hand,
>> SAVI devices on the same link.  If this coordination does not exist, or

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 19:22:18 +0200

Joel M. Halpern escribió:
> While I appreciate Christian's question, I think that this is part of 
> a larger pair of questions that we talk around, but do not address.
>
> 1) What threats are we actually trying to protect against.  The 
> threats draft talks about general internet threats and the need to be 
> able to track them back.  But it is not particularly clear about what 
> behavioral threats we are actually concerned with stopping in SAVI
> - Are we concerned with ensure that every packet leaving a site can be 
> reliably tracked back to a human being
> - Are we concerned with preventing one device within a site from 
> masquerading as another device, either at the IP or MAC layer.
>
> 2) What tools do we want to require or prohibit.  While we probably do 
> not want to mandate a single tool set, without mandating something we 
> get nowhere.  Possibilities include
> - restricting mobility (with or without session continuity)
> - Requiring MAC or IP authentication (*02.1X, SEND, ...)
> - Requiring central management of addressing and bindings
>
> No, those are not all the alternatives.  As far as I can tell from 
> watching this list, there are folks who take as given the need for 
> almost any subset of these and related constraints you can imagine. 
> Unless we pick, explicitly, we will continue to argue in circles.
i agree with this
i guess that now that we understnad the problem space a bit better, e 
could try to define more precisely what are the requirements for a solution

Regards, marcelo

>
> For example, the question of controlling unregistered addresses turns 
> on assumptions about what threats we are addressing, and assumptions 
> about address allocation that mean that "unregistered" is a meaningful 
> condition.  I don't object to that particular pair, but it is really 
> hard to discuss the acceptability of answers without agreeing on the 
> questions.
>
> Yours,
> Joel M. Halpern
>
> Christian Vogt wrote:
>> Folks -
>>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 13:54:24 -0700

> device by device which port is used for what function

Interesting.  Should SAVI devices use this shared secret to synchronize
binding state, or to automatically partition the scope of SAVI
protection?  I am assuming the latter, since you mention it as an
alternative to manual partitioning.  But in the latter case, how would
this work, in particular in the presence of legacy switches?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 14:02:15 -0700

> i am not sure what do you mean by this... I mean, the attacker will  
> need
> to use a topologically correct address, since we are asuming ingress
> filtering then within the prefix, it can use any unused address, if  
> not
> SAVI will drop it. The only question is whether it shoudl perform a  
> DAD
> previously doing it or not So, i fail to see what is the concept of
> protecting unused addresses...

Marcelo -

Even in the presence of ingress filtering, source addresses with a
correct prefix, but spoofed interface identifier, could still permit an
attacker to conceal its identify or location.  The effectiveness of this
concealment depends on the size and structure of the link.

This said, I do agree with your statement that protection of unused
addresses is of limited benefit in networks that allow Stateless Address
Autoconfiguration -- as I explained in my previous email.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 04 Jul 2009 09:59:20 +0200

> this work, in particular in the presence of legacy switches?

I understand that what you are after is to configure that a valid dhcp 
server or a SAVI switch are connected to a given port of a given SAVI 
switch, in order to provide some level of security (i.e. that a attacker 
cannot pretend to be a valid dhcp server or another SAVI switch.)

I think that this would require to manually configure each SAVI device 
to state which ports are SAVI switches and which port are dhcp servers. 
this may not require any protocol change but i think it would be quite 
burdesome and would require a very careful topology control.
Using a shared secret woudl allow to identify dhcp servers and savi 
switeches without that careful manual configuration of ports. OTOH, it 
would require some protocol indeed.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 04 Jul 2009 10:03:26 +0200

Christian Vogt escribió:
>> i am not sure what do you mean by this... I mean, the attacker will need
>> filtering then within the prefix, it can use any unused address, if not
>> SAVI will drop it. The only question is whether it shoudl perform a DAD
> attacker to conceal its identify or location.
that i don't understand. I think you are making some assumption of what 
is the meaning of using a spoofed interface identifier.
for me, spoofing a interface identifier means using someone's interface 
identifier. If the interface identifier is not being used, it is not 
spoofing it. I mean, why using a source address that is not being used 
is spoofing? I can perfectly configure that address manually in my 
interface and i am using it.
Is it because there was no DAD before? well, the DAD msg could have been 
lost, so there is no way for a SAVI device to tell if the node didn't 
send the DAD msg.

Regards, marcelo

>   The effectiveness of this

---

From: Christian Vogt <[email-masked]>
Date: Sun, 5 Jul 2009 15:54:24 -0700

Forking off from thread "On the Protection of Unused Addresses"

> would require some protocol indeed.

Avoiding manual configuration would indeed be of advantage.  Yet I am
still not sure whether shared secrets would permit auto-configuration.

The reason is this:  Knowledge of the presence of other SAVI devices or
DHCP servers on a particular port is useful only if those SAVI devices
and DHCP servers attach /directly/ to the port.  If they do not attach
directly, one may want to treat the port just like a port without other
SAVI devices or DHCP servers.  An example of a scenario where this
happens is a port trunk with both legacy switches and SAVI devices.

So using a shared secret for SAVI devices to auto-detect ports with
other SAVI devices and DHCP servers would be useful only if the SAVI
devices could detect whether those other SAVI devices and DHCP servers
attach directly.  I don't see how this could be realized.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Sun, 5 Jul 2009 16:14:38 -0700

On Jul 4, 2009, marcelo bagnulo braun wrote:

> interface and i am using it. Is it because there was no DAD before?
> well, the DAD msg could have been lost, so there is no way for a SAVI
> device to tell if the node didn't send the DAD msg.

Marcelo and all -

The text that you, Marcelo, are commenting on was my summary of other
working group members' motivation for protecting unused addresses.  I
would like those working group members to respond to Marcelo's comments
if they still think that unused addresses should be protected in
networks that permit SLAAC.

Personally, I think Marcelo's arguments do make sense.  In fact, I was
coming to a similar conclusion in my analysis in [1].

- Christian

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

---

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

> attach directly.  I don't see how this could be realized.

right
i agree that manuallly configuring what is connected to which port 
provides a different set of capabilities than a shared secret
However, depending what we are looking for, the features provided by a 
shared secret may be what is needed.
Anycase, i think that maybe we should leave the this discussion for a 
concrete case.

Regards, marcelo

---

From: "Greg Daley" <[email-masked]>
Date: Tue, 7 Jul 2009 17:53:21 +1000

Hi Christian, 

Shared secrets make sense in order to prevent misconfiguration or
misbehaviour amongst
the LAN.

If there is no authentication, it is possible to trivially pretend to be
a SAVI
device (which defeats the purpose).

While manual configuration would need to be minimal, if security is
required, it
cannot be avoided.

Greg

> > switeches without that careful manual configuration of 
> > ports. OTOH, it would require some protocol indeed.
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 7 Jul 2009 13:17:19 -0700

This is correct, Greg.  My comments were related to somethings else.

My comments were related to automatic configuration of SAVI devices
regarding which ports attach to hosts, which attach to legacy switches,
and which attach to other SAVI devices.  Such configuration would be
useful to avoid binding and logging redundancies across multiple SAVI
devices.  My point here was that automatic configuration does not work,
even if it was protected by shared secrets, because there is no way to
detect the existence of legacy switches in between two SAVI devices.

I agree that shared secrets may be useful for other purposes.

- Christian

On Jul 7, 2009, Greg Daley wrote:

> misbehaviour amongst the LAN.
>
> a SAVI device (which defeats the purpose).
>
> required, it cannot be avoided.
>
> Greg