Subject: [savi] Lower-Layer Binding Anchors

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Oct 2008 23:44:17 +0200

Folks,

since our charter requires SAVI to not change hosts, a SAVI device will
necessarily have to bind IP addresses to a property of layers below IP.
This is because, in the absence of host changes, properties of lower
layers are the only reasonably trustworthy information about a packet
sender that shows up in all packets.  The question hence is which
lower-layer properties, or lower-layer "binding anchors", are most
appropriate for this purpose.

In the design taxonomy [1] that Bill and I presented in Dublin, we
identified two suitable lower-layer binding anchors:  link-layer
addresses and switch ports.  The design taxonomy also includes an
analysis of which challenging situations (mobility, multi-homing, etc.)
each binding anchor can handle.  I would like to take this as a basis
for a discussion with you on which binding anchor, or which combination,
you folks deem more appropriate.

One possible approach would be to define a set of possible binding
anchors, and leave it up to the administrator to choose one or more of
them.  We should, of course, explain the pros and cons of the different
binding anchors.  And we could define a default setup.

- Christian

[1] http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2008 08:24:37 +0200 (EET)

> appropriate for this purpose.

If lower-layer address is chosen, we assume that the lower-layer 
address spoofability is prevented, yes? (E.g. using MAC address 
locking in switches).  Usually that is not done by default however, 
and doing so is challenging in many environments (e.g. a virtual 
server or a blade server connected to a switch port, having 20 or 30 
MAC addresses in one extreme; office network with roaming laptops in 
another).

Would port-based be a more widely applicable (default) solution?

-- 
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: ZhangDong <[email-masked]>
Date: Fri, 31 Oct 2008 15:08:29 +0800

>  addresses and switch ports.  
I do not think link-layer address cannot be spoofed.
One important thing is that we must guarantee reliability and reality of the source information(e.g. link-layer address) which the SAVI device obtains for binding. 
This is the premise of binding. 

Dong Zhang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 10:10:57 +0100

Hi Christian,

My view on this is that whatever we do, if we bind the IP address to the 
layer 2 information, we are improving the security.
If we simply bind it to the MAC address and not further checks are 
applied, we are making a very limited increment, but still is better 
than nothing in an environment where you are very constrained, cause 
essentially you are assuming no layer 2 security, no configurnation of 
MAC address enforcement no port switching and so on.
If we have more capable layer 2, we can provide much better security so 
SAVI would improve the security considerably.

My point is that depending the scenario you are asuming and the 
constraints about not being able to mae changes in the host, then you 
may not have many options

more below...

> binding anchors.  And we could define a default setup.
yes, and i think draft-baker-sava-implementation has a very good 
starting poitn for this:

section 2.1.  Trust anchors of draft-baker-sava-implementation reads:

   In short, the implementation approach requires neighboring devices to
   associate a layer 3 entity addressed with an IPv6 address with a
   layer 2 entity.  The identification of the layer 2 entity may take a
   number of forms:

   o  On a traditional Ethernet or for a host or router attached to a
      switched Ethernet, the only real option is association with the
      MAC Address.

   o  The switch, however, may be able to associate the IPv6 address
      with a switch port if it knows that only one host is attached to
      the port.

   o  In a wireless network, there are often layer 2 security
      associations between neighboring devices, and the address can be
      associated with that security association.

   o  In a Cable Modem network, the address may be associated with the
      combination of a MAC address and a customer relationship.

   o  In a classical DSL network, it may be associated with an ATM
      Virtual Channel, or a PPPoE or L2TP Session ID.

   o  In some cases, an IP/IP tunnel, an MPLS LSP, or similar tunneling
      technology is taken to a single system.  In such cases, local
      address validation can be applied to the use of the tunnel.

   The key is to have a solid understanding of

   o  what identifies a neighbor in the context: a MAC Address, a switch
      port, an ATM VC, or whatever,

   o  what addresses one's neighbor is in fact using, and

   o  to limit what one accepts from the neighbor as so identified to
      that which the neighbor is legitimately using.

   One could argue that this runs counter to the Robustness Principle,
   which is stated in RFC 793 as "be conservative in what you do, be
   liberal in what you accept from others."  In fact, it follows the
   Robustness Principle, but adds the Russian proverb made famous in the
   west by Ronald Reagan: "Trust, but verify".

Now, with respect to the defaul case, i am not sure you can do that
I mean, is not that there is a defaul layer 2 out there
IMHO, what we can do is a list (similar to the one Fred has) and explain 
for each case what can be achieved

Regards, marcelo

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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 14:08:05 +0200

On Oct 31, 2008, marcelo bagnulo braun wrote:

> My view on this is that whatever we do, if we bind the IP address to  
> the layer 2 information, we are improving the security.
> essentially you are assuming no layer 2 security, no configurnation  
> of MAC address enforcement no port switching and so on.
> If we have more capable layer 2, we can provide much better security  
> so SAVI would improve the security considerably.

Yes, we are on the same page.

[...]

> I mean, is not that there is a defaul layer 2 out there

But since the SAVI charter wants us to focus on Ethernet, we may use  
MAC addresses as a default.

Having said that, I agree that we should also come up with a list of  
alternatives, along with the benefits and shortfalls of each.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 15:43:12 +0200

Pekka and Zhang Dong,

you are of course right that MAC addresses fail to render a secure  
binding anchor because they can be spoofed without much effort.  But  
in some cases, we may have to rely on them anyway.

Having said this, I agree with you that we should use a more secure  
binding anchor whenever possible.  And this makes me reconsider what I  

> MAC addresses as a default.

Perhaps it would be better to define the default as:  Use switch ports  
when available, and MAC addresses otherwise.  Or:  Use MAC addresses,  
and switch ports in addition if available.

What do you think?

- Christian

On Oct 31, 2008, ZhangDong wrote:

> One important thing is that we must guarantee reliability and  
> reality of the source information(e.g. link-layer address) which the  
> SAVI device obtains for binding.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Nov 2008 12:39:54 -0500

Hi,

It's been a while since I participated in IEEE 802.1, but I recall
them working on 802.1af(?) to provide link-layer security, and another
effort (don't remember the name) to standardize a link-layer identity.
If we want a more secure MAC address, could those be helpful here? Has
anybody been following IEEE 802.1?

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Vogt
> Sent: Friday, October 31, 2008 9:43 AM
> To: Pekka Savola; ZhangDong
> Cc: SAVI Mailing List
> Subject: Re: [savi] Lower-Layer Binding Anchors
> 
> Pekka and Zhang Dong,
>

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 5 Nov 2008 14:31:49 -0600

Yes.

But I am not sure I am qualified to determine how applicable
that work is to this question.

Current work that probably relates to this is in the projects
802.1X-REV (Revision to update/synchronize Port-based Network
Access Control) and 802.1AR (Secure Device Identifier).  It
looks to me as if 802.1X is what 802.1af evolved into.

--
Eric Gray
Principal Engineer
Ericsson  

> Behalf Of David Harrington
> Sent: Wednesday, November 05, 2008 12:40 PM
> To: 'Christian Vogt'; 'Pekka Savola'; 'ZhangDong'
> Cc: 'SAVI Mailing List'

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 00:38:16 +0200

Hi David,

this is interesting.

Note, however, that a recently agreed-upon goal of SAVI is to do with  
minimal requirements for SAVI deployment.  Requiring special crypto at  
the link layer would not be compatible with that goal.  Of course, it  
is certainly conceivable that, on the long run, one could devise a  
SAVI extension that makes use of the extra link layer security -- for  
those scenarios where it is available.

- Christian

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Nov 2008 18:08:03 -0500

802.1X seems to be widely deployed, so I wouldn't expect it be veruy
onerous.

dbh

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Wednesday, November 05, 2008 5:38 PM
> To: David Harrington
> Cc: 'Pekka Savola'; 'ZhangDong'; 'SAVI Mailing List'

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Nov 2008 15:09:25 -0800

lower layer elements would include the following, I think. Have I  
missed anything?
  - switch port or set of ports (as viewed by a switch)
  - MAC address or equivalent
  - radio channel or security association related to such
  - DSL VC-or-equivalent
  - Cable Modem customer channel

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Nov 2008 15:12:16 -0800

> MAC addresses as a default.

not necessarily. Since we can't change the hosts, and in the local LAN  
context "host" includes "router", we're talking about switches or  
hubs. Hubs may as well be physical wires, which brings us back to  
switches.

I think you'll find switches trusting their ports before they trust  
datagram content received on the ports. They want to say that a  
datagram received from some specific port should have some specific  
source address or from among some set of source addresses.

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 11:32:13 +0200

On Nov 6, 2008, Fred Baker wrote:

> not necessarily. Since we can't change the hosts, and in the local  
> LAN context "host" includes "router", we're talking about switches  
> or hubs. Hubs may as well be physical wires, which brings us back to  
> switches.

Correct.  Where SAVI is implemented on a switch, switch ports could  
also be used as a default lower-layer binding anchor.  Or the default  
binding anchor could be the combination of a switch port and a MAC  
address.

The combination of switch port and MAC address is actually my  
preference for a default binding anchor in this case.  The reason is  
that, if we used only a switch port as a binding anchor, then the  
source address validation would be of very coarse granularity if  
multiple hosts are connected to a single switch port.  Examples where  
this would be the case are (i) switch ports connected to other  
switches, or (ii) switch ports connected to Wi-Fi base stations.   
Using the MAC address in addition to the switch port in these cases  
will ensure that source address validation is still at the granularity  
of a single host.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 11:40:18 +0200

On Nov 6, 2008, Christian Vogt wrote:

> Of course, it is certainly conceivable that, on the long run, one  
> could devise a SAVI extension that makes use of the extra link layer  
> security -- for those scenarios where it is available.

Let me actually make an addition here:

Perhaps we don't even need an extension to SAVI in order to benefit  
from 802.1X-secured MAC addresses, because 802.1X and SAVI are  
completely independent of each other.  Still, if you deploy both and  
configure SAVI to use MAC addresses as binding anchors, then SAVI  
provides extra IP source address security thanks to the MAC addresses  
now being 802.1X-secured.

Comments?

- Christian

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Nov 2008 07:07:39 -0800

On Nov 6, 2008, at 1:32 AM, Christian Vogt wrote:

> preference for a default binding anchor in this case.

That makes sense, especially when the port in question is a trunk port  
- one to another switch.

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Nov 2008 07:08:05 -0800

On Nov 6, 2008, at 1:40 AM, Christian Vogt wrote:

> provides extra IP source address security thanks to the MAC  
> addresses now being 802.1X-secured.

It is stronger than one that is not secured, yes.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 6 Nov 2008 10:32:38 -0500

Hi,

I guess my concern is the other side of the coin:
if you deploy only SAVI and configure SAVI to use MAC addresses as
binding anchors, then SAVI  does not provide extra IP source address
security if the MAC addresses are not being 802.1X-secured. 

And even when 802.1X is used, 802.1X has had the problems of multiple
hosts being represented by a single MAC, MAC cloning, and other MAC
spoofing issues.

We need to be sure we do not mislead people into thinking that SAVI
makes IP source addresses more secure, when it does not necessarily do
that if the MAC is not secured.

I guess this raises the question of whether MAC-binding can be a
viable approach for validating IP src addresses, if we have no
reliable mechanisms for MAC address validation.

dbh

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 10:08 AM
> To: Christian Vogt
> Cc: David Harrington; SAVI Mailing List

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 06 Nov 2008 16:50:37 +0100

Hi,

I think that maybe one option is to define a the SAVI base spec with two 
parts:
First a general framework, where the SAVI functions binds the IP source 
address to a generic lower layer anchors left unspecified in the general 
framework).
Second, a set of annexes where we define what are those anchors for some 
well know technologies (such as the list Fred has defined)

Additionally,  we can support for new layer 2 technologies in additional 
document if needed

does this sounds like a feasible approach?

regards, marcelo

David Harrington escribió:
>>> Perhaps we don't even need an extension to SAVI in order to 
>>>       
>> benefit  
>>     
>>> completely independent of each other.  Still, if you deploy 
>>>       
>> both and  
>>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 19:24:28 +0200

Marcelo -

Yes, this modularization of the document would be really good.  And  
the list of possible binding anchors should have a brief statement for  
each binding anchor about the level of security provided.

The binding anchor list from Fred's document would be a good starting  
point.

- Christian

marcelo bagnulo braun wrote:

> Hi,
>
> I think that maybe one option is to define a the SAVI base spec with  
> two parts:
> First a general framework, where the SAVI functions binds the IP  
> source address to a generic lower layer anchors left unspecified in  
> the general framework).
> Second, a set of annexes where we define what are those anchors for  
> some well know technologies (such as the list Fred has defined)
>
> Additionally,  we can support for new layer 2 technologies in  
> additional document if needed
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 6 Nov 2008 12:31:54 -0500

Hi,

Be careful about trying to quantify "level of security provided". This
is highly dependent on the environment in which the solution is
deployed, and can be dramatically changed if a crypto algorithm is
"broken".

If you want to list potential binding anchors and their properties,
then you should focus on what threats are mitigated by each binding
anchor, the known security vulnerabilities for each binding anchor,
how those impact SAVI, and RECOMMENDED deployment approaches for use
with SAVI.

dbh

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 12:24 PM
> To: marcelo bagnulo braun
> Cc: David Harrington; 'Fred Baker'; 'SAVI Mailing List'

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 20:16:05 +0200

> how those impact SAVI, and RECOMMENDED deployment approaches for use

Right, I agree.  Recommending deployment approaches for use with SAVI
is a good idea as well.

- Christian

---

From: ZhangDong <[email-masked]>
Date: Fri, 07 Nov 2008 10:25:16 +0800

>  now being 802.1X-secured.

First of all, any lower-layer anchors used by SAVI solution for binding must be secure. Especially for MAC addresses, they may be forged easily.

Dong Zhang