RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: Stark, Barbara ^lt;Barbara.Stark@BellSouth.com>
Date: Tue Feb 13 2007 - 15:01:15 EST

I agree, that it's absolutely possible, through existing TLS mechanisms.

While DSL lines don't (or shouldn't) move, the L2TP tunnel, or router port, where traffic for a given DSL customer comes into an ISP's network, does change. PPPoE authentication info isn't tied to a DSL line (I can use my login and password from anybody's bellsouth.net DSL line). So, the ISP can't assume, that just because they see traffic from a particular customer, that the customer's traffic is coming from his DSL line. The ISP needs to ask the access provider where that traffic physically originates from.

As a side note, I hope there's no expectation that we would calculate, derive, or measure geo locations for service addresses. My expectation is that we would only have a civic location. We certainly won't be going out and measuring, and I've heard it's a bad idea to create geo data based on a civic address. [Comment on "I think both the civic and geodetic location of the DSL line's service address is known".]
Barbara

-----Original Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Tuesday, February 13, 2007 2:45 PM
To: Stark, Barbara
Cc: g.caron@bell.ca; lendl@nic.at; hgs@cs.columbia.edu; geopriv@ietf.org
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

Do DSL lines move? In general, I don't think they do. I did have one do that a couple of years ago when I tried to get service via a CLEC, but the ILEC put it back where they found it... coincidentally
an hour after I filed a complaint with the state regulatory body.
But in general, I think both the civic and geodetic location of the DSL line's service address is known, or should be known, at the time of provisioning the service.

And LIS to LIS is the same thing as LS to LS, which is already covered by the current specs. I'm unclear what it is that is so special about OBO, but sending location objects from one location server to another is already possible the RFCs that are published today.

I don't have a problem with providing a mechanism to do what is being asked, so long as it doesn't seriously contort that protocol's main function. But from what I can tell, what is being asked is already possible.

-andy

On Feb 12, 2007, at 3:39 PM, Stark, Barbara wrote:

> We also have the wholesale DSL model that would require LIS to LIS
> communication.
>
> To start this process all over again to generate requirements for a
> protocol that can only be used for LIS to LIS communication, isn't
> workable. This process has taken far too long, as it is, and
> there's pressure to have a complete solution.
>
> Furthermore, people have expressed the belief in other venues
> (other than the IETF) that legislative and/or regulatory bodies in
> some countries may require true "On Behalf Of" querying by a VPC
> (VoIP Position Center), when an emergency call arrives without a
> location. It's believed that this could make for a smoother
> transition from non-location-capable to location-capable devices.
> That should be the job of that national entity to legislate this
> (or not), and not of the IETF to simply prevent it (by refusing to
> allow a protocol to support this function). Furthermore, it should
> be the job of these same national legislative/regulatory bodies to
> determine and police privacy laws/regulations, and not the IETF.
>
> In the past, geopriv has also discussed locating objects such as
> hospital carts and weather balloons, which may have an RFID tag (so
> they can be located) but no IP stack. In this case, a doctor's PDA
> device in a hospital could be querying the central hospital locator
> database (let's call it a LIS), to determine the cart's location.
>
> IMO, people need to get over the fact that they can't control how a
> protocol is used once it's released into the world. The desire to
> make this "L7" protocol so uni-purpose that it can't be used
> improperly, will generate a protocol that is almost useless,
> because it is so limited in its capabilities.
> Barbara
>
>
> -----Original Message-----
> From: g.caron@bell.ca [mailto:g.caron@bell.ca]
> Sent: Monday, February 12, 2007 10:45 AM
> To: lendl@nic.at; hgs@cs.columbia.edu
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement
>
> The model described by Otmar herein is also the one we are
> contemplating. As such, LIS to LIS interaction is definitively a
> requirement for us.
>
> I will add that the third party ISP and its wholesaler already have
> a business relationship and an interconnection agreement (for IP
> traffic handoff). As such, adding another protocol on top of may
> not raise more security or privacy concerns, including the explicit
> consent of the end user.
>
> I'm also of the view that reusing protocols that can effectively
> fulfill the requirements is generally a good thing.
>
> Thanks,
>
> Guy Caron
>
> -----Message d'origine-----
> De : Otmar Lendl [mailto:lendl@nic.at]
> Envoyé : 12 février 2007 10:19
> À : Henning Schulzrinne
> Cc : GEOPRIV
> Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement
>
> On 2007/02/12 15:02, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
>> It all comes down to identification. We have focused on L2/L3
>> identifiers so far. Asking "where is alice@example.com?" is much more
>> closely related to SIMPLE, for example. Needless to say, this
>> question
>> seems to be equivalent to some random person asking the question, in
>> that it is subject to privacy rules and possibly requires the consent
>> of the target.
>
> If "alice@example.com" from above is a meant to be a SIP address,
> then yes, we don't want to do that.
>
> There are a number of IDs with which a L3 provider could ask his L2
> provider for the location of a specific customer, e.g.
>
> * L2TP tunnel/channel ID
> * ATM VCI/VPI
> * Ethernet VLAN tag
> * MPLS tag
> * Radius username
>
> I don't see the need for consent from the target. After all, it's
> completely irrelevant for the broadband subscriber whether his ISP
> has subcontracted the L2 connectivity to someone else.
> All that matters to the user is that his provider's LIS can provide
> an accurate response.
>
> The L2 provider needs to ensure that the interface he provides to
> his customers (i.e. reseller) authenticates queries and only
> provides informations to L3 providers about their respective users.
>
>> I'm not sure if, in your example, you intend Earthlink to provide an
>> IP address or some NAS identifier or something else.
>
> Let's walk this though again (this time using an Austrian Real World
> example:
>
> * Telekom Austia (TA) as the local incumbent operates a DSL
> infrastructure in Austria. They run DSLAMs and BRAS.
>
> * Other ISPs, e.g. eTel resell the TA DSL solution.
>
> * TA hands off customers to eTel using L2TP tunnels.
>
> * The PPTP session which the customer sees is from his PC
> to a device from eTel (LNS) which does the PPP handshake
> and assigns the IP address (from eTel's pool).
>
> * All the TA infrastructure is transparent for the customer, he
> doesn't even know that the DSLAM isn't run by eTel.
>
> Thus:
>
> * A LIS will have to be run by eTel to serve their own customers.
>
> * eTel has (as of now) no chance to know from which of the TA
> lines a specific user is logging in. A user can use his
> username/password from *any* TA DSL line and will be forwarded
> to eTel equipment.
>
> * The eTel LIS thus needs to query into the TA network on where
> this specific L2TP session comes from in order to give a
> correct answer. eTel could either use
>
> - L2TP tunnel/session identifiers or
> - Radius Authentication names
>
> to identify a specific session when querying TA's LIS.
>
> They can't use IP addresses as TA does not see the end-user's
> address: they just transport the PPP stream.
>
>>
>> Obviously, there is also no necessity for the same protocol to be
>> used
>> for both the configuration application and the remote query.
>
> That's a legitimate question.
>
> We need that LIS-LIS protocol for 10 - 30 % of the European
> broadband users. ASAP. In the sense of "at the same time as the
> endhost-LIS protocol". I doubt we have the manpower here in this WG
> to tackle two different protocols for LIS queries at the same time.
>
>> For a variety of reasons, such as privacy, consent, identifiers and
>> security, one might even argue that this is not a good idea. We have
>> been able to avoid the privacy policy discussion so far since we
>> assumed that the querier was the target or that the target had, by
>> handing out a token, given permission to the location recipient. Your
>> example clearly violates that assumption.
>
> Sorry, but that assumption was misplaced.
>
> Sometimes the simple and easy solution just is not enough.
>
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> *****
>
> 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
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

*****

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 13 Feb 2007 15:01:15 -0500

This archive was generated by hypermail 2.1.8 : Tue Feb 13 2007 - 15:01:10 EST