Subject: [Ecrit] Some documents from DSL Forum

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Sep 2007 08:07:46 -0700

This message was also sent to GEOPRIV but please only reply to one list.

In my IETF AD Role I received some documents from DSL Forum that are  
of relevant to this WG. I have posted them at:

http://www.dial911anddie.com/DSLForum/WT-164v2.pdf

and

http://www.dial911anddie.com/DSLForum/WT-164v2-xls.pdf

Thanks, Cullen

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 21:57:34 +0200

Hi Cullen,
Hi all,

I read through the documents.

The text in the document can be classified into three types of feedback:

-- Protocol specific requirements
These are aspects that could be captured in the Phone BCP or are already 
found in the protocol specific documents itself.
I believe we have covered already most of these aspects (but we should 
double-check it).

-- Implementation-specific aspects
I am not sure how well we can capture these aspects in our documents. 
Still, they are fine with me.

-- Interactions between different protocols and timing.
There are a couple of timing aspects and protocol sequences (e.g., for 
retrieving location information). I am not so sure about these aspects. 
Is the timing reasonable? Is the sequence of retrieving location 
information reasonable and generic enough?

I think that the provided documents sound pretty reasonable to me. We 
need to figure out what aspects are not yet covered in our documents and 
then we should try to incorporate them. We need to discuss them obviously.

Help from members of the DSL forum would be useful.

Ciao
Hannes

PS: The text mentions that when the end host uses GPS then the device 
has t6 use it instead of fetching location info from the network. In the 
past a couple of WG members raised some security concerns.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Sep 2007 09:39:48 -0700

Sounds good. One thing that caught my attentions was in the gaps it  
mentions

Need to understand how long a device would need to wait for LLDP-MED and
DHCP INFORM responses, in networks that don’t support responses to these
protocols.

Any advice we can give on that? Would phonebcp be a reasonable place  
to address that?

On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote:

> These are aspects that could be captured in the Phone BCP or are  
> already found in the protocol specific documents itself.
> I believe we have covered already most of these aspects (but we  
> should double-check it).
>
> I am not sure how well we can capture these aspects in our  
> documents. Still, they are fine with me.
>
> There are a couple of timing aspects and protocol sequences (e.g.,  
> for retrieving location information). I am not so sure about these  
> aspects. Is the timing reasonable? Is the sequence of retrieving  
> location information reasonable and generic enough?
>
> I think that the provided documents sound pretty reasonable to me.  
> We need to figure out what aspects are not yet covered in our  
> documents and then we should try to incorporate them. We need to  
> discuss them obviously.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 17 Sep 2007 13:01:09 -0400

I'll put it in phonebcp but I don't know what the numbers should be

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Monday, September 17, 2007 12:40 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] Some documents from DSL Forum
> 
> 
> DHCP INFORM responses, in networks that don't support responses to these
> protocols.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 17 Sep 2007 19:45:58 +0200

LLDP has a periodic 'slow protocol' announcement timer which is
inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken.
A device is supposed to respond much faster (layer 2 single link
protocol) so this timer can be used as a default  worst case when facing
non-responsive devices.  

Dan

> Sent: Monday, September 17, 2007 6:40 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Sounds good. One thing that caught my attentions was in the 
> gaps it mentions
> 
> Need to understand how long a device would need to wait for 
> LLDP-MED and DHCP INFORM responses, in networks that don't 
> support responses to these protocols.
> 
> Any advice we can give on that? Would phonebcp be a 
> reasonable place to address that?
> 
> 
> > retrieving location information). I am not so sure about these

---

From: [email-masked]
Date: Tue, 18 Sep 2007 12:10:50 -0400

Hi, (adding also Barbara Stark, Ed of the DSL document), 

I also had a go tat the DSL Forum document -- looks pretty good overall. 
Also noted the "Known Gaps". 

> support responses to these protocols.

Adding some important details to Dan's... 
In LLDP-MED, a "Fast Start" procedure is used at startup (not present in 
basic LLDP).  In Fast Start. the Endpoint side initiates by transmitting a 
bust of -MED frames.  By default, 4 frames are sent at 1 sec interval. 
Before that time, the Network Connectivity side (ie the upstream L2 
switch) is only transmitting basic LLDP (not -MED extensions).  In 
response to seeing that first -MED frame come in, the Network Connectivity 
device then immediately begins transmitting -MED frames back, again 
starting with a burst of 4 frames at 1 sec interval by default.  So, as a 
result the Endpoint will learn its location (from the Location 
Identification TLVs) almost immediately at startup.  In my experience, 
this is typically measurable in handfuls of ms, certainly well under 1 
sec, unless there is frame loss (very rare in practice).  The whole Fast 
Start procedure takes 4 sec max, so that would make a good "didn't work" 
threshold. 

Note also that after startup phase, basic LLDP (and -MED by extension) 
will continue to advertise periodically at 30 sec interval by default (not 
5 sec as Dan suggests).  Also, due to basic LLDP behaviour, if any TLV 
information changes the change is immediately advertised, so if there is a 
change of location the Endpoint gets informed right away.  Thus, the 
location will always stay up to date after that point, with a maximum 
window of 30 sec. 

In the DSL document, the sequence flows in Appendix A look basically 
correct, the sequence of events looks good.  However a better value for 
"Was LLDP-MED successful" would be 4 sec.  Also, I do not see a "was it 
successful" decision for DHCP ("was location in DHCP response" only has a 
Yes result, and no timeout associated) -- probably helpful to add that. 

Noting this stuff would also be helpful in the Phone BCP I think.  (Brian 
already said he would do so.) 

I am not deep on the DHCP part of the question, so perhaps someone else 
can provide some details there.  However, I don't *think* there is any 
explicit threshold "didn't work" timer we could count on (could well be 
wrong on that).  In my experience, DHCP process takes longer than 
LLDP-MED. 

> Need requirements for soft client on a PC or PDA. These applications 
> will not have the ability to control LLDP or DHCP options, but 
> should be able to read them, if the underlying OS has requested 
> these options. 

Actually, LLDP / LLDP-MED does not necessarily need OS or driver support 
since it is defined above the MAC layer, though it would be nice of 
course.  PC / PDA apps could build in the LLDP-MED capability directly. 
(Again, unclear on the DHCP part of this question.) 

Cheers,
Peter Blatherwick (with Editor of LLDP-MED hat on)

"Romascanu, Dan (Dan)" <[email-masked]>
17.09.07 13:45
 
        To:     "Cullen Jennings" <[email-masked]>, "Hannes Tschofenig" 
<[email-masked]>
        cc:     ECRIT <[email-masked]>
        Subject:        RE: [Ecrit] Some documents from DSL Forum

Dan

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 18 Sep 2007 13:26:27 -0400

Thanks for all the really useful input on LLDP and LLDP-MED. I'll be
reflecting this in my next update. 
I need to better understand the implications of a client running
LLDP-MED, separate from the underlying OS. I would need for the client
to know whether or not the OS provided that function, before it tried.
If one client started doing it, then all the clients might decide they
wanted to do it, too, and it might just get out of hand.
There is a "known gap" on the DHCP INFORM timer, but not the standard
DHCP request. My logic there was that if a device is configured to do
DHCP for bootstrap, then it will be completely unable to do anything at
a higher layer (including make an emergency call), until it gets a
response. I have yet to find a mass market home network setup where auto
addressing works to get network connectivity, after DHCP failed. There's
usually a 60 second timer to try to get a response to DHCP DISCOVERY,
after which the device gives up. It may periodically try DHCP again, but
that's outside the scope of this document. I should probably try to fit
this failure into my chart, but I ran out of room.
 
As to Hannes request for help from the DSLF, I'm happy to help in any
way I can. I'll make sure they get any questions you need for them to
answer. Of course, I'm editor of this document, and am tracking all your
comments on this list. I'll do my best to be responsive, where I can
answer questions directly. I really would like to see as much as
possible be in phonebcp, and simply reference it. I have no intention of
being redundant, or of going against the recommendations in phonebcp.
Barbara

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 12:11 PM
To: ECRIT
Cc: Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan);
[email-masked]
Subject: RE: [Ecrit] Some documents from DSL Forum

Adding some important details to Dan's...     
In LLDP-MED, a "Fast Start" procedure is used at startup (not present in
basic LLDP).  In Fast Start. the Endpoint side initiates by transmitting
a bust of -MED frames.  By default, 4 frames are sent at 1 sec interval.
Before that time, the Network Connectivity side (ie the upstream L2
switch) is only transmitting basic LLDP (not -MED extensions).  In
response to seeing that first -MED frame come in, the Network
Connectivity device then immediately begins transmitting -MED frames
back, again starting with a burst of 4 frames at 1 sec interval by
default.  So, as a result the Endpoint will learn its location (from the
Location Identification TLVs) almost immediately at startup.  In my
experience, this is typically measurable in handfuls of ms, certainly
well under 1 sec, unless there is frame loss (very rare in practice).
The whole Fast Start procedure takes 4 sec max, so that would make a
good "didn't work" threshold.   

Note also that after startup phase, basic LLDP (and -MED by extension)
will continue to advertise periodically at 30 sec interval by default
(not 5 sec as Dan suggests).  Also, due to basic LLDP behaviour, if any
TLV information changes the change is immediately advertised, so if
there is a change of location the Endpoint gets informed right away.
Thus, the location will always stay up to date after that point, with a
maximum window of 30 sec.     

In the DSL document, the sequence flows in Appendix A look basically
correct, the sequence of events looks good.  However a better value for
"Was LLDP-MED successful" would be 4 sec.  Also, I do not see a "was it
successful" decision for DHCP ("was location in DHCP response" only has
a Yes result, and no timeout associated) -- probably helpful to add
that.   

Noting this stuff would also be helpful in the Phone BCP I think.
(Brian already said he would do so.)   

Cheers, 

17.09.07 13:45 

        To:        "Cullen Jennings" <[email-masked]>, "Hannes
Tschofenig" <[email-masked]> 
        cc:        ECRIT <[email-masked]> 
        Subject:        RE: [Ecrit] Some documents from DSL Forum

Dan

*****

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. GA625

---

From: [email-masked]
Date: Tue, 18 Sep 2007 14:16:57 -0400

Hi again Barbara,
Trying to answer some of your questions back, please see [PB] inline 
below. 
-- Peter

"Stark, Barbara" <[email-masked]>
18.09.07 13:26
 
        To:     <[email-masked]>, "ECRIT" <[email-masked]>
        cc:     "Cullen Jennings" <[email-masked]>, "Hannes Tschofenig" 
<[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>
        Subject:        RE: [Ecrit] Some documents from DSL Forum

Thanks for all the really useful input on LLDP and LLDP-MED. I'll be 
reflecting this in my next update. 
I need to better understand the implications of a client running LLDP-MED, 
separate from the underlying OS. I would need for the client to know 
whether or not the OS provided that function, before it tried. If one 
client started doing it, then all the clients might decide they wanted to 
do it, too, and it might just get out of hand.

[PB] I agree there are potential issues if multiple applications in a 
single Endpoint device all decided to start LLDP-MED.  (You are referring 
to these applications as "clients" I believe??)  Potentially, the first of 
those would get immediate response, but others would not see -MED coming 
back until the next normal advertising cycle.  Hence, OS support would be 
a good thing.  I do not see this as a big issue though, since location 
would only be out of date for a max of the advertising interval (30 sec 
default), and would be correct thereafter.  A bit more serious would be 
the implication on the Network Connectivity Device side, where it would 
potentially be receiving multiple sets of advertisements.  Not only would 
there be more traffic (a non-issue in practice, since it is constrained to 
the link), but if each app was advertising different TLVs then the info 
from one could continually get overridden with info from the other(s).  I 
would expect multiple apps all wanting to use LLDP-MED in a single device 
to be rare though, at least at this point. 

There is a "known gap" on the DHCP INFORM timer, but not the standard DHCP 
request. My logic there was that if a device is configured to do DHCP for 
bootstrap, then it will be completely unable to do anything at a higher 
layer (including make an emergency call), until it gets a response. I have 
yet to find a mass market home network setup where auto addressing works 
to get network connectivity, after DHCP failed. There's usually a 60 
second timer to try to get a response to DHCP DISCOVERY, after which the 
device gives up. It may periodically try DHCP again, but that's outside 
the scope of this document. I should probably try to fit this failure into 
my chart, but I ran out of room.
 
[PB] Yup, this makes sense now.  Yeah, the chart is pretty convoluted and 
hard to fit anything else into, but still think it would be good to 
include "No" paths from the "Was <method x> successful" decisions to the 
appropriate handling (which is LIS determination I would think). 

As to Hannes request for help from the DSLF, I'm happy to help in any way 
I can. I'll make sure they get any questions you need for them to answer. 
Of course, I'm editor of this document, and am tracking all your comments 
on this list. I'll do my best to be responsive, where I can answer 
questions directly. I really would like to see as much as possible be in 
phonebcp, and simply reference it. I have no intention of being redundant, 
or of going against the recommendations in phonebcp.
Barbara

Cheers, 

Dan

*****
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. GA625
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 18 Sep 2007 15:03:35 -0400

Thanks again for the LLDP-MED info. I'll feed it to the developer-types,
and see what they think.
I agree the DHCP failure scenario can be filled out a bit better. I'll
have to break my charts apart, but that's ok. If there's no DHCP
response after the standard DHCP time-out, most devices do one of 3
things: assign themselves 0.0.0.0 and give up trying to talk externally;
do IP auto addressing, see if there's anything to talk to, and then give
up trying to talk externally; or have a static assignment to try (my
laptop does this, since we have static in the office and DHCP in all
other places). With a static assignment, it makes sense to go to the
"No" path of "Is DHCP used for IP address config?". I suppose on the off
chance that auto addressing succeeded in finding something else
(extremely low probability), that it might also try that path. I
wouldn't give it much chance of succeeding.
Barbara

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 2:17 PM
To: Stark, Barbara
Cc: Romascanu, Dan (Dan); ECRIT; Cullen Jennings; Hannes Tschofenig
Subject: RE: [Ecrit] Some documents from DSL Forum

Hi again Barbara, 

18.09.07 13:26 

        To:        <[email-masked]>, "ECRIT"
<[email-masked]> 
        cc:        "Cullen Jennings" <[email-masked]>, "Hannes
Tschofenig" <[email-masked]>, "Romascanu, Dan (Dan)"
<[email-masked]> 
        Subject:        RE: [Ecrit] Some documents from DSL Forum

[PB] I agree there are potential issues if multiple applications in a
single Endpoint device all decided to start LLDP-MED.  (You are
referring to these applications as "clients" I believe??)  Potentially,
the first of those would get immediate response, but others would not
see -MED coming back until the next normal advertising cycle.  Hence, OS
support would be a good thing.  I do not see this as a big issue though,
since location would only be out of date for a max of the advertising
interval (30 sec default), and would be correct thereafter.  A bit more
serious would be the implication on the Network Connectivity Device
side, where it would potentially be receiving multiple sets of
advertisements.  Not only would there be more traffic (a non-issue in
practice, since it is constrained to the link), but if each app was
advertising different TLVs then the info from one could continually get
overridden with info from the other(s).  I would expect multiple apps
all wanting to use LLDP-MED in a single device to be rare though, at
least at this point.   

[PB] Yup, this makes sense now.  Yeah, the chart is pretty convoluted
and hard to fit anything else into, but still think it would be good to
include "No" paths from the "Was <method x> successful" decisions to the
appropriate handling (which is LIS determination I would think).   

Cheers, 

17.09.07 13:45 

Dan

*****

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 23 Sep 2007 23:58:14 -0500

Hi Barbara,

Apologies for the delay - I just got the time to take a look. I've been
through the responses so far and I haven't seen anything that makes my
following observations redundant.

My general comment is that this document implies but perhaps fails to
explicitly highlight the difference between the link layer and the
so-called L7 approach.

Figure 2 implies, as does the rest of the text I think, that it is the
residential gateway that obtains location information from the
access/ISP. The power of the L7 approach is that the VoIP client can do
this directly without any dependency on the rest of the CPE. The
introductory text says "The client-side behavior is expected to be
included in all SIP endpoints, *and* residential gateways (RG), *and*
other home routers." (emphasis mine). HELD only requires the SIP
endpoint to support the client-side capabilities. Assuming the network
also supports the recommended discovery mechanisms, it isn't even
necessary for the DHCP server to support the LIS address option. While
having all devices in the residential LAN support the client-side
protocols is a worthy goal, I think it would be good for the text to
highlight that this isn't necessary for direct SIP-Client to HELD LIS
interaction; currently I think it implies that things won't work unless
every device supports the client-side protocol.

With respect to the use of LLDP-MED and DHCP, there also seems to be an
implication that the location information delivered by these methods may
have been obtained from the access network by the RG. However, the only
protocol that I think could support this is HELD. Again, if the RG is
using HELD to get this information, then the SIP client should be able
to get it directly without dependency on the RG. Perhaps the meaning of
"client-side behavior" needs to be spelt out - particularly in terms of
what it means for the RG and other home routers. I agree that where the
access network does not support a LIS function, then the RG needs to
support manual configuration regardless of whether it's LLDP-MED, DHCP,
or HELD that the SIP client uses - however, that is "server-side"
behavior.

With respect to the location selection flow chart, has any consideration
been given to the "mobile LAN" scenario that has been raised a few
times? Perhaps this is written purely from the perspective that DSL
endpoints are not mobile, so this is not an issue? It would mean that
reliance on a piece of static location data in a link layer device may
be incorrect if the other side of the LAN gateway is actually connected
to a mobile network. DSL, by definition, isn't a mobile network but, on
the other hand, if the SIP clients are encoded with this algorithm they
may fail to take advantage of a mobile network LIS when they do move
from their DSL attachment to that scenario.

I raise the same concern with respect to "GPS" that Hannes mentioned.
That is, there are security issues to do with purely target-device
generated and provided location. This is what location signing is
intended to address. There is growing awareness of this issue (not just
limited to network location - see reference and text below) and it may
be a poor strategy on the part of the DSL forum to start from a baseline
that ignores this problem. For example, getting location from an access
provider LIS as the priority would ensure that signed location is
acquired when it is available. In the future, when location-assertion is
available, there will be the option of using the device-acquired
location and still having it signed by a recognized operator. The other
issue is that, presumably, the format of location provided by the DSL
network would be civic whereas GPS is going to be geodetic. While I'm
not sure that there has been any strict policy established with respect
to this, I'd expect that emergency responders would prefer the civic
form.

Finally, if the scope is actually restricted to residential mass market
CPE, is LLDP-MED actually a pertinent technology in any case or is it
really an enterprise technology? I've also heard 3825 characterized as
enterprise (switched network LAN) technology.

Cheers,

Martin

http://sidt.gpsworld.com/gpssidt/article/articleDetail.jsp?id=436920

The growing use of GPS in civil security and monitoring applications
brings with it a vulnerability to criminal enterprises suborning GPS for
financial gain. For example, asset tracking, identified as the
second-fastest growing GNSS market segment after mapping, uses
geofencing to raise the alarm when an asset is not where it is supposed
to be. Geofences can be time-dependent and dynamic, so cargo in transit
can be monitored as well. The successful theft of an intermodal shipping
container could provide ample incentive to develop a GPS signal spoofer
to cover criminal activity.

The 2001 Volpe Report, Vulnerability Assessment of the Transportation
Infrastructure Relying on GPS, states that "The DOT should coordinate
with the DoD to ensure that appropriate anti-spoofing technologies are
available to civilian applications, should the need arise. It is
important to identify observables that may indicate spoofing in civil
safety-critical receivers. In addition, DOT should develop independent
information to determine the validity and extent of possible civil
spoofing threats."

Other examples of illicit gain that may encourage spoofing include:

*	the highly regulated fisheries industry, where an onboard vessel
monitoring system (VMS) reports positions in real-time  to monitor
compliance with regulations. If a fishing vessel can cover its true
activity for 30 minutes, it might land an additional $60,000 worth of
fish, crabs, or shrimp. 
*	illegal dumping of trash and other hazardous materials,
estimated as a $10-$12 billion industry. 
*	theft of private data records. More than 150 million records
have been lost or stolen in the last 40 months, potentially enabling
identity theft, credit card fraud, voting fraud, and other exploits.
Geo-encryption techniques relying on GPS can restrict access to
plaintext data based on location, time, and key access. My own Geocodex
LLC is currently commercializing this technology with extensive
anti-spoofing design elements. 

As these examples show, there are strong motivations to compromise GPS
location integrity. We have clear financial and ethical reasons to
prevent this from happening by securing the location determination
process, in what I call location assurance.  In this essay, I describe
what is involved in developing an effective spoofer given current "open
door" civil signal architectures and show how civil vulnerabilities
differ greatly from military vulnerabilities. The Internet and
software-defined radio (SDR) architectures play a major role in
advancing the civil spoofing threat. Finally, I will look at prospects
for hardening GPS, Galileo, and Loran signals against spoofing attacks.
Navigation signals can be hardened and it is not all that difficult -
but it will take an act of national will to do so.

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, 19 September 2007 5:04 AM
To: [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Some documents from DSL Forum

Barbara

Hi again Barbara, 

18.09.07 13:26 

  

Cheers, 

17.09.07 13:45 

Dan

***** 

*****

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit