Subject: [Ecrit] LLDP-MED in phonebcp

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 11 Jan 2007 13:39:19 -0500

I'm a bit concerned about the suggestion that LLDP-MED be implemented in all consumer VoIP devices. Specifically, I'm worried about security.

I haven't found any document that attempts to describe the security risks of devices that advertise themselves with LLDP, and that are on either a consumer LAN (assumed to generally have no other LLDP devices) or on a public non-LLDP network (such as a hotspot). If this security information exists, I'd appreciate being pointed to it. LLDP seems to be very much designed to operate in an enterprise environment, where network administrators exist, and where devices can generally trust each other. 

Is there some way for a device to determine whether the network it is in is truly LLDP-enabled, before it starts sending out LLDP messages?

LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED multicast messages received from a wireless device, to other wireless devices. But I assume that a non-LLDP-capable AP would mindlessly broadcast. What does this mean in a hotspot environment? Could someone else on the hotspot have a device that maliciously configures devices through LLDP and LLDP-MED?

Is it possible to write a trojan that would reside on a PC, and could maliciously configure devices in a non-LLDP-capable consumer LAN?

I really don't know enough. Would it be possible/appropriate for one of the LLDP proponents to provide verbiage for the "Security Considerations" section of phonebcp? I'm not convinced that the normative references adequately address security concerns of its use in these non-enterprise networks. 

When should a device attempt to get location through LLDP? Would it be appropriate for a device to only try it if DHCP and L7 fail?

Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Fri, 12 Jan 2007 14:17:42 -0500

Hi Barbara, list. 

I've also added a couple of the other LLDP-MED authors in CC here, 
who are familiar with the ECRIT problem space. 

> I'm a bit concerned about the suggestion that LLDP-MED be implemented 
> in all consumer VoIP devices. Specifically, I'm worried about 
> security. 
> 
> I haven't found any document that attempts to describe the security 
> risks of devices that advertise themselves with LLDP, and that are 
> on either a consumer LAN (assumed to generally have no other LLDP 
> devices) or on a public non-LLDP network (such as a hotspot). If 
> this > security information exists, I'd appreciate being pointed to 
> it. LLDP seems to be very much designed to operate in an enterprise 
> environment, where network administrators exist, and where devices 
> can generally trust each other. 
...
> I really don't know enough. Would it be possible/appropriate for one 
> of the LLDP proponents to provide verbiage for the "Security 
> Considerations" section of phonebcp? I'm not convinced that the 
> normative references adequately address security concerns of its use 
> in these non-enterprise networks. 

OK, here goes. 

First, I certainly agree completely that Security Considerations 
content on LLDP-MED, and the other methods also of course, would be a 
very good thing!  It should include considerations for consumer and 
public networks, as well as enterprise ones, and also both wired and 
wireless.  I'd be more than happy to contribute specific text for 
LLDP-MED in this, but let's bash it out on the list a bit first. 
Please count on me for that (really to Brian Rosen here I assume). 

We believe LLDP (and by inference LLDP-MED extensions) do not open 
significant security risks in a wired environment, and certainly not 
relative to DHCP methods.  We also believe that LLDP-MED is also quite 
manageable in a wireless environment, where DHCP does not appear to be 
a very good option (IMHO).  Can't really comment on merits relative to 
L7 methods at this point, since they are not actually settled.  This 
is for the following key reasons: 

o LLDP frames, hence LLDP-MED extensions as well, are link specific. 
  Hence any attack on the end device would need to be "on-wire" (ie 
  effectively same as PSTN today, physical wiretap scenario).  More 
  details on this below. 

o Also since LLDP does not propagate past the single link, attacks from 
  "higher" in the infrastructure are not possible through it (as can be 
  the case for DHCP for example). 

o The information supplied from the device towards the network 
  infrastructure is only ever sent to the upstream L2 switch, not 
  propagated beyond it, and mechanisms to extract the information 
  (SNMP MIBs) can readily be secured. 

o Information sent from the network infrastructure towards the device 
  (specifically location objects in this discussion) is either strictly 
  device-specific (wired case) or equally applicable to all devices in 
  the broadcast (wireless AP case).  In the latter case, if the 
  information cannot be made generic to all, then LLDP would not be 
  configured -- it is the administrator's choice. 

Now, some more detailed answers to your questions ...

> Is there some way for a device to determine whether the network it 
> is in is truly LLDP-enabled, before it starts sending out LLDP 
> messages? 

Not really.  The device could passively listen for LLDP before 
initiating its LLDP-MED, but that would add time to the startup (bad) 
and really only indicates the upstream L2 entity *says* it is LLDP 
compliant. I do not see this as a real risk however, unless the 
upstream device is compromised of course, but then all bets are off 
for all methods. 

> LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED 
> multicast messages received from a wireless device, to other 
> wireless devices. But I assume that a non-LLDP-capable AP would 
> mindlessly broadcast. What does this mean in a hotspot environment? 
> Could someone else on the hotspot have a device that maliciously 
> configures devices through LLDP and LLDP-MED?

No, that would not be possible.  Reasons for this are as follows 
(sorry, lots of details for full understanding). 

The LLDP-MED multicast address falls within the IEEE 802.1D block of
reserved BPDU addresses, that must not be forwarded by a compliant Media
Access Control Bridge (including APs).  This reserved address list also
includes Spanning Tree BPDUs, 802.1X PAE, and LLDP.  Packets to these
destinations must not be forwarded, whether or not the bridge supports
that protocol.  As such a properly implemented AP will not forward LLDP,
even if the AP doesn't support LLDP.

In addition, most Ethernet switches used for public access services
support 'private VLANs' specifically designed to prevent this type of
connectivity between devices on the same access switches.  This feature
is frequently deployed to prevent  clients with rogue DHCP 
service from bringing down the network by misconfiguring all devices in 
the local subnet.  This private VLAN feature also will prevent LLDP-MED 
flooding between clients.

Many APs in public hot-spots have a similar feature, specifically to
prevent two clients on the same AP from communicating directly. 

That being said, some APs are not properly implemented/configured and
will mindlessly broadcast.  (This will cause lots of other grief 
outside of LLDP also.)  If this should occur, then multiple location 
mechanisms are beneficial to help identify configuration conflicts 
and/or rogue devices.  When multiple formats are provided and there is 
a conflict, this *should* be brought to the users and/or administrator's 
attention. 

> Is it possible to write a trojan that would reside on a PC, and could 
> maliciously configure devices in a non-LLDP-capable consumer LAN?

No, for reasons above. 

> When should a device attempt to get location through LLDP? Would it 
> be appropriate for a device to only try it if DHCP and L7 fail?

This is not a security question, it is a reliability one, at least in 
my mind.  I personally believe LLDP-MED should be tried first, then DHCP, 
then L7.  This is in network layered order, from bottom up, closest 
source first.  It is also "least moving parts" first order, hence most 
likely to be reliable.  All this is IMHO at this point, certainly open 
to debate. 

I hope this helps.  Sorry for the rather long reply. 

Cheers,
Peter Blatherwick 
(Editor, ANSI/TIA-1057 / LLDP-MED)

"Stark, Barbara" <[email-masked]>
11.01.07 13:39
 
        To:     "ECRIT" <[email-masked]>
        cc: 
        Subject:        [Ecrit] LLDP-MED in phonebcp

I'm a bit concerned about the suggestion that LLDP-MED be implemented in 
all consumer VoIP devices. Specifically, I'm worried about security.
I haven't found any document that attempts to describe the security risks 
of devices that advertise themselves with LLDP, and that are on either a 
consumer LAN (assumed to generally have no other LLDP devices) or on a 
public non-LLDP network (such as a hotspot). If this security information 
exists, I'd appreciate being pointed to it. LLDP seems to be very much 
designed to operate in an enterprise environment, where network 
administrators exist, and where devices can generally trust each other. 
Is there some way for a device to determine whether the network it is in 
is truly LLDP-enabled, before it starts sending out LLDP messages?
LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED multicast 
messages received from a wireless device, to other wireless devices. But I 
assume that a non-LLDP-capable AP would mindlessly broadcast. What does 
this mean in a hotspot environment? Could someone else on the hotspot have 
a device that maliciously configures devices through LLDP and LLDP-MED?
Is it possible to write a trojan that would reside on a PC, and could 
maliciously configure devices in a non-LLDP-capable consumer LAN?
I really don't know enough. Would it be possible/appropriate for one of 
the LLDP proponents to provide verbiage for the "Security Considerations" 
section of phonebcp? I'm not convinced that the normative references 
adequately address security concerns of its use in these non-enterprise 
networks. 
When should a device attempt to get location through LLDP? Would it be 
appropriate for a device to only try it if DHCP and L7 fail?
Barbara 
*****
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential, proprietary, and/or 
privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by 
persons or entities other than the intended recipient is prohibited. If 
you received this in error, please contact the sender and delete the 
material from all computers. GA621
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 12 Jan 2007 14:41:26 -0500

Thanks! That was extremely helpful and informative. I appreciate the
level of detail.
Barbara

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 12, 2007 2:18 PM
> To: Stark, Barbara
> Cc: ECRIT; Dan Romascanu; Manfred Arndt
> Subject: Re: [Ecrit] LLDP-MED in phonebcp
> 
> 
> Hi Barbara, list. 
> 
> multicast