From ecrit-bounces@ietf.org Wed Apr 13 16:59:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06987; Wed, 13 Apr 2005 16:59:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLp7U-0004Jl-DB; Wed, 13 Apr 2005 17:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLow6-0003pt-EQ; Wed, 13 Apr 2005 16:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLow5-0003e4-Rh for ecrit@megatron.ietf.org; Wed, 13 Apr 2005 16:58:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06795 for ; Wed, 13 Apr 2005 16:57:36 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLp5Q-0004GB-9D for ecrit@ietf.org; Wed, 13 Apr 2005 17:07:49 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j3DKvSYj026019 for ; Wed, 13 Apr 2005 22:57:28 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3DKvS3O011578 for ; Wed, 13 Apr 2005 22:57:28 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ5JXDX>; Wed, 13 Apr 2005 22:57:28 +0200 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Wed, 13 Apr 2005 22:55:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ecrit] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The GEOPRIV and ECRIT working groups will be holding a joint interim meeting. What: Interim GEOPRIV/ECRIT meeting When: 2005 May 16 08:30-17:30 2005 May 17 08:30-17:30 2005 May 18 08:30-17:30 Where: Columbia University Dept. of Computer Science 450 Computer Science Bldg. 1214 Amsterdam Avenue (close to 120th St.) New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html Also: WiFi provided. Teleconference to be provided. Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html Early bookings recommended. Proposed GEOPRIV Agenda: 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 14 09:59:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13718; Thu, 14 Apr 2005 09:59:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM52r-0000Ck-7S; Thu, 14 Apr 2005 10:10:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4q2-000508-KO; Thu, 14 Apr 2005 09:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4JV-0007gR-A4 for ecrit@megatron.ietf.org; Thu, 14 Apr 2005 09:23:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10449 for ; Thu, 14 Apr 2005 09:23:11 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4TM-00072U-Oa for ecrit@ietf.org; Thu, 14 Apr 2005 09:33:33 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j3EDN1dq014756 for ; Thu, 14 Apr 2005 08:23:02 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <26JFMFG9>; Thu, 14 Apr 2005 15:23:00 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577DB48@nl0006exch001u.nl.lucent.com> From: "Bemmel, Jeroen van (Jeroen)" To: "'ecrit@ietf.org'" Date: Thu, 14 Apr 2005 15:23:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Thu, 14 Apr 2005 09:56:57 -0400 Subject: [Ecrit] Emergency location alternative: outbound proxy adding location in formation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0212997346==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0212997346== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C540F5.143F5B0E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C540F5.143F5B0E Content-Type: text/plain; charset="iso-8859-1" Hello, I have been reading the sipping-emergency architecture draft ( http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-arch-02.txt ) authored by this charter and I have a question / suggestion to share. This may have been discussed before, if so I apologize for the repitition We are currently working on emergency services in the context of an enterprise WiFi environment. In such an environment, we figured it could help if a SIP proxy with some knowledge on the proximity of the user (e.g. within the same building, connected to the same LAN) would add information to outgoing emergency calls to assist with locating the user. The proxy could add a header, e.g.: Emergency-Location: lat=1.2345; long=6.789; postal=xxxx; certainty=500m It should probably also refer to the source of this information, e.g. the URI of the responsible administrator. This location information could be preconfigured in the proxy. A second issue is that the proxy could be provisioned with the address of the emergency center to contact for emergency calls. In that case the location information would not be needed for call routing I noted that the current draft does not mention these alternatives, it talks mainly about things that can be done at the terminal side. I would argue that in case of emergency all information that can assist in locating the user can be helpful. So it would be wise to do "as much as possible", i.e. both have the terminal report its location if possible and have the proxy append information too. >From a privacy perspective I understand there could be objections to this approach, i.e. the user's location is given out without the user's consent. I would say that in case the user is making an emergency call, he should know that it implies he will give out his location information. Furthermore, given the nature of emergency situations which by definition are "life and limb threatening" I would say that users generally would take the risk that their location information ends up in the wrong hands, rather than not share it and risk death. Regards, Jeroen van Bemmel, Lucent Technologies Bell Labs ------_=_NextPart_001_01C540F5.143F5B0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have been reading the=20 sipping-emergency architecture draft ( http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-eme= rgency-arch-02.txt )=20 authored by this charter and I have a question / suggestion to share. = This may=20 have been discussed before, if so I apologize for the=20 repitition
 
We are = currently=20 working on emergency services in the context of an enterprise WiFi = environment.=20 In such an environment, we figured it could help if a SIP proxy with = some=20 knowledge on the proximity of the user (e.g. within the same building, = connected=20 to the same LAN) would add information to outgoing emergency calls to = assist=20 with locating the user.
 
The proxy = could add a=20 header, e.g.: Emergency-Location:=20 lat=3D1.2345; long=3D6.789; postal=3Dxxxx;=20 certainty=3D500m
It should = probably also=20 refer to the source of this information, e.g. the URI of the = responsible=20 administrator. This = location=20 information could be preconfigured in the proxy.=20
 
A second issue is=20 that the proxy could be = provisioned=20 with the address of the emergency center to contact for emergency = calls. In that=20 case the location information would not be needed for call=20 routing
 
I noted=20 that the current draft does not mention these alternatives, it talks = mainly=20 about things that can be done at the terminal side.=20
 
I would=20 argue that in case of emergency all information that can assist in = locating the=20 user can be helpful. So it would be wise to do "as much as possible", = i.e. both=20 have the terminal report its location if possible and have the proxy = append=20 information too.
 
From a=20 privacy perspective I understand there could be objections to this = approach,=20 i.e. the user's location is given out without the user's consent. I = would say=20 that in case the user is making an emergency call, he should know that = it=20 implies he will give out his location information. Furthermore, given = the nature=20 of emergency situations which by definition are "life and limb = threatening" I=20 would say that users generally would take the risk that their location=20 information ends up in the wrong hands, rather than not share it = and risk=20 death.
 
Regards,
 
Jeroen van=20 Bemmel, Lucent Technologies Bell=20 Labs
------_=_NextPart_001_01C540F5.143F5B0E-- --===============0212997346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0212997346==-- From ecrit-bounces@ietf.org Thu Apr 14 11:47:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25907; Thu, 14 Apr 2005 11:47:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6ij-0005BI-RL; Thu, 14 Apr 2005 11:57:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Sx-0000Qb-Vd; Thu, 14 Apr 2005 11:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Sv-0000Q1-EB for ecrit@megatron.ietf.org; Thu, 14 Apr 2005 11:41:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25420 for ; Thu, 14 Apr 2005 11:41:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6cm-0004rZ-Ci for ecrit@ietf.org; Thu, 14 Apr 2005 11:51:26 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2005 08:40:38 -0700 X-IronPort-AV: i="3.92,102,1112598000"; d="scan'208"; a="249685006:sNHT1308945624" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3EFeSfk011785; Thu, 14 Apr 2005 08:40:29 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA13579; Thu, 14 Apr 2005 08:40:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20050414103237.03433bf0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Apr 2005 10:40:31 -0500 To: "Bemmel, Jeroen van (Jeroen)" , "'ecrit@ietf.org'" From: "James M. Polk" Subject: Re: [Ecrit] Emergency location alternative: outbound proxy adding location in formation In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550577DB48@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 At 03:23 PM 4/14/2005 +0200, Bemmel, Jeroen van (Jeroen) wrote: > >The proxy could add a header, e.g.: Emergency-Location: lat=1.2345; >long=6.789; postal=xxxx; certainty=500m >It should probably also refer to the source of this information, e.g. the >URI of the responsible administrator. This location information could be >preconfigured in the proxy. Adding "location" as a header has been in SIPPING for a few years as a discussion point of the ID http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-02.txt and has been dismissed by the WG and the Transport Area Director. I am moving that ID over to SIP very shortly (because it is actually modifying the protocol slightly), and you're welcome to start another thread about this there. It should appear there within a week. > >A second issue is that the proxy could be provisioned with the address of >the emergency center to contact for emergency calls. My proxy can always be in Dallas, though I might be traveling in Europe and call 911. This is one of the points that's made when folks say "you can never rely on the location of the proxy relative to where the UAC/user is". There really is no bind between the two. > >Regards, > >Jeroen van Bemmel, Lucent Technologies Bell Labs >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 15 14:06:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27545; Fri, 15 Apr 2005 14:06:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVN8-0003xU-Cq; Fri, 15 Apr 2005 14:16:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMV4j-0000X3-Js; Fri, 15 Apr 2005 13:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMV4i-0000Wp-Er for ecrit@megatron.ietf.org; Fri, 15 Apr 2005 13:57:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27022 for ; Fri, 15 Apr 2005 13:57:51 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVEw-0003Yn-MO for ecrit@ietf.org; Fri, 15 Apr 2005 14:08:27 -0400 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+syh8EZWjnQDHVvZ/ReHBW4T1X2HkLIak@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3FHvlqt019288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 13:57:47 -0400 (EDT) Received: from [127.0.0.1] (IDENT:U2FsdGVkX18pr5qL4BHyxTjvsPkN3YItflOXI1NUmEQ@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j3FHvkZK004320; Fri, 15 Apr 2005 13:57:46 -0400 Message-ID: <426000A3.9050408@cs.columbia.edu> Date: Fri, 15 Apr 2005 13:57:55 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Emergency location alternative: outbound proxy adding location in formation References: <4.3.2.7.2.20050414103237.03433bf0@localhost> In-Reply-To: <4.3.2.7.2.20050414103237.03433bf0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: "Bemmel, Jeroen van \(Jeroen\)" , "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit It may well be that, given intervening work on identity and other SIP components, that some of these issues are no longer relevant. > Adding "location" as a header has been in SIPPING for a few years as a > discussion point of the ID > http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-02.txt > > > and has been dismissed by the WG and the Transport Area Director. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 09:28:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFFK-0008Qx-8W; Wed, 20 Apr 2005 09:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFFI-0008Qk-JF; Wed, 20 Apr 2005 09:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07604; Wed, 20 Apr 2005 09:27:59 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFQV-0002a2-FS; Wed, 20 Apr 2005 09:39:37 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 29F9C2010D; Wed, 20 Apr 2005 09:27:49 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 12203-04; Wed, 20 Apr 2005 09:27:48 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 7424720055; Wed, 20 Apr 2005 09:27:48 -0400 (EDT) To: Andrew Newton MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Wed, 20 Apr 2005 09:29:56 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 04/20/2005 09:27:47 AM, Serialize complete at 04/20/2005 09:27:47 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: GEOPRIV WG , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0302794264==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0302794264== Content-Type: multipart/alternative; boundary="=_alternative 0049F46A85256FE9_=" This is a multipart message in MIME format. --=_alternative 0049F46A85256FE9_= Content-Type: text/plain; charset="us-ascii" Hi Andrew, lists, I'd like to better understand the meaning of the following agenda items: " 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. " Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions? Reason I'm asking is I am deeply involved in a layer 2 approach which would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to. The work is going on in TIA and is called Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems. In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). We see this method of delivery as a non-competing alternative to the DHCP-based approach, with the same end result to the overall ECS system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios. (The DHCP-based method has advantages in different scenarios.) I am Editor of this document, and it is now in ballot process in TIA (more or less equivalent to Last Call in IETF). Sorry, I expect I am suffering lack of context here, since I only joined the list relatively recently. BTW, what is the state of geopriv-dhcp-civil? Is it now past Last Call and in the RFC Editor's queue? It seemed to have been settled on the list, and waiting on AD action. -- Peter Blatherwick Andrew Newton Sent by: geopriv-bounces@ietf.org 13.04.05 16:34 To: GEOPRIV WG cc: Subject: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting The GEOPRIV and ECRIT working groups will be holding a joint interim meeting. What: Interim GEOPRIV/ECRIT meeting When: 2005 May 16 08:30-17:30 2005 May 17 08:30-17:30 2005 May 18 08:30-17:30 Where: Columbia University Dept. of Computer Science 450 Computer Science Bldg. 1214 Amsterdam Avenue (close to 120th St.) New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html Also: WiFi provided. Teleconference to be provided. Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html Early bookings recommended. Proposed GEOPRIV Agenda: 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --=_alternative 0049F46A85256FE9_= Content-Type: text/html; charset="us-ascii"
Hi Andrew, lists,  

I'd like to better understand the meaning of the following agenda items:
  "
  2) Properties of network elements in transferring LI from layer 2
 upward to PIDF-LO.
 3) Proposed enhancements to PIDF-LO to support #2.
 "

Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions?  

Reason I'm asking is I am deeply involved in a layer 2 approach which would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to.  The work is going on in TIA and is called Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems.  In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe).  We see this method of delivery as a non-competing alternative to the DHCP-based approach, with the same end result to the overall ECS system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios.  (The DHCP-based method has advantages in different scenarios.)   I am Editor of thi s document, and it is now in ballot process in TIA (more or less equivalent to Last Call in IETF).  

Sorry, I expect I am suffering lack of context here, since I only joined the list relatively recently.  

BTW, what is the state of geopriv-dhcp-civil?  Is it now past Last Call and in the RFC Editor's queue?  It seemed to have been settled on the list, and waiting on AD action.

-- Peter Blatherwick




Andrew Newton <andy@hxr.us>
Sent by: geopriv-bounces@ietf.org

13.04.05 16:34

       
        To:        GEOPRIV WG <geopriv@ietf.org>
        cc:        
        Subject:        [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting




The GEOPRIV and ECRIT working groups will be holding a joint interim
meeting.

      What: Interim GEOPRIV/ECRIT meeting
      When: 2005 May 16 08:30-17:30
            2005 May 17 08:30-17:30
            2005 May 18 08:30-17:30
     Where: Columbia University
            Dept. of Computer Science
            450 Computer Science Bldg.
            1214 Amsterdam Avenue (close to 120th St.)
            New York, NY 10027
Directions: http://www.cs.columbia.edu/directions.html
      Also: WiFi provided.
            Teleconference to be provided.
     Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
            Early bookings recommended.

Proposed GEOPRIV Agenda:
  2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30
1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in
HTTP/HTML for web browsing.
2) Properties of network elements in transferring LI from layer 2
upward to PIDF-LO.
3) Proposed enhancements to PIDF-LO to support #2.

Proposed ECRIT Agenda:
  2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30
1) Emergency Call Routing Requirements
2) Security and Threats Analysis

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

--=_alternative 0049F46A85256FE9_=-- --===============0302794264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0302794264==-- From ecrit-bounces@ietf.org Wed Apr 20 09:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFdN-00035R-1E; Wed, 20 Apr 2005 09:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFdL-00034u-Ip; Wed, 20 Apr 2005 09:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09476; Wed, 20 Apr 2005 09:52:50 -0400 (EDT) Received: from [64.151.105.12] (helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFoY-0003GN-Q7; Wed, 20 Apr 2005 10:04:28 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 20 Apr 2005 09:52:45 -0400 id 000FF84E.42665EAD.00002E0D In-Reply-To: References: Mime-Version: 1.0 Message-Id: <00b444334545222d572fc588237e6742@hxr.us> From: Andrew Newton Date: Wed, 20 Apr 2005 09:52:37 -0400 To: peter_blatherwick@mitel.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: GEOPRIV WG , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0523782193==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0523782193== Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-11789-1114005166-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-11789-1114005166-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 20, 2005, at 9:29 AM, peter_blatherwick@mitel.com wrote: > Hi Andrew, lists, > > I'd like to better understand the meaning of the following agenda > items: > " > 2) Properties of network elements in transferring LI from layer 2 > upward to PIDF-LO. > 3) Proposed enhancements to PIDF-LO to support #2. > " > > Is there a summary of what these really mean, or examples of what the > outcome could be in terms of protocol or layer interactions? > > Reason I'm asking is I am deeply involved in a layer 2 approach which > would be able to deliver location information to endpoints from the L2 > LAN > infrastructure they are connected to. The work is going on in TIA and > is > called Link Layer Discovery Protocol - Media Endpoint Discovery > (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP > systems. In LLDP-MED, among several other things, we have specified > ways > to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and > civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call > process > I believe). We see this method of delivery as a non-competing > alternative > to the DHCP-based approach, with the same end result to the overall ECS > system (the endpoint receives the exact same data), which has some > advantages particularly in enterprise deployment scenarios. (The > DHCP-based method has advantages in different scenarios.) I am > Editor of > this document, and it is now in ballot process in TIA (more or less > equivalent to Last Call in IETF). This is a very good question. At the last GEOPRIV meeting at IETF 62, concerns were raised about how devices get location information and send up the protocol stack. Since the IETF does not standardize all components of the stack, it would be either foolish or arrogant of us to define "an architecture" of how this is done. Instead, we want to simply identify the different types of components in the network and the properties they should/must have in order to reliably accomplish the task of gathering location information from the network, placing it in a PIDF-LO document, and sending that information on its way through the appropriate application. Our hope is to provide a clearer picture to network operators and implementors regarding the types of gear needed even if there are multiple types of gear to accomplish the same task. Input regarding LLDP-MED is very much welcome and would be very useful. > Sorry, I expect I am suffering lack of context here, since I only > joined > the list relatively recently. Not a problem. I hope I explained this in an understandable fashion. > BTW, what is the state of geopriv-dhcp-civil? Is it now past Last Call > and in the RFC Editor's queue? It seemed to have been settled on the > list, and waiting on AD action. It was sent up to our AD right as he went on extended leave. He's back now and clearing his queue, so this draft will be moving along shortly (as our AD is one of the best in the business). -andy --=_zak.ecotroph.net-11789-1114005166-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNDIwMTM1MjM4WjAjBgkqhkiG9w0BCQQxFgQU9/CDxWZzTZHGgLbj1fuh 9DYzwDsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEALGrBssBWb8XAwKSsCZNP sJ4IZiQD8sSWMTrtaDDVNcZrqE2eKee93eKSQLrCqlG5L6xOHxhb3PrjyW4ecZ4pGlO5iJje+zGg aIapJ1oJBfBYi0tnAR4y9SJtrV9tcU7dvAIqSDnH1xaqjFNVTqFnNSzjScy5k4qfnzQ9sDAO9tWp nLaya4OPwUf7UtOC6rE4iS7vYw6QYT/wXYwHEDke7+2QTKF4PKGTJHtP1yXI5e4YWIWsMoFcBFRa s+kNmpo9rgnZDZnFHG185WCF+mJBylllpyceeJy3lXHbHu338mANDQrZ5gjtHJoJCOh/cgN0SH0O w2PaW3H4VGLyMM2xxwAAAAAAAA== --=_zak.ecotroph.net-11789-1114005166-0001-2-- --===============0523782193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0523782193==-- From ecrit-bounces@ietf.org Wed Apr 20 09:54:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFeh-0003FF-Pz; Wed, 20 Apr 2005 09:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFeg-0003F5-CT; Wed, 20 Apr 2005 09:54:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09649; Wed, 20 Apr 2005 09:54:12 -0400 (EDT) Message-Id: <200504201354.JAA09649@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFpu-0003JQ-Di; Wed, 20 Apr 2005 10:05:50 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOFeR-0004Ki-DO; Wed, 20 Apr 2005 08:53:59 -0500 From: "Brian Rosen" To: Date: Wed, 20 Apr 2005 09:53:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There turns out to be a large set of issues around this problem, which I fear is leading to Balkanization. There are two really important = problems we need to solve. One fundamental problem is that every client needs to implement every possible LI transfer mechanism that its environment could provide. We have DHCP. You guys are working on LLDP-MED. The DSL guys reject = both of these and want a something else. Every phone has to implement every protocol. There are some who have observed that the mechanisms at hand are L2 specific. They claim as long as you have an L2 specific mechanism, you = need one or more for each L2. To get out of that, they propose that we use = an L7 mechanism (think some version of HTTP, although that might not fly). = They would say, lets do that once, and every L2 can use it. The problem is = that you then have to deal with the security issues of an L7 mechanism, and = in particular, you have to use IP address as the =93key=94 for what = location to return. If you can spoof IP address, you can get someone else=92s = location. =20 Those advocating L7 mechanisms claim that the mechanism would only be implemented within a domain, and the domain would have to take = anti-spoofing steps. They note that the mechanism would need at least a complete = round trip, and probably more than one, so spoofing requires the ability to intercept packets not addressed to the attacker. The returned data = could be precisely a PIDF-LO. Then on top of that, we turn out to need some more security, especially = for emergency calls. We need to prevent forged locations. That means we = need to sign the PIDF-LO. If you get location via DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that, how do we construct a signature from the entity that actually determined location? Brian ________________________________________ From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf Of peter_blatherwick@mitel.com Sent: Wednesday, April 20, 2005 9:30 AM To: Andrew Newton Cc: GEOPRIV WG; ecrit@ietf.org Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim = Meeting Hi Andrew, lists, =A0=20 I'd like to better understand the meaning of the following agenda items: = =A0 "=20 =A0 2) Properties of network elements in transferring LI from layer 2=20 =A0upward to PIDF-LO. =A03) Proposed enhancements to PIDF-LO to support #2. =A0"=20 Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions? =A0=20 Reason I'm asking is I am deeply involved in a layer 2 approach which = would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to. =A0The work is going on in TIA and = is called Link Layer Discovery Protocol - Media Endpoint Discovery = (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems. =A0In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). =A0We see this method of delivery as a non-competing = alternative to the DHCP-based approach, with the same end result to the overall ECS = system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios. =A0(The DHCP-based = method has advantages in different scenarios.) =A0 I am Editor of thi s document, = and it is now in ballot process in TIA (more or less equivalent to Last Call in IETF). =A0=20 Sorry, I expect I am suffering lack of context here, since I only joined = the list relatively recently. =A0=20 BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last = Call and in the RFC Editor's queue? =A0It seemed to have been settled on the = list, and waiting on AD action.=20 -- Peter Blatherwick=20 Andrew Newton =20 Sent by: geopriv-bounces@ietf.org=20 13.04.05 16:34=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Joint = GEOPRIV/ECRIT Interim Meeting The GEOPRIV and ECRIT working groups will be holding a joint interim=20 meeting. =A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting =A0 =A0 =A0 When: 2005 May 16 08:30-17:30 =A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 =A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 =A0 =A0 =A0Where: Columbia University =A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science =A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. =A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) =A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html =A0 =A0 =A0 Also: WiFi provided. =A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. =A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html =A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. Proposed GEOPRIV Agenda: =A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in=20 HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2=20 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: =A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 10:15:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFzN-0006SA-K2; Wed, 20 Apr 2005 10:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFzM-0006S2-G3; Wed, 20 Apr 2005 10:15:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12447; Wed, 20 Apr 2005 10:15:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGAa-000435-73; Wed, 20 Apr 2005 10:27:13 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2005 10:26:27 -0400 X-IronPort-AV: i="3.92,116,1112587200"; d="scan'208"; a="45369303:sNHT31727328" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3KEEbS4008871; Wed, 20 Apr 2005 10:15:21 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:13:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 10:13:52 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3113AFC@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 20 Apr 2005 14:13:53.0751 (UTC) FILETIME=[2EDB3E70:01C545B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, Could you clarify the domain statement. Given nomadicity, it would seem = that location delivery would need to be cross-domain. The E911 PSAP = will not always be the same domain as the roaming endpoint. My impression is that Location discovery is a L2 issue, tied to the fact = that L2 is supposed to be a single physical hop at most between the = end-user terminal and an adjacent location-determining network node. = (Of course those trying to make L2 protocols a replacement for IP sort = of screw this assumption up.) The location delivery mechanism is an application-layer or L7 service. = The argument there is that since multiple applications will need to rely = on location information, a general purpose delivery mechanism will = provide consistency and generality that is so often sought in IETF work. = Security can be built-in to the chosen delivery mechanism. Note, that = delivery could be a choice of an existing transfer mechanism. This does = not preclude other L7 protocols from defining a place in their messages = that could also carry location information. So, I believe: Location discovery is local, with associated security being local, Location delivery is global, with associated security being global. The real issues are making those happen. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Brian Rosen >Sent: Wednesday, April 20, 2005 9:54 AM >To: peter_blatherwick@mitel.com >Cc: 'GEOPRIV WG'; ecrit@ietf.org >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT InterimMeeting > >There turns out to be a large set of issues around this=20 >problem, which I fear is leading to Balkanization. There are=20 >two really important problems we need to solve. > >One fundamental problem is that every client needs to=20 >implement every possible LI transfer mechanism that its=20 >environment could provide. > >We have DHCP. You guys are working on LLDP-MED. The DSL=20 >guys reject both >of these and want a something else. Every phone has to=20 >implement every protocol. > >There are some who have observed that the mechanisms at hand=20 >are L2 specific. They claim as long as you have an L2=20 >specific mechanism, you need one or more for each L2. To get=20 >out of that, they propose that we use an L7 mechanism (think=20 >some version of HTTP, although that might not fly). They=20 >would say, lets do that once, and every L2 can use it. The=20 >problem is that you then have to deal with the security issues=20 >of an L7 mechanism, and in particular, you have to use IP=20 >address as the "key" for what location to return. If you can=20 >spoof IP address, you can get someone else's location. =20 > >Those advocating L7 mechanisms claim that the mechanism would=20 >only be implemented within a domain, and the domain would have=20 >to take anti-spoofing steps. They note that the mechanism=20 >would need at least a complete round trip, and probably more=20 >than one, so spoofing requires the ability to >intercept packets not addressed to the attacker. The=20 >returned data could >be precisely a PIDF-LO. > >Then on top of that, we turn out to need some more security,=20 >especially for emergency calls. We need to prevent forged=20 >locations. That means we need to sign the PIDF-LO. If you=20 >get location via DHCP, or LLDP-MED, and the endpoint=20 >constructs a PIDF-LO from that, how do we construct a=20 >signature from the entity that actually determined location? > >Brian > > >________________________________________ >From: geopriv-bounces@ietf.org=20 >[mailto:geopriv-bounces@ietf.org] On Behalf Of=20 >peter_blatherwick@mitel.com >Sent: Wednesday, April 20, 2005 9:30 AM >To: Andrew Newton >Cc: GEOPRIV WG; ecrit@ietf.org >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 >Interim Meeting > > >Hi Andrew, lists, =A0=20 > >I'd like to better understand the meaning of the following=20 >agenda items:=20 >=A0 "=20 >=A0 2) Properties of network elements in transferring LI from layer 2 >=A0upward to PIDF-LO. >=A03) Proposed enhancements to PIDF-LO to support #2. >=A0"=20 > >Is there a summary of what these really mean, or examples of=20 >what the outcome could be in terms of protocol or layer=20 >interactions? =A0=20 > >Reason I'm asking is I am deeply involved in a layer 2=20 >approach which would be able to deliver location information=20 >to endpoints from the L2 LAN infrastructure they are connected=20 >to. =A0The work is going on in TIA and is called Link Layer=20 >Discovery Protocol - Media Endpoint Discovery (LLDP-MED),=20 >which is an extension of IEEE 802.1AB, specific to VoIP=20 >systems. =A0In LLDP-MED, among several other things, we have=20 >specified ways to pass equivalent data to the DHCP=20 >coordinate-based LCI (RFC 3825) and civic location LCI=20 >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I=20 >believe). =A0We see this method of delivery as a non-competing=20 >alternative to the DHCP-based approach, with the same end=20 >result to the overall ECS system (the endpoint receives the=20 >exact same data), which has some advantages particularly in=20 >enterprise deployment scenarios. =A0(The DHCP-based method has=20 >advantages in different scenarios.) =A0 I am Editor of thi s=20 >document, and it is now in ballot process in TIA (more or less=20 >equivalent to Last Call in IETF). =A0=20 > >Sorry, I expect I am suffering lack of context here, since I=20 >only joined the list relatively recently. =A0=20 > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past=20 >Last Call and in the RFC Editor's queue? =A0It seemed to have=20 >been settled on the list, and waiting on AD action.=20 > >-- Peter Blatherwick=20 > > > > >Andrew Newton >Sent by: geopriv-bounces@ietf.org >13.04.05 16:34=20 >=A0 =A0 =A0 =A0=20 >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG >=A0 =A0 =A0 =A0 cc: >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Joint = >GEOPRIV/ECRIT Interim Meeting > > > > >The GEOPRIV and ECRIT working groups will be holding a joint=20 >interim meeting. > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 >=A0 =A0 =A0Where: Columbia University >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 >Directions: http://www.cs.columbia.edu/directions.html >=A0 =A0 =A0 Also: WiFi provided. >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > >Proposed GEOPRIV Agenda: >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use=20 >of LI in HTTP/HTML for web browsing. >2) Properties of network elements in transferring LI from=20 >layer 2 upward to PIDF-LO. >3) Proposed enhancements to PIDF-LO to support #2. > >Proposed ECRIT Agenda: >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 >1) Emergency Call Routing Requirements >2) Security and Threats Analysis > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 10:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGUU-0001fH-SJ; Wed, 20 Apr 2005 10:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGUT-0001f9-TS; Wed, 20 Apr 2005 10:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15953; Wed, 20 Apr 2005 10:47:44 -0400 (EDT) Message-Id: <200504201447.KAA15953@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGfi-0005A3-LS; Wed, 20 Apr 2005 10:59:23 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOGUH-0006pb-L0; Wed, 20 Apr 2005 09:47:34 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 10:47:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3113AFC@xmb-rtp-20b.amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The idea is that, say, you are in your home, served by a DSL provider. The domain is then that of the DSL vendor. Your phone asks for its = location from the server in the DSL domain. It would be given the location corresponding to the IP address of the request. Note that this would be pretty good for the requested case, even in the presence of a NATed = local area network in your home. The phone would do this on boot, before any = VPN tunnels were established. I get the idea that a single delivery mechanism is desirable. I'm = skeptical we can do that because of the security issues. When you make the = delivery mechanism L2 dependent, you can control the possible attacks to a finer grain than the L7 local domain. Please keep in mind that some of the folks wishing to use the L7 = mechanism don't really want to just return location to the endpoint; they want to retain the location and give it out to authorized entities upon = presentation of the IP address of the endpoint. That is a business decision. They = can charge for such a service. I think the privacy implications of that are dicey, but the reality is that's the model that will probably be = implemented if we do this. =20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 10:14 AM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting >=20 > Brian, >=20 > Could you clarify the domain statement. Given nomadicity, it would = seem > that location delivery would need to be cross-domain. The E911 PSAP = will > not always be the same domain as the roaming endpoint. >=20 > My impression is that Location discovery is a L2 issue, tied to the = fact > that L2 is supposed to be a single physical hop at most between the = end- > user terminal and an adjacent location-determining network node. (Of > course those trying to make L2 protocols a replacement for IP sort of > screw this assumption up.) >=20 > The location delivery mechanism is an application-layer or L7 service. > The argument there is that since multiple applications will need to = rely > on location information, a general purpose delivery mechanism will = provide > consistency and generality that is so often sought in IETF work. = Security > can be built-in to the chosen delivery mechanism. Note, that delivery > could be a choice of an existing transfer mechanism. This does not > preclude other L7 protocols from defining a place in their messages = that > could also carry location information. >=20 > So, I believe: > Location discovery is local, with associated security being local, > Location delivery is global, with associated security being global. >=20 > The real issues are making those happen. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Brian Rosen > >Sent: Wednesday, April 20, 2005 9:54 AM > >To: peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >There turns out to be a large set of issues around this > >problem, which I fear is leading to Balkanization. There are > >two really important problems we need to solve. > > > >One fundamental problem is that every client needs to > >implement every possible LI transfer mechanism that its > >environment could provide. > > > >We have DHCP. You guys are working on LLDP-MED. The DSL > >guys reject both > >of these and want a something else. Every phone has to > >implement every protocol. > > > >There are some who have observed that the mechanisms at hand > >are L2 specific. They claim as long as you have an L2 > >specific mechanism, you need one or more for each L2. To get > >out of that, they propose that we use an L7 mechanism (think > >some version of HTTP, although that might not fly). They > >would say, lets do that once, and every L2 can use it. The > >problem is that you then have to deal with the security issues > >of an L7 mechanism, and in particular, you have to use IP > >address as the "key" for what location to return. If you can > >spoof IP address, you can get someone else's location. > > > >Those advocating L7 mechanisms claim that the mechanism would > >only be implemented within a domain, and the domain would have > >to take anti-spoofing steps. They note that the mechanism > >would need at least a complete round trip, and probably more > >than one, so spoofing requires the ability to > >intercept packets not addressed to the attacker. The > >returned data could > >be precisely a PIDF-LO. > > > >Then on top of that, we turn out to need some more security, > >especially for emergency calls. We need to prevent forged > >locations. That means we need to sign the PIDF-LO. If you > >get location via DHCP, or LLDP-MED, and the endpoint > >constructs a PIDF-LO from that, how do we construct a > >signature from the entity that actually determined location? > > > >Brian > > > > > >________________________________________ > >From: geopriv-bounces@ietf.org > >[mailto:geopriv-bounces@ietf.org] On Behalf Of > >peter_blatherwick@mitel.com > >Sent: Wednesday, April 20, 2005 9:30 AM > >To: Andrew Newton > >Cc: GEOPRIV WG; ecrit@ietf.org > >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >Interim Meeting > > > > > >Hi Andrew, lists, > > > >I'd like to better understand the meaning of the following > >agenda items: > >=A0 " > >=A0 2) Properties of network elements in transferring LI from layer 2 > >=A0upward to PIDF-LO. > >=A03) Proposed enhancements to PIDF-LO to support #2. > >=A0" > > > >Is there a summary of what these really mean, or examples of > >what the outcome could be in terms of protocol or layer > >interactions? > > > >Reason I'm asking is I am deeply involved in a layer 2 > >approach which would be able to deliver location information > >to endpoints from the L2 LAN infrastructure they are connected > >to. =A0The work is going on in TIA and is called Link Layer > >Discovery Protocol - Media Endpoint Discovery (LLDP-MED), > >which is an extension of IEEE 802.1AB, specific to VoIP > >systems. =A0In LLDP-MED, among several other things, we have > >specified ways to pass equivalent data to the DHCP > >coordinate-based LCI (RFC 3825) and civic location LCI > >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). =A0We see this method of delivery as a non-competing > >alternative to the DHCP-based approach, with the same end > >result to the overall ECS system (the endpoint receives the > >exact same data), which has some advantages particularly in > >enterprise deployment scenarios. =A0(The DHCP-based method has > >advantages in different scenarios.) =A0 I am Editor of thi s > >document, and it is now in ballot process in TIA (more or less > >equivalent to Last Call in IETF). > > > >Sorry, I expect I am suffering lack of context here, since I > >only joined the list relatively recently. > > > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past > >Last Call and in the RFC Editor's queue? =A0It seemed to have > >been settled on the list, and waiting on AD action. > > > >-- Peter Blatherwick > > > > > > > > > >Andrew Newton > >Sent by: geopriv-bounces@ietf.org > >13.04.05 16:34 > > > >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >=A0 =A0 =A0 =A0 cc: > >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint > >GEOPRIV/ECRIT Interim Meeting > > > > > > > > > >The GEOPRIV and ECRIT working groups will be holding a joint > >interim meeting. > > > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >=A0 =A0 =A0Where: Columbia University > >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >Directions: http://www.cs.columbia.edu/directions.html > >=A0 =A0 =A0 Also: WiFi provided. > >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > > >Proposed GEOPRIV Agenda: > >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use > >of LI in HTTP/HTML for web browsing. > >2) Properties of network elements in transferring LI from > >layer 2 upward to PIDF-LO. > >3) Proposed enhancements to PIDF-LO to support #2. > > > >Proposed ECRIT Agenda: > >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >1) Emergency Call Routing Requirements > >2) Security and Threats Analysis > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 11:43:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHMA-0001VQ-5r; Wed, 20 Apr 2005 11:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHM9-0001VH-54; Wed, 20 Apr 2005 11:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21038; Wed, 20 Apr 2005 11:43:11 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOHXM-0006wI-I3; Wed, 20 Apr 2005 11:54:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2005 08:43:01 -0700 X-IronPort-AV: i="3.92,117,1112598000"; d="scan'208"; a="252257256:sNHT28828036" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3KFgwhu009260; Wed, 20 Apr 2005 08:42:59 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA04827; Wed, 20 Apr 2005 08:42:56 -0700 (PDT) Message-Id: <200504201542.IAA04827@malone.cisco.com> From: "Marc Linsner" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRITInterimMeeting Date: Wed, 20 Apr 2005 11:42:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200504201447.KAA15953@ietf.org> Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACHFwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org snip......... > > The idea is that, say, you are in your home, served by a DSL provider. > The domain is then that of the DSL vendor. Your phone asks for its > location > from the server in the DSL domain. It would be given the location > corresponding to the IP address of the request. Note that this would be > pretty good for the requested case, even in the presence of a NATed local > area network in your home. The phone would do this on boot, before any > VPN > tunnels were established. In the VPN case, the phone most likely is not the device that terminates the tunnel; this is typically done via a separate box. If the phone were booted after the tunnel was established, the phone would not have the capability of contacting the domain with location knowledge. -Marc- snip............ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 11:58:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHax-0003MU-Lj; Wed, 20 Apr 2005 11:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHav-0003MK-K3; Wed, 20 Apr 2005 11:58:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22118; Wed, 20 Apr 2005 11:58:27 -0400 (EDT) Message-Id: <200504201558.LAA22118@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOHmB-0007NI-6R; Wed, 20 Apr 2005 12:10:07 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOHal-0002hg-LK; Wed, 20 Apr 2005 10:58:19 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRITInterimMeeting Date: Wed, 20 Apr 2005 11:58:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200504201542.IAA04827@malone.cisco.com> Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACHFwgAABTrYA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yeah, it's one of the larger limitations of the idea. The devices that need location don't have any knowledge of shenanigans happening underneath them, and they don't have any way to find out. The typical case works, because in the really, really, really common cases of teleworkers, hotspot users, and the like, VPN tunnels are established by software on computers, and not by boxes. Having said that, there are lots of IPsec boxes out there, and routers that have those features, and, .... The folks pushing these ideas, when faced with this kind of problem, tend to say "if there is a box screwing up the location mechanism, it's up to it to fix the problem it creates". They think it's perfectly reasonable for all tunnel creation things to be aware of location infrastructure, and do the right thing, whatever that means. I must admit I don't believe we can do that. I may not have stated my own opinions on this issue clearly. I don't think we can make an L7 mechanism work. I like the idea in the theoretic sense, but don't see how to make it work. I observe that real devices really get IP address from DHCP, and that mechanism can really be made to work in our favor. The typical case is a DSL modem with a home router. The PCs get IP addresses from DHCP in the router. It can use whatever L2 mechanism it wants to get location from the upstream provider, and then provide location to downstream PCs, phones and the like via DHCP. The uncommon case of a single device directly connected to the DSL modem can be made to work because custom software is always provided for that case, and can be provided with any L2 specific mechanism needed to get location. Push back on that idea is that there are a heck of a lot of home routers out there, and updating their firmware is really hard. I recognize the value of LLDP-MED, but I don't like having every phone, every softclient/PC, etc having to implement LLDP-MED. We may be stuck with it, but it's not good. Better to use DHCP to learn location, and have something between the switches and the DHCP server to determine location. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, April 20, 2005 11:43 AM > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com > Cc: 'GEOPRIV WG'; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > GEOPRIV/ECRITInterimMeeting > > snip......... > > > > > The idea is that, say, you are in your home, served by a DSL provider. > > The domain is then that of the DSL vendor. Your phone asks for its > > location > > from the server in the DSL domain. It would be given the location > > corresponding to the IP address of the request. Note that this would be > > pretty good for the requested case, even in the presence of a NATed > local > > area network in your home. The phone would do this on boot, before any > > VPN > > tunnels were established. > > In the VPN case, the phone most likely is not the device that terminates > the > tunnel; this is typically done via a separate box. If the phone were > booted > after the tunnel was established, the phone would not have the capability > of > contacting the domain with location knowledge. > > -Marc- > > snip............ > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 12:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHdA-0003bc-9f; Wed, 20 Apr 2005 12:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHd8-0003bM-ES; Wed, 20 Apr 2005 12:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22258; Wed, 20 Apr 2005 12:00:44 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOHoL-0007QF-DI; Wed, 20 Apr 2005 12:12:24 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2005 12:00:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3KG0SRU012190; Wed, 20 Apr 2005 12:00:31 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 12:00:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 12:00:23 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3113B2A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACuDTw From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 20 Apr 2005 16:00:24.0745 (UTC) FILETIME=[102F8990:01C545C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I still get the feeling that "delivery" is being used in two different = contexts: (1) (2) Local node---?---->endpoint-----/many hops/----->PSAP=20 ---------------------/many hops/-----> (2) How can "delivery" be L2 dependent, when it must reach a PSAP many hops = away? Color me confused. Mike >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, April 20, 2005 10:47 AM >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com >Cc: 'GEOPRIV WG'; ecrit@ietf.org >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT InterimMeeting > >The idea is that, say, you are in your home, served by a DSL provider. >The domain is then that of the DSL vendor. Your phone asks=20 >for its location from the server in the DSL domain. It would=20 >be given the location corresponding to the IP address of the=20 >request. Note that this would be pretty good for the=20 >requested case, even in the presence of a NATed local area=20 >network in your home. The phone would do this on boot, before=20 >any VPN tunnels were established. > >I get the idea that a single delivery mechanism is desirable. =20 >I'm skeptical we can do that because of the security issues. =20 >When you make the delivery mechanism L2 dependent, you can=20 >control the possible attacks to a finer grain than the L7 local domain. > >Please keep in mind that some of the folks wishing to use the=20 >L7 mechanism don't really want to just return location to the=20 >endpoint; they want to retain the location and give it out to=20 >authorized entities upon presentation of the IP address of the=20 >endpoint. That is a business decision. They can charge for=20 >such a service. I think the privacy implications of that are=20 >dicey, but the reality is that's the model that will probably=20 >be implemented if we do this. =20 > >Brian > > > > > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Wednesday, April 20, 2005 10:14 AM >> To: Brian Rosen; peter_blatherwick@mitel.com >> Cc: GEOPRIV WG; ecrit@ietf.org >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT=20 >> InterimMeeting >>=20 >> Brian, >>=20 >> Could you clarify the domain statement. Given nomadicity, it would=20 >> seem that location delivery would need to be cross-domain. The E911=20 >> PSAP will not always be the same domain as the roaming endpoint. >>=20 >> My impression is that Location discovery is a L2 issue, tied to the=20 >> fact that L2 is supposed to be a single physical hop at most between=20 >> the end- user terminal and an adjacent location-determining network=20 >> node. (Of course those trying to make L2 protocols a=20 >replacement for=20 >> IP sort of screw this assumption up.) >>=20 >> The location delivery mechanism is an application-layer or=20 >L7 service. >> The argument there is that since multiple applications will need to=20 >> rely on location information, a general purpose delivery mechanism=20 >> will provide consistency and generality that is so often sought in=20 >> IETF work. Security can be built-in to the chosen delivery=20 >mechanism. =20 >> Note, that delivery could be a choice of an existing transfer=20 >> mechanism. This does not preclude other L7 protocols from=20 >defining a=20 >> place in their messages that could also carry location information. >>=20 >> So, I believe: >> Location discovery is local, with associated security being local,=20 >> Location delivery is global, with associated security being global. >>=20 >> The real issues are making those happen. >>=20 >> Mike >>=20 >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> >Behalf Of Brian Rosen >> >Sent: Wednesday, April 20, 2005 9:54 AM >> >To: peter_blatherwick@mitel.com >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 >> >InterimMeeting >> > >> >There turns out to be a large set of issues around this problem,=20 >> >which I fear is leading to Balkanization. There are two really=20 >> >important problems we need to solve. >> > >> >One fundamental problem is that every client needs to=20 >implement every=20 >> >possible LI transfer mechanism that its environment could provide. >> > >> >We have DHCP. You guys are working on LLDP-MED. The DSL >> >guys reject both >> >of these and want a something else. Every phone has to implement=20 >> >every protocol. >> > >> >There are some who have observed that the mechanisms at hand are L2=20 >> >specific. They claim as long as you have an L2 specific mechanism,=20 >> >you need one or more for each L2. To get out of that, they propose=20 >> >that we use an L7 mechanism (think some version of HTTP, although=20 >> >that might not fly). They would say, lets do that once,=20 >and every L2=20 >> >can use it. The problem is that you then have to deal with the=20 >> >security issues of an L7 mechanism, and in particular, you have to=20 >> >use IP address as the "key" for what location to return. =20 >If you can=20 >> >spoof IP address, you can get someone else's location. >> > >> >Those advocating L7 mechanisms claim that the mechanism=20 >would only be=20 >> >implemented within a domain, and the domain would have to take=20 >> >anti-spoofing steps. They note that the mechanism would need at=20 >> >least a complete round trip, and probably more than one, so=20 >spoofing=20 >> >requires the ability to >> >intercept packets not addressed to the attacker. The >> >returned data could >> >be precisely a PIDF-LO. >> > >> >Then on top of that, we turn out to need some more security,=20 >> >especially for emergency calls. We need to prevent forged=20 >locations. =20 >> >That means we need to sign the PIDF-LO. If you get location via=20 >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that,=20 >> >how do we construct a signature from the entity that actually=20 >> >determined location? >> > >> >Brian >> > >> > >> >________________________________________ >> >From: geopriv-bounces@ietf.org >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of=20 >> >peter_blatherwick@mitel.com >> >Sent: Wednesday, April 20, 2005 9:30 AM >> >To: Andrew Newton >> >Cc: GEOPRIV WG; ecrit@ietf.org >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim=20 >> >Meeting >> > >> > >> >Hi Andrew, lists, >> > >> >I'd like to better understand the meaning of the following agenda=20 >> >items: >> >=A0 " >> >=A0 2) Properties of network elements in transferring LI from layer = 2 >> >=A0upward to PIDF-LO. >> >=A03) Proposed enhancements to PIDF-LO to support #2. >> >=A0" >> > >> >Is there a summary of what these really mean, or examples=20 >of what the=20 >> >outcome could be in terms of protocol or layer interactions? >> > >> >Reason I'm asking is I am deeply involved in a layer 2=20 >approach which=20 >> >would be able to deliver location information to endpoints from the=20 >> >L2 LAN infrastructure they are connected to. =A0The work is=20 >going on in=20 >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20 >> >Discovery (LLDP-MED), which is an extension of IEEE=20 >802.1AB, specific=20 >> >to VoIP systems. =A0In LLDP-MED, among several other things, we have = >> >specified ways to pass equivalent data to the DHCP coordinate-based=20 >> >LCI (RFC 3825) and civic location LCI=20 >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I=20 >believe). =A0 >> >We see this method of delivery as a non-competing=20 >alternative to the=20 >> >DHCP-based approach, with the same end result to the overall ECS=20 >> >system (the endpoint receives the exact same data), which has some=20 >> >advantages particularly in enterprise deployment scenarios. =A0(The=20 >> >DHCP-based method has advantages in different scenarios.) =A0 I am=20 >> >Editor of thi s document, and it is now in ballot process in TIA=20 >> >(more or less equivalent to Last Call in IETF). >> > >> >Sorry, I expect I am suffering lack of context here, since I only=20 >> >joined the list relatively recently. >> > >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last = >> >Call and in the RFC Editor's queue? =A0It seemed to have been = settled=20 >> >on the list, and waiting on AD action. >> > >> >-- Peter Blatherwick >> > >> > >> > >> > >> >Andrew Newton >> >Sent by: geopriv-bounces@ietf.org >> >13.04.05 16:34 >> > >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG >> >=A0 =A0 =A0 =A0 cc: >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint=20 >GEOPRIV/ECRIT=20 >> >Interim Meeting >> > >> > >> > >> > >> >The GEOPRIV and ECRIT working groups will be holding a=20 >joint interim=20 >> >meeting. >> > >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 >> >=A0 =A0 =A0Where: Columbia University >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 >> >Directions: http://www.cs.columbia.edu/directions.html >> >=A0 =A0 =A0 Also: WiFi provided. >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. >> > >> >Proposed GEOPRIV Agenda: >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the=20 >use of LI=20 >> >in HTTP/HTML for web browsing. >> >2) Properties of network elements in transferring LI from layer 2=20 >> >upward to PIDF-LO. >> >3) Proposed enhancements to PIDF-LO to support #2. >> > >> >Proposed ECRIT Agenda: >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 >> >1) Emergency Call Routing Requirements >> >2) Security and Threats Analysis >> > >> >_______________________________________________ >> >Geopriv mailing list >> >Geopriv@ietf.org >> >https://www1.ietf.org/mailman/listinfo/geopriv >> > >> > >> > >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 12:15:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHot-0004xf-BS; Wed, 20 Apr 2005 12:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHop-0004xC-P9; Wed, 20 Apr 2005 12:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23519; Wed, 20 Apr 2005 12:12:49 -0400 (EDT) Message-Id: <200504201612.MAA23519@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOI05-0007si-6I; Wed, 20 Apr 2005 12:24:29 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOHof-0003QN-Bo; Wed, 20 Apr 2005 11:12:41 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 12:12:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3113B2A@xmb-rtp-20b.amer.cisco.com> Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACuDTwAABc4NA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The basic picture is: LIS ---> endpoint ---> routing element ---> psap The LIS knows where the endpoint is. The endpoint gets location from the LIS The endpoint includes location on the emergency call The routing element uses location to route the call to the right PSAP The PSAP gets the call, and the location. The discussion is, how does the endpoint get location from the LIS? DHCP is one answer. LLDP-MED is another. A proposed L7 mechanism is another. To be sure, there are folks who want to make the picture: LIS --> endpoint --> routing element ---> psap ^ | | | | | +------------------------+ | | | +------------------------------------------+ The LIS gives the endpoint a "key" The endpoint includes the key in the emergency call The routing element gets the key and exchanges it for location at the = LIS The psap gets the key and exchanges it for location at the LIS The key could be an IP address. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 12:00 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting >=20 > I still get the feeling that "delivery" is being used in two different > contexts: >=20 > (1) (2) > Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) >=20 > How can "delivery" be L2 dependent, when it must reach a PSAP many = hops > away? > Color me confused. >=20 > Mike >=20 >=20 > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL = provider. > >The domain is then that of the DSL vendor. Your phone asks > >for its location from the server in the DSL domain. It would > >be given the location corresponding to the IP address of the > >request. Note that this would be pretty good for the > >requested case, even in the presence of a NATed local area > >network in your home. The phone would do this on boot, before > >any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. > >I'm skeptical we can do that because of the security issues. > >When you make the delivery mechanism L2 dependent, you can > >control the possible attacks to a finer grain than the L7 local = domain. > > > >Please keep in mind that some of the folks wishing to use the > >L7 mechanism don't really want to just return location to the > >endpoint; they want to retain the location and give it out to > >authorized entities upon presentation of the IP address of the > >endpoint. That is a business decision. They can charge for > >such a service. I think the privacy implications of that are > >dicey, but the reality is that's the model that will probably > >be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would > >> seem that location delivery would need to be cross-domain. The = E911 > >> PSAP will not always be the same domain as the roaming endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the > >> fact that L2 is supposed to be a single physical hop at most = between > >> the end- user terminal and an adjacent location-determining network > >> node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to > >> rely on location information, a general purpose delivery mechanism > >> will provide consistency and generality that is so often sought in > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local, > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem, > >> >which I fear is leading to Balkanization. There are two really > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are = L2 > >> >specific. They claim as long as you have an L2 specific = mechanism, > >> >you need one or more for each L2. To get out of that, they = propose > >> >that we use an L7 mechanism (think some version of HTTP, although > >> >that might not fly). They would say, lets do that once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the > >> >security issues of an L7 mechanism, and in particular, you have to > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take > >> >anti-spoofing steps. They note that the mechanism would need at > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security, > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from = that, > >> >how do we construct a signature from the entity that actually > >> >determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org > >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of > >> >peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> >=A0 " > >> >=A0 2) Properties of network elements in transferring LI from = layer 2 > >> >=A0upward to PIDF-LO. > >> >=A03) Proposed enhancements to PIDF-LO to support #2. > >> >=A0" > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from = the > >> >L2 LAN infrastructure they are connected to. =A0The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. =A0In LLDP-MED, among several other things, we = have > >> >specified ways to pass equivalent data to the DHCP = coordinate-based > >> >LCI (RFC 3825) and civic location LCI > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS > >> >system (the endpoint receives the exact same data), which has some > >> >advantages particularly in enterprise deployment scenarios. = =A0(The > >> >DHCP-based method has advantages in different scenarios.) =A0 I am > >> >Editor of thi s document, and it is now in ballot process in TIA > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past = Last > >> >Call and in the RFC Editor's queue? =A0It seemed to have been = settled > >> >on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >> >=A0 =A0 =A0 =A0 cc: > >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >> >=A0 =A0 =A0Where: Columbia University > >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> >=A0 =A0 =A0 Also: WiFi provided. > >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 13:02:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIau-0004lp-B3; Wed, 20 Apr 2005 13:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIas-0004lV-IQ; Wed, 20 Apr 2005 13:02:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27642; Wed, 20 Apr 2005 13:02:28 -0400 (EDT) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOIm8-00017M-Do; Wed, 20 Apr 2005 13:14:08 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j3KH2DO07901; Wed, 20 Apr 2005 13:02:13 -0400 (EDT) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005042013021004280 ; Wed, 20 Apr 2005 13:02:10 -0400 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 13:02:10 -0400 Message-ID: From: "Abbott, Nadine B." To: "'Brian Rosen'" , "'Michael Hammer (mhammer)'" , peter_blatherwick@mitel.com Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Wed, 20 Apr 2005 13:02:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dnsmx2pya.telcordia.com id j3KH2DO07901 X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The "folks pushing this mechanism" are not using DHCP servers in their networks to download configuration information. This constitutes a significant portion of the access network providers in North America. Tha= t is why they see a need to investigate an additional mechanism, e.g., ACS. And the beyond-transition methods being discussed support download of location to the endpoint, just not necessarily via DHCP. On a different point, determination of location will be paid for by someo= ne (or it won't happen). It's a matter of who and how. Out of scope for IET= F surely?=20 Nadine -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behal= f Of Brian Rosen Sent: Wednesday, April 20, 2005 10:47 AM To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting The idea is that, say, you are in your home, served by a DSL provider. Th= e domain is then that of the DSL vendor. Your phone asks for its location from the server in the DSL domain. It would be given the location corresponding to the IP address of the request. Note that this would be pretty good for the requested case, even in the presence of a NATed local area network in your home. The phone would do this on boot, before any V= PN tunnels were established. I get the idea that a single delivery mechanism is desirable. I'm skepti= cal we can do that because of the security issues. When you make the deliver= y mechanism L2 dependent, you can control the possible attacks to a finer grain than the L7 local domain. Please keep in mind that some of the folks wishing to use the L7 mechanis= m don't really want to just return location to the endpoint; they want to retain the location and give it out to authorized entities upon presentat= ion of the IP address of the endpoint. That is a business decision. They ca= n charge for such a service. I think the privacy implications of that are dicey, but the reality is that's the model that will probably be implemen= ted if we do this. =20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 10:14 AM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > InterimMeeting >=20 > Brian, >=20 > Could you clarify the domain statement. Given nomadicity, it would=20 > seem that location delivery would need to be cross-domain. The E911=20 > PSAP will not always be the same domain as the roaming endpoint. >=20 > My impression is that Location discovery is a L2 issue, tied to the=20 > fact that L2 is supposed to be a single physical hop at most between=20 > the end- user terminal and an adjacent location-determining network=20 > node. (Of course those trying to make L2 protocols a replacement for=20 > IP sort of screw this assumption up.) >=20 > The location delivery mechanism is an application-layer or L7 service.=20 > The argument there is that since multiple applications will need to=20 > rely on location information, a general purpose delivery mechanism=20 > will provide consistency and generality that is so often sought in=20 > IETF work. Security can be built-in to the chosen delivery mechanism. = =20 > Note, that delivery could be a choice of an existing transfer=20 > mechanism. This does not preclude other L7 protocols from defining a=20 > place in their messages that could also carry location information. >=20 > So, I believe: > Location discovery is local, with associated security being local,=20 > Location delivery is global, with associated security being global. >=20 > The real issues are making those happen. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >Behalf Of Brian Rosen > >Sent: Wednesday, April 20, 2005 9:54 AM > >To: peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > >InterimMeeting > > > >There turns out to be a large set of issues around this problem,=20 > >which I fear is leading to Balkanization. There are two really=20 > >important problems we need to solve. > > > >One fundamental problem is that every client needs to implement every=20 > >possible LI transfer mechanism that its environment could provide. > > > >We have DHCP. You guys are working on LLDP-MED. The DSL > >guys reject both > >of these and want a something else. Every phone has to implement=20 > >every protocol. > > > >There are some who have observed that the mechanisms at hand are L2=20 > >specific. They claim as long as you have an L2 specific mechanism,=20 > >you need one or more for each L2. To get out of that, they propose=20 > >that we use an L7 mechanism (think some version of HTTP, although=20 > >that might not fly). They would say, lets do that once, and every L2=20 > >can use it. The problem is that you then have to deal with the=20 > >security issues of an L7 mechanism, and in particular, you have to=20 > >use IP address as the "key" for what location to return. If you can > >spoof IP address, you can get someone else's location. > > > >Those advocating L7 mechanisms claim that the mechanism would only be=20 > >implemented within a domain, and the domain would have to take=20 > >anti-spoofing steps. They note that the mechanism would need at=20 > >least a complete round trip, and probably more than one, so spoofing=20 > >requires the ability to > >intercept packets not addressed to the attacker. The > >returned data could > >be precisely a PIDF-LO. > > > >Then on top of that, we turn out to need some more security,=20 > >especially for emergency calls. We need to prevent forged locations. = =20 > >That means we need to sign the PIDF-LO. If you get location via=20 > >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that,=20 > >how do we construct a signature from the entity that actually=20 > >determined location? > > > >Brian > > > > > >________________________________________ > >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On=20 > >Behalf Of peter_blatherwick@mitel.com > >Sent: Wednesday, April 20, 2005 9:30 AM > >To: Andrew Newton > >Cc: GEOPRIV WG; ecrit@ietf.org > >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >Interim Meeting > > > > > >Hi Andrew, lists, > > > >I'd like to better understand the meaning of the following agenda=20 > >items: > >=A0 " > >=A0 2) Properties of network elements in transferring LI from layer 2 > >=A0upward to PIDF-LO. > >=A03) Proposed enhancements to PIDF-LO to support #2. > >=A0" > > > >Is there a summary of what these really mean, or examples of what the=20 > >outcome could be in terms of protocol or layer interactions? > > > >Reason I'm asking is I am deeply involved in a layer 2 approach which=20 > >would be able to deliver location information to endpoints from the=20 > >L2 LAN infrastructure they are connected to. =A0The work is going on i= n=20 > >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20 > >Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, specific=20 > >to VoIP systems. =A0In LLDP-MED, among several other things, we have > >specified ways to pass equivalent data to the DHCP > >coordinate-based LCI (RFC 3825) and civic location LCI > >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). =A0We see this method of delivery as a non-competing > >alternative to the DHCP-based approach, with the same end > >result to the overall ECS system (the endpoint receives the > >exact same data), which has some advantages particularly in > >enterprise deployment scenarios. =A0(The DHCP-based method has > >advantages in different scenarios.) =A0 I am Editor of thi s > >document, and it is now in ballot process in TIA (more or less > >equivalent to Last Call in IETF). > > > >Sorry, I expect I am suffering lack of context here, since I only=20 > >joined the list relatively recently. > > > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last=20 > >Call and in the RFC Editor's queue? =A0It seemed to have been settled=20 > >on the list, and waiting on AD action. > > > >-- Peter Blatherwick > > > > > > > > > >Andrew Newton > >Sent by: geopriv-bounces@ietf.org > >13.04.05 16:34 > > > >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >=A0 =A0 =A0 =A0 cc: > >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Join= t GEOPRIV/ECRIT=20 > >Interim Meeting > > > > > > > > > >The GEOPRIV and ECRIT working groups will be holding a joint interim=20 > >meeting. > > > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >=A0 =A0 =A0Where: Columbia University > >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >Directions: http://www.cs.columbia.edu/directions.html > >=A0 =A0 =A0 Also: WiFi provided. > >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > > >Proposed GEOPRIV Agenda: > >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI=20 > >in HTTP/HTML for web browsing. > >2) Properties of network elements in transferring LI from layer 2=20 > >upward to PIDF-LO. > >3) Proposed enhancements to PIDF-LO to support #2. > > > >Proposed ECRIT Agenda: > >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >1) Emergency Call Routing Requirements > >2) Security and Threats Analysis > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 13:04:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIcy-0004yF-4w; Wed, 20 Apr 2005 13:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIcw-0004xy-9G; Wed, 20 Apr 2005 13:04:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27764; Wed, 20 Apr 2005 13:04:35 -0400 (EDT) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOIoC-0001AA-6l; Wed, 20 Apr 2005 13:16:16 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j3KH4AO08295; Wed, 20 Apr 2005 13:04:10 -0400 (EDT) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005042013040704386 ; Wed, 20 Apr 2005 13:04:07 -0400 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 13:04:05 -0400 Message-ID: From: "Abbott, Nadine B." To: "'Michael Hammer (mhammer)'" , Brian Rosen , peter_blatherwick@mitel.com Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Wed, 20 Apr 2005 13:03:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dnsmx2pya.telcordia.com id j3KH4AO08295 X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Mike, You are right--it is being used in two different contexts. Delivery of location to the endpoint and delivery of location to the PSAP. We need different terms or we need to qualify the term when we use it (as above). Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Michael Hammer (mhammer) Sent: Wednesday, April 20, 2005 12:00 PM To: Brian Rosen; peter_blatherwick@mitel.com Cc: GEOPRIV WG; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I still get the feeling that "delivery" is being used in two different contexts: (1) (2) Local node---?---->endpoint-----/many hops/----->PSAP=20 ---------------------/many hops/-----> (2) How can "delivery" be L2 dependent, when it must reach a PSAP many hops away? Color me confused. Mike >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, April 20, 2005 10:47 AM >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com >Cc: 'GEOPRIV WG'; ecrit@ietf.org >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT InterimMeeting > >The idea is that, say, you are in your home, served by a DSL provider.=20 >The domain is then that of the DSL vendor. Your phone asks for its=20 >location from the server in the DSL domain. It would be given the=20 >location corresponding to the IP address of the request. Note that=20 >this would be pretty good for the requested case, even in the presence=20 >of a NATed local area network in your home. The phone would do this on=20 >boot, before any VPN tunnels were established. > >I get the idea that a single delivery mechanism is desirable. >I'm skeptical we can do that because of the security issues. =20 >When you make the delivery mechanism L2 dependent, you can=20 >control the possible attacks to a finer grain than the L7 local domain. > >Please keep in mind that some of the folks wishing to use the >L7 mechanism don't really want to just return location to the=20 >endpoint; they want to retain the location and give it out to=20 >authorized entities upon presentation of the IP address of the=20 >endpoint. That is a business decision. They can charge for=20 >such a service. I think the privacy implications of that are=20 >dicey, but the reality is that's the model that will probably=20 >be implemented if we do this. =20 > >Brian > > > > > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Wednesday, April 20, 2005 10:14 AM >> To: Brian Rosen; peter_blatherwick@mitel.com >> Cc: GEOPRIV WG; ecrit@ietf.org >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint >GEOPRIV/ECRIT >> InterimMeeting >>=20 >> Brian, >>=20 >> Could you clarify the domain statement. Given nomadicity, it would >> seem that location delivery would need to be cross-domain. The E911=20 >> PSAP will not always be the same domain as the roaming endpoint. >>=20 >> My impression is that Location discovery is a L2 issue, tied to the >> fact that L2 is supposed to be a single physical hop at most between=20 >> the end- user terminal and an adjacent location-determining network=20 >> node. (Of course those trying to make L2 protocols a=20 >replacement for >> IP sort of screw this assumption up.) >>=20 >> The location delivery mechanism is an application-layer or >L7 service. >> The argument there is that since multiple applications will need to >> rely on location information, a general purpose delivery mechanism=20 >> will provide consistency and generality that is so often sought in=20 >> IETF work. Security can be built-in to the chosen delivery=20 >mechanism. >> Note, that delivery could be a choice of an existing transfer >> mechanism. This does not preclude other L7 protocols from=20 >defining a >> place in their messages that could also carry location information. >>=20 >> So, I believe: >> Location discovery is local, with associated security being local, >> Location delivery is global, with associated security being global. >>=20 >> The real issues are making those happen. >>=20 >> Mike >>=20 >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >Behalf Of Brian Rosen >> >Sent: Wednesday, April 20, 2005 9:54 AM >> >To: peter_blatherwick@mitel.com >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 >> >InterimMeeting >> > >> >There turns out to be a large set of issues around this problem, >> >which I fear is leading to Balkanization. There are two really=20 >> >important problems we need to solve. >> > >> >One fundamental problem is that every client needs to >implement every >> >possible LI transfer mechanism that its environment could provide. >> > >> >We have DHCP. You guys are working on LLDP-MED. The DSL >> >guys reject both >> >of these and want a something else. Every phone has to implement >> >every protocol. >> > >> >There are some who have observed that the mechanisms at hand are L2 >> >specific. They claim as long as you have an L2 specific mechanism,=20 >> >you need one or more for each L2. To get out of that, they propose=20 >> >that we use an L7 mechanism (think some version of HTTP, although=20 >> >that might not fly). They would say, lets do that once,=20 >and every L2 >> >can use it. The problem is that you then have to deal with the >> >security issues of an L7 mechanism, and in particular, you have to=20 >> >use IP address as the "key" for what location to return. =20 >If you can >> >spoof IP address, you can get someone else's location. >> > >> >Those advocating L7 mechanisms claim that the mechanism >would only be >> >implemented within a domain, and the domain would have to take >> >anti-spoofing steps. They note that the mechanism would need at=20 >> >least a complete round trip, and probably more than one, so=20 >spoofing >> >requires the ability to >> >intercept packets not addressed to the attacker. The >> >returned data could >> >be precisely a PIDF-LO. >> > >> >Then on top of that, we turn out to need some more security, >> >especially for emergency calls. We need to prevent forged=20 >locations. >> >That means we need to sign the PIDF-LO. If you get location via >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that,=20 >> >how do we construct a signature from the entity that actually=20 >> >determined location? >> > >> >Brian >> > >> > >> >________________________________________ >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On=20 >> >Behalf Of peter_blatherwick@mitel.com >> >Sent: Wednesday, April 20, 2005 9:30 AM >> >To: Andrew Newton >> >Cc: GEOPRIV WG; ecrit@ietf.org >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim=20 >> >Meeting >> > >> > >> >Hi Andrew, lists, >> > >> >I'd like to better understand the meaning of the following agenda >> >items: >> >=A0 " >> >=A0 2) Properties of network elements in transferring LI from layer 2 >> >=A0upward to PIDF-LO. >> >=A03) Proposed enhancements to PIDF-LO to support #2. >> >=A0" >> > >> >Is there a summary of what these really mean, or examples >of what the >> >outcome could be in terms of protocol or layer interactions? >> > >> >Reason I'm asking is I am deeply involved in a layer 2 >approach which >> >would be able to deliver location information to endpoints from the >> >L2 LAN infrastructure they are connected to. =A0The work is=20 >going on in >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint >> >Discovery (LLDP-MED), which is an extension of IEEE=20 >802.1AB, specific >> >to VoIP systems. =A0In LLDP-MED, among several other things, we have >> >specified ways to pass equivalent data to the DHCP coordinate-based=20 >> >LCI (RFC 3825) and civic location LCI=20 >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I=20 >believe). >> >We see this method of delivery as a non-competing >alternative to the >> >DHCP-based approach, with the same end result to the overall ECS >> >system (the endpoint receives the exact same data), which has some=20 >> >advantages particularly in enterprise deployment scenarios. =A0(The=20 >> >DHCP-based method has advantages in different scenarios.) =A0 I am=20 >> >Editor of thi s document, and it is now in ballot process in TIA=20 >> >(more or less equivalent to Last Call in IETF). >> > >> >Sorry, I expect I am suffering lack of context here, since I only >> >joined the list relatively recently. >> > >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last >> >Call and in the RFC Editor's queue? =A0It seemed to have been settled= =20 >> >on the list, and waiting on AD action. >> > >> >-- Peter Blatherwick >> > >> > >> > >> > >> >Andrew Newton >> >Sent by: geopriv-bounces@ietf.org >> >13.04.05 16:34 >> > >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG >> >=A0 =A0 =A0 =A0 cc: >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Joi= nt >GEOPRIV/ECRIT >> >Interim Meeting >> > >> > >> > >> > >> >The GEOPRIV and ECRIT working groups will be holding a >joint interim >> >meeting. >> > >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 >> >=A0 =A0 =A0Where: Columbia University >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 >> >Directions: http://www.cs.columbia.edu/directions.html >> >=A0 =A0 =A0 Also: WiFi provided. >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. >> > >> >Proposed GEOPRIV Agenda: >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the >use of LI >> >in HTTP/HTML for web browsing. >> >2) Properties of network elements in transferring LI from layer 2 >> >upward to PIDF-LO. >> >3) Proposed enhancements to PIDF-LO to support #2. >> > >> >Proposed ECRIT Agenda: >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 >> >1) Emergency Call Routing Requirements >> >2) Security and Threats Analysis >> > >> >_______________________________________________ >> >Geopriv mailing list >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv >> > >> > >> > >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 13:19:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIr8-0007hW-9j; Wed, 20 Apr 2005 13:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOIr6-0007hK-Sd; Wed, 20 Apr 2005 13:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29206; Wed, 20 Apr 2005 13:19:14 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJ2J-0001n4-46; Wed, 20 Apr 2005 13:30:55 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 6055520096; Wed, 20 Apr 2005 13:18:59 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 18973-01; Wed, 20 Apr 2005 13:18:59 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id E7B3720055; Wed, 20 Apr 2005 13:18:58 -0400 (EDT) To: "Brian Rosen" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Wed, 20 Apr 2005 13:21:15 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 04/20/2005 01:18:57 PM, Serialize complete at 04/20/2005 01:18:57 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630967659==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0630967659== Content-Type: multipart/alternative; boundary="=_alternative 005F21C685256FE9_=" This is a multipart message in MIME format. --=_alternative 005F21C685256FE9_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Seems a simple-minded question has sparked a flurry of debate ;-) Some=20 thoughts, just to stir the pot some more... not that it appears to need=20 it... I do not at all see the purely L2 LLDP-MED approach and the call it L2.5=20 DHCP approach as being in conflict. They are merely different ways suited = to different scenarios.=20 I do not see implementing both LLDP-based and DHCP-based methods in a=20 phone as being a big deal, since in the end they both are simple, would=20 deliver the exact same data to the application above, and they start in a=20 strict order (LLDP always before DHCP). The harder issue is really what=20 would the poor phone do if it received by both mechanisms, and the=20 received data were different -- it would need to pick one, or sort out the = conflict itself (yech!).=20 Since LLDP (hence LLDP-MED) is strictly contained to a physical link, its=20 security is very contained.=20 IEEE 802.1X is applied to that same link before LLDP gets to run (or=20 before DHCP for that matter), so at least the endpoint can be well=20 authenticated before hand. Also, it intuitively makes sense at least in=20 my fuzzy brain, that the X509 certs which could be part of the 802.1X=20 authentication exchange (if EAP-TLS is used) could also be useful in the=20 upward authentication process. (If I have messed up the acronyms, please=20 do not jump down my throat .. hopefully close enough.) It would indeed be unfortunate to add a third approach ... or a forth .... = I am not familiar with whatever the DSL approach would be, but do not=20 off-hand see why a DHCP relay approach would not work there. Anything=20 written up to look at on it?=20 Peter "Brian Rosen" 20.04.05 10:47 =20 To: "'Michael Hammer (mhammer)'" ,=20 cc: "'GEOPRIV WG'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEO= PRIV/ECRIT=20 InterimMeeting The idea is that, say, you are in your home, served by a DSL provider. The domain is then that of the DSL vendor. Your phone asks for its=20 location from the server in the DSL domain. It would be given the location corresponding to the IP address of the request. Note that this would be pretty good for the requested case, even in the presence of a NATed local area network in your home. The phone would do this on boot, before any=20 VPN tunnels were established. I get the idea that a single delivery mechanism is desirable. I'm=20 skeptical we can do that because of the security issues. When you make the delivery mechanism L2 dependent, you can control the possible attacks to a finer grain than the L7 local domain. Please keep in mind that some of the folks wishing to use the L7 mechanism don't really want to just return location to the endpoint; they want to retain the location and give it out to authorized entities upon=20 presentation of the IP address of the endpoint. That is a business decision. They can charge for such a service. I think the privacy implications of that are dicey, but the reality is that's the model that will probably be=20 implemented if we do this.=20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 10:14 AM > To: Brian Rosen; peter=5Fblatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting >=20 > Brian, >=20 > Could you clarify the domain statement. Given nomadicity, it would seem > that location delivery would need to be cross-domain. The E911 PSAP=20 will > not always be the same domain as the roaming endpoint. >=20 > My impression is that Location discovery is a L2 issue, tied to the fact > that L2 is supposed to be a single physical hop at most between the end- > user terminal and an adjacent location-determining network node. (Of > course those trying to make L2 protocols a replacement for IP sort of > screw this assumption up.) >=20 > The location delivery mechanism is an application-layer or L7 service. > The argument there is that since multiple applications will need to rely > on location information, a general purpose delivery mechanism will=20 provide > consistency and generality that is so often sought in IETF work.=20 Security > can be built-in to the chosen delivery mechanism. Note, that delivery > could be a choice of an existing transfer mechanism. This does not > preclude other L7 protocols from defining a place in their messages that > could also carry location information. >=20 > So, I believe: > Location discovery is local, with associated security being local, > Location delivery is global, with associated security being global. >=20 > The real issues are making those happen. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Brian Rosen > >Sent: Wednesday, April 20, 2005 9:54 AM > >To: peter=5Fblatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >There turns out to be a large set of issues around this > >problem, which I fear is leading to Balkanization. There are > >two really important problems we need to solve. > > > >One fundamental problem is that every client needs to > >implement every possible LI transfer mechanism that its > >environment could provide. > > > >We have DHCP. You guys are working on LLDP-MED. The DSL > >guys reject both > >of these and want a something else. Every phone has to > >implement every protocol. > > > >There are some who have observed that the mechanisms at hand > >are L2 specific. They claim as long as you have an L2 > >specific mechanism, you need one or more for each L2. To get > >out of that, they propose that we use an L7 mechanism (think > >some version of HTTP, although that might not fly). They > >would say, lets do that once, and every L2 can use it. The > >problem is that you then have to deal with the security issues > >of an L7 mechanism, and in particular, you have to use IP > >address as the "key" for what location to return. If you can > >spoof IP address, you can get someone else's location. > > > >Those advocating L7 mechanisms claim that the mechanism would > >only be implemented within a domain, and the domain would have > >to take anti-spoofing steps. They note that the mechanism > >would need at least a complete round trip, and probably more > >than one, so spoofing requires the ability to > >intercept packets not addressed to the attacker. The > >returned data could > >be precisely a PIDF-LO. > > > >Then on top of that, we turn out to need some more security, > >especially for emergency calls. We need to prevent forged > >locations. That means we need to sign the PIDF-LO. If you > >get location via DHCP, or LLDP-MED, and the endpoint > >constructs a PIDF-LO from that, how do we construct a > >signature from the entity that actually determined location? > > > >Brian > > > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >From: geopriv-bounces@ietf.org > >[mailto:geopriv-bounces@ietf.org] On Behalf Of > >peter=5Fblatherwick@mitel.com > >Sent: Wednesday, April 20, 2005 9:30 AM > >To: Andrew Newton > >Cc: GEOPRIV WG; ecrit@ietf.org > >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >Interim Meeting > > > > > >Hi Andrew, lists, > > > >I'd like to better understand the meaning of the following > >agenda items: > >=A0 " > >=A0 2) Properties of network elements in transferring LI from layer 2 > >=A0upward to PIDF-LO. > >=A03) Proposed enhancements to PIDF-LO to support #2. > >=A0" > > > >Is there a summary of what these really mean, or examples of > >what the outcome could be in terms of protocol or layer > >interactions? > > > >Reason I'm asking is I am deeply involved in a layer 2 > >approach which would be able to deliver location information > >to endpoints from the L2 LAN infrastructure they are connected > >to. =A0The work is going on in TIA and is called Link Layer > >Discovery Protocol - Media Endpoint Discovery (LLDP-MED), > >which is an extension of IEEE 802.1AB, specific to VoIP > >systems. =A0In LLDP-MED, among several other things, we have > >specified ways to pass equivalent data to the DHCP > >coordinate-based LCI (RFC 3825) and civic location LCI > >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). =A0We see this method of delivery as a non-competing > >alternative to the DHCP-based approach, with the same end > >result to the overall ECS system (the endpoint receives the > >exact same data), which has some advantages particularly in > >enterprise deployment scenarios. =A0(The DHCP-based method has > >advantages in different scenarios.) =A0 I am Editor of thi s > >document, and it is now in ballot process in TIA (more or less > >equivalent to Last Call in IETF). > > > >Sorry, I expect I am suffering lack of context here, since I > >only joined the list relatively recently. > > > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past > >Last Call and in the RFC Editor's queue? =A0It seemed to have > >been settled on the list, and waiting on AD action. > > > >-- Peter Blatherwick > > > > > > > > > >Andrew Newton > >Sent by: geopriv-bounces@ietf.org > >13.04.05 16:34 > > > >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >=A0 =A0 =A0 =A0 cc: > >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Joint > >GEOPRIV/ECRIT Interim Meeting > > > > > > > > > >The GEOPRIV and ECRIT working groups will be holding a joint > >interim meeting. > > > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >=A0 =A0 =A0Where: Columbia University > >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >Directions: http://www.cs.columbia.edu/directions.html > >=A0 =A0 =A0 Also: WiFi provided. > >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > > >Proposed GEOPRIV Agenda: > >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use > >of LI in HTTP/HTML for web browsing. > >2) Properties of network elements in transferring LI from > >layer 2 upward to PIDF-LO. > >3) Proposed enhancements to PIDF-LO to support #2. > > > >Proposed ECRIT Agenda: > >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >1) Emergency Call Routing Requirements > >2) Security and Threats Analysis > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 --=_alternative 005F21C685256FE9_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Seems a simple-minded question has s= parked a flurry of debate ;-)    Some thoughts, just to stir the = pot some more... not that it appears to need it...

I do not at all see the purely L2 LL= DP-MED approach and the call it L2.5 DHCP approach as being in conflict. &n= bsp;They are merely different ways suited to different scenarios.  

I do not see implementing both LLDP-= based and DHCP-based methods in a phone as being a big deal, since in the e= nd they both are simple, would deliver the exact same data to the applicati= on above, and they start in a strict order (LLDP always before DHCP).  = ;The harder issue is really what would the poor phone do if it received by = both mechanisms, and the received data were different -- it would need to p= ick one, or sort out the conflict itself (yech!).  

Since LLDP (hence LLDP-MED) is stric= tly contained to a physical link, its security is very contained.  

IEEE 802.1X is applied to that same = link before LLDP gets to run (or before DHCP for that matter), so at least = the endpoint can be well authenticated before hand.  Also, it intuitiv= ely makes sense at least in my fuzzy brain, that the X509 certs which could= be part of the 802.1X authentication exchange (if EAP-TLS is used) could a= lso be useful in the upward authentication process.  (If I have messed= up the acronyms, please do not jump down my throat .. hopefully close enou= gh.)

It would indeed be unfortunate to ad= d a third approach ... or a forth ....   I am not familiar with whatev= er the DSL approach would be, but do not off-hand see why a DHCP relay appr= oach would not work there.  Anything written up to look at on it?

Peter







"Brian Rosen" <br@br= ianrosen.net>

20.04.05 10:47

       
        To: &nbs= p;      "'Michael Hammer (mhammer)'" <mhammer@c= isco.com>, <peter=5Fblatherwick@mitel.com>
        cc: &nbs= p;      "'GEOPRIV WG'" <geopriv@ietf.org>, &= lt;ecrit@ietf.org>
        Subject:=        RE: [Ecrit] RE: [Geopriv] Announcement of Joint= GEOPRIV/ECRIT InterimMeeting



The idea is that, say, you are in y= our home, served by a DSL provider.
The domain is then that of the DSL vendor.  Your phone asks for its lo= cation
from the server in the DSL domain.  It would be given the location
corresponding to the IP address of the request.  Note that this would = be
pretty good for the requested case, even in the presence of a NATed local area network in your home.  The phone would do this on boot, before an= y VPN
tunnels were established.

I get the idea that a single delivery mechanism is desirable.  I'm ske= ptical
we can do that because of the security issues.  When you make the deli= very
mechanism L2 dependent, you can control the possible attacks to a finer
grain than the L7 local domain.

Please keep in mind that some of the folks wishing to use the L7 mechanism<= br> don't really want to just return location to the endpoint; they want to
retain the location and give it out to authorized entities upon presentatio= n
of the IP address of the endpoint.  That is a business decision.  = ;They can
charge for such a service.  I think the privacy implications of that a= re
dicey, but the reality is that's the model that will probably be implemente= d
if we do this.  

Brian





> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Wednesday, April 20, 2005 10:14 AM
> To: Brian Rosen; peter=5Fblatherwick@mitel.com
> Cc: GEOPRIV WG; ecrit@ietf.org
> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=
> InterimMeeting
>
> Brian,
>
> Could you clarify the domain statement.  Given nomadicity, it wou= ld seem
> that location delivery would need to be cross-domain.  The E911 P= SAP will
> not always be the same domain as the roaming endpoint.
>
> My impression is that Location discovery is a L2 issue, tied to the fa= ct
> that L2 is supposed to be a single physical hop at most between the en= d-
> user terminal and an adjacent location-determining network node.  = ;(Of
> course those trying to make L2 protocols a replacement for IP sort of<= br> > screw this assumption up.)
>
> The location delivery mechanism is an application-layer or L7 service.=
> The argument there is that since multiple applications will need to re= ly
> on location information, a general purpose delivery mechanism will pro= vide
> consistency and generality that is so often sought in IETF work.  = ;Security
> can be built-in to the chosen delivery mechanism.  Note, that del= ivery
> could be a choice of an existing transfer mechanism.  This does n= ot
> preclude other L7 protocols from defining a place in their messages th= at
> could also carry location information.
>
> So, I believe:
> Location discovery is local, with associated security being local,
> Location delivery is global, with associated security being global.
>
> The real issues are making those happen.
>
> Mike
>
> >-----Original Message-----
> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> >On Behalf Of Brian Rosen
> >Sent: Wednesday, April 20, 2005 9:54 AM
> >To: peter=5Fblatherwick@mitel.com
> >Cc: 'GEOPRIV WG'; ecrit@ietf.org
> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT InterimMeeting
> >
> >There turns out to be a large set of issues around this
> >problem, which I fear is leading to Balkanization.  There are=
> >two really important problems we need to solve.
> >
> >One fundamental problem is that every client needs to
> >implement every possible LI transfer mechanism that its
> >environment could provide.
> >
> >We have DHCP.  You guys are working on LLDP-MED.   The D= SL
> >guys reject both
> >of these and want a something else.  Every phone has to
> >implement every protocol.
> >
> >There are some who have observed that the mechanisms at hand
> >are L2 specific.  They claim as long as you have an L2
> >specific mechanism, you need one or more for each L2.  To get=
> >out of that, they propose that we use an L7 mechanism (think
> >some version of HTTP, although that might not fly).  They
> >would say, lets do that once, and every L2 can use it.  The > >problem is that you then have to deal with the security issues
> >of an L7 mechanism, and in particular, you have to use IP
> >address as the "key" for what location to return.  = If you can
> >spoof IP address, you can get someone else's location.
> >
> >Those advocating L7 mechanisms claim that the mechanism would
> >only be implemented within a domain, and the domain would have
> >to take anti-spoofing steps.  They note that the mechanism
> >would need at least a complete round trip, and probably more
> >than one, so spoofing requires the ability to
> >intercept packets not addressed to the attacker.   The
> >returned data could
> >be precisely a PIDF-LO.
> >
> >Then on top of that, we turn out to need some more security,
> >especially for emergency calls.  We need to prevent forged
> >locations.  That means we need to sign the PIDF-LO.  If = you
> >get location via DHCP, or LLDP-MED, and the endpoint
> >constructs a PIDF-LO from that, how do we construct a
> >signature from the entity that actually determined location?
> >
> >Brian
> >
> >
> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> >From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On Behalf Of
> >peter=5Fblatherwick@mitel.com
> >Sent: Wednesday, April 20, 2005 9:30 AM
> >To: Andrew Newton
> >Cc: GEOPRIV WG; ecrit@ietf.org
> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> >Interim Meeting
> >
> >
> >Hi Andrew, lists,
> >
> >I'd like to better understand the meaning of the following
> >agenda items:
> >=A0 "
> >=A0 2) Properties of network elements in transferring LI from laye= r 2
> >=A0upward to PIDF-LO.
> >=A03) Proposed enhancements to PIDF-LO to support #2.
> >=A0"
> >
> >Is there a summary of what these really mean, or examples of
> >what the outcome could be in terms of protocol or layer
> >interactions?
> >
> >Reason I'm asking is I am deeply involved in a layer 2
> >approach which would be able to deliver location information
> >to endpoints from the L2 LAN infrastructure they are connected
> >to. =A0The work is going on in TIA and is called Link Layer
> >Discovery Protocol - Media Endpoint Discovery (LLDP-MED),
> >which is an extension of IEEE 802.1AB, specific to VoIP
> >systems. =A0In LLDP-MED, among several other things, we have
> >specified ways to pass equivalent data to the DHCP
> >coordinate-based LCI (RFC 3825) and civic location LCI
> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I
> >believe). =A0We see this method of delivery as a non-competing
> >alternative to the DHCP-based approach, with the same end
> >result to the overall ECS system (the endpoint receives the
> >exact same data), which has some advantages particularly in
> >enterprise deployment scenarios. =A0(The DHCP-based method has
> >advantages in different scenarios.) =A0 I am Editor of thi s
> >document, and it is now in ballot process in TIA (more or less
> >equivalent to Last Call in IETF).
> >
> >Sorry, I expect I am suffering lack of context here, since I
> >only joined the list relatively recently.
> >
> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past
> >Last Call and in the RFC Editor's queue? =A0It seemed to have
> >been settled on the list, and waiting on AD action.
> >
> >-- Peter Blatherwick
> >
> >
> >
> >
> >Andrew Newton <andy@hxr.us>
> >Sent by: geopriv-bounces@ietf.org
> >13.04.05 16:34
> >
> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG <geopriv@ietf.org= >
> >=A0 =A0 =A0 =A0 cc:
> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint
> >GEOPRIV/ECRIT Interim Meeting
> >
> >
> >
> >
> >The GEOPRIV and ECRIT working groups will be holding a joint
> >interim meeting.
> >
> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting
> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30
> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30
> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30
> >=A0 =A0 =A0Where: Columbia University
> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science
> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg.
> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.)=
> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027
> >Directions: http://www.cs.columbia.edu/directions.html
> >=A0 =A0 =A0 Also: WiFi pro= vided.
> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided.
> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html<= br> > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended.
> >
> >Proposed GEOPRIV Agenda:
> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30
> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use
> >of LI in HTTP/HTML for web browsing.
> >2) Properties of network elements in transferring LI from
> >layer 2 upward to PIDF-LO.
> >3) Proposed enhancements to PIDF-LO to support #2.
> >
> >Proposed ECRIT Agenda:
> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30
> >1) Emergency Call Routing Requirements
> >2) Security and Threats Analysis
> >
> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
> >Geopriv mailing list
> >Geopriv@ietf.org
> >https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> >
> >
> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ecrit
> >
>





--=_alternative 005F21C685256FE9_=-- --===============0630967659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0630967659==-- From ecrit-bounces@ietf.org Wed Apr 20 13:34:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJ5v-0001FU-OF; Wed, 20 Apr 2005 13:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJ5t-0001FJ-HJ; Wed, 20 Apr 2005 13:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00510; Wed, 20 Apr 2005 13:34:30 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJH9-0002Gd-I0; Wed, 20 Apr 2005 13:46:12 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2005 13:34:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3KHYIRS008720; Wed, 20 Apr 2005 13:34:21 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 13:34:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 13:34:16 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3113B4B@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACuDTwAABc4NAAAh/ZEA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 20 Apr 2005 17:34:17.0811 (UTC) FILETIME=[2DC13230:01C545CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, You describe the NENA phase i2 options, ESQK etc. Your routing element, = I assume is doing session routing. The elements you detail are all (or would appear to be) = application-layer entities and the signaling hops are likewise = application-layer hops, not L2 hops (except for maybe the LIS-->EP).=20 So, where is the L2 "dependency" coming from? I understand that a network node that is immediately adjacent to the = endpoint is most likely to know where the other end of the link = terminates, but does that force the delivery protocol aspects of this to = be a L2 issue? Each of the myriad link types carry IP packets, no? And IP packets can = carry an application packet, no? So, wouldn't the application-layer = solution be the more general one? I thought that was in line with IETF = principles. You are probably just laying out the options, not promoting a particular = one. I would be interested in seeing what the champions of one approach = or another have to say. (I did a search on LLDP-MED and drew a blank.) Mike >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, April 20, 2005 12:13 PM >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com >Cc: 'GEOPRIV WG'; ecrit@ietf.org >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT InterimMeeting > >The basic picture is: > >LIS ---> endpoint ---> routing element ---> psap > >The LIS knows where the endpoint is. >The endpoint gets location from the LIS >The endpoint includes location on the emergency call The=20 >routing element uses location to route the call to the right=20 >PSAP The PSAP gets the call, and the location. > >The discussion is, how does the endpoint get location from the LIS? >DHCP is one answer. LLDP-MED is another. A proposed L7=20 >mechanism is another. > > >To be sure, there are folks who want to make the picture: > >LIS --> endpoint --> routing element ---> psap > ^ | | > | | | > +------------------------+ | > | | > +------------------------------------------+ > >The LIS gives the endpoint a "key" >The endpoint includes the key in the emergency call The=20 >routing element gets the key and exchanges it for location at=20 >the LIS The psap gets the key and exchanges it for location at the LIS > >The key could be an IP address. > >Brian > > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Wednesday, April 20, 2005 12:00 PM >> To: Brian Rosen; peter_blatherwick@mitel.com >> Cc: GEOPRIV WG; ecrit@ietf.org >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT=20 >> InterimMeeting >>=20 >> I still get the feeling that "delivery" is being used in two=20 >different >> contexts: >>=20 >> (1) (2) >> Local node---?---->endpoint-----/many hops/----->PSAP >> ---------------------/many hops/-----> >> (2) >>=20 >> How can "delivery" be L2 dependent, when it must reach a PSAP many=20 >> hops away? >> Color me confused. >>=20 >> Mike >>=20 >>=20 >> >-----Original Message----- >> >From: Brian Rosen [mailto:br@brianrosen.net] >> >Sent: Wednesday, April 20, 2005 10:47 AM >> >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org >> >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >> >GEOPRIV/ECRIT InterimMeeting >> > >> >The idea is that, say, you are in your home, served by a=20 >DSL provider. >> >The domain is then that of the DSL vendor. Your phone asks for its=20 >> >location from the server in the DSL domain. It would be given the=20 >> >location corresponding to the IP address of the request. Note that=20 >> >this would be pretty good for the requested case, even in the=20 >> >presence of a NATed local area network in your home. The=20 >phone would=20 >> >do this on boot, before any VPN tunnels were established. >> > >> >I get the idea that a single delivery mechanism is desirable. >> >I'm skeptical we can do that because of the security issues. >> >When you make the delivery mechanism L2 dependent, you can control=20 >> >the possible attacks to a finer grain than the L7 local domain. >> > >> >Please keep in mind that some of the folks wishing to use the >> >L7 mechanism don't really want to just return location to the=20 >> >endpoint; they want to retain the location and give it out to=20 >> >authorized entities upon presentation of the IP address of the=20 >> >endpoint. That is a business decision. They can charge for such a=20 >> >service. I think the privacy implications of that are=20 >dicey, but the=20 >> >reality is that's the model that will probably be implemented if we=20 >> >do this. >> > >> >Brian >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> >> Sent: Wednesday, April 20, 2005 10:14 AM >> >> To: Brian Rosen; peter_blatherwick@mitel.com >> >> Cc: GEOPRIV WG; ecrit@ietf.org >> >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint >> >GEOPRIV/ECRIT >> >> InterimMeeting >> >> >> >> Brian, >> >> >> >> Could you clarify the domain statement. Given=20 >nomadicity, it would=20 >> >> seem that location delivery would need to be cross-domain. The=20 >> >> E911 PSAP will not always be the same domain as the=20 >roaming endpoint. >> >> >> >> My impression is that Location discovery is a L2 issue,=20 >tied to the=20 >> >> fact that L2 is supposed to be a single physical hop at most=20 >> >> between the end- user terminal and an adjacent=20 >location-determining=20 >> >> network node. (Of course those trying to make L2 protocols a >> >replacement for >> >> IP sort of screw this assumption up.) >> >> >> >> The location delivery mechanism is an application-layer or >> >L7 service. >> >> The argument there is that since multiple applications=20 >will need to=20 >> >> rely on location information, a general purpose delivery=20 >mechanism=20 >> >> will provide consistency and generality that is so often=20 >sought in=20 >> >> IETF work. Security can be built-in to the chosen delivery >> >mechanism. >> >> Note, that delivery could be a choice of an existing transfer=20 >> >> mechanism. This does not preclude other L7 protocols from >> >defining a >> >> place in their messages that could also carry location=20 >information. >> >> >> >> So, I believe: >> >> Location discovery is local, with associated security=20 >being local,=20 >> >> Location delivery is global, with associated security=20 >being global. >> >> >> >> The real issues are making those happen. >> >> >> >> Mike >> >> >> >> >-----Original Message----- >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> >> >Behalf Of Brian Rosen >> >> >Sent: Wednesday, April 20, 2005 9:54 AM >> >> >To: peter_blatherwick@mitel.com >> >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org >> >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT=20 >> >> >InterimMeeting >> >> > >> >> >There turns out to be a large set of issues around this problem,=20 >> >> >which I fear is leading to Balkanization. There are two really=20 >> >> >important problems we need to solve. >> >> > >> >> >One fundamental problem is that every client needs to >> >implement every >> >> >possible LI transfer mechanism that its environment=20 >could provide. >> >> > >> >> >We have DHCP. You guys are working on LLDP-MED. The DSL >> >> >guys reject both >> >> >of these and want a something else. Every phone has to=20 >implement=20 >> >> >every protocol. >> >> > >> >> >There are some who have observed that the mechanisms at hand are=20 >> >> >L2 specific. They claim as long as you have an L2 specific=20 >> >> >mechanism, you need one or more for each L2. To get out=20 >of that,=20 >> >> >they propose that we use an L7 mechanism (think some version of=20 >> >> >HTTP, although that might not fly). They would say,=20 >lets do that=20 >> >> >once, >> >and every L2 >> >> >can use it. The problem is that you then have to deal with the=20 >> >> >security issues of an L7 mechanism, and in particular,=20 >you have to=20 >> >> >use IP address as the "key" for what location to return. >> >If you can >> >> >spoof IP address, you can get someone else's location. >> >> > >> >> >Those advocating L7 mechanisms claim that the mechanism >> >would only be >> >> >implemented within a domain, and the domain would have to take=20 >> >> >anti-spoofing steps. They note that the mechanism would need at=20 >> >> >least a complete round trip, and probably more than one, so >> >spoofing >> >> >requires the ability to >> >> >intercept packets not addressed to the attacker. The >> >> >returned data could >> >> >be precisely a PIDF-LO. >> >> > >> >> >Then on top of that, we turn out to need some more security,=20 >> >> >especially for emergency calls. We need to prevent forged >> >locations. >> >> >That means we need to sign the PIDF-LO. If you get location via=20 >> >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from=20 >> >> >that, how do we construct a signature from the entity that=20 >> >> >actually determined location? >> >> > >> >> >Brian >> >> > >> >> > >> >> >________________________________________ >> >> >From: geopriv-bounces@ietf.org >> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of=20 >> >> >peter_blatherwick@mitel.com >> >> >Sent: Wednesday, April 20, 2005 9:30 AM >> >> >To: Andrew Newton >> >> >Cc: GEOPRIV WG; ecrit@ietf.org >> >> >Subject: Re: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT Interim=20 >> >> >Meeting >> >> > >> >> > >> >> >Hi Andrew, lists, >> >> > >> >> >I'd like to better understand the meaning of the following agenda >> >> >items: >> >> >=A0 " >> >> >=A0 2) Properties of network elements in transferring LI=20 >from layer=20 >> >> >2 >> >> >=A0upward to PIDF-LO. >> >> >=A03) Proposed enhancements to PIDF-LO to support #2. >> >> >=A0" >> >> > >> >> >Is there a summary of what these really mean, or examples >> >of what the >> >> >outcome could be in terms of protocol or layer interactions? >> >> > >> >> >Reason I'm asking is I am deeply involved in a layer 2 >> >approach which >> >> >would be able to deliver location information to endpoints from=20 >> >> >the >> >> >L2 LAN infrastructure they are connected to. =A0The work is >> >going on in >> >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20 >> >> >Discovery (LLDP-MED), which is an extension of IEEE >> >802.1AB, specific >> >> >to VoIP systems. =A0In LLDP-MED, among several other=20 >things, we have=20 >> >> >specified ways to pass equivalent data to the DHCP=20 >> >> >coordinate-based LCI (RFC 3825) and civic location LCI=20 >> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I >> >believe). >> >> >We see this method of delivery as a non-competing >> >alternative to the >> >> >DHCP-based approach, with the same end result to the overall ECS=20 >> >> >system (the endpoint receives the exact same data),=20 >which has some=20 >> >> >advantages particularly in enterprise deployment=20 >scenarios. =A0(The=20 >> >> >DHCP-based method has advantages in different scenarios.) =A0 I = am=20 >> >> >Editor of thi s document, and it is now in ballot process in TIA=20 >> >> >(more or less equivalent to Last Call in IETF). >> >> > >> >> >Sorry, I expect I am suffering lack of context here,=20 >since I only=20 >> >> >joined the list relatively recently. >> >> > >> >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now=20 >past Last=20 >> >> >Call and in the RFC Editor's queue? =A0It seemed to have been=20 >> >> >settled on the list, and waiting on AD action. >> >> > >> >> >-- Peter Blatherwick >> >> > >> >> > >> >> > >> >> > >> >> >Andrew Newton >> >> >Sent by: geopriv-bounces@ietf.org >> >> >13.04.05 16:34 >> >> > >> >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG >> >> >=A0 =A0 =A0 =A0 cc: >> >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint >> >GEOPRIV/ECRIT >> >> >Interim Meeting >> >> > >> >> > >> >> > >> >> > >> >> >The GEOPRIV and ECRIT working groups will be holding a >> >joint interim >> >> >meeting. >> >> > >> >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting >> >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 >> >> >=A0 =A0 =A0Where: Columbia University >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science >> >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. >> >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th = St.) >> >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 >> >> >Directions: http://www.cs.columbia.edu/directions.html >> >> >=A0 =A0 =A0 Also: WiFi provided. >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. >> >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. >> >> > >> >> >Proposed GEOPRIV Agenda: >> >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 >> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the >> >use of LI >> >> >in HTTP/HTML for web browsing. >> >> >2) Properties of network elements in transferring LI=20 >from layer 2=20 >> >> >upward to PIDF-LO. >> >> >3) Proposed enhancements to PIDF-LO to support #2. >> >> > >> >> >Proposed ECRIT Agenda: >> >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 >> >> >1) Emergency Call Routing Requirements >> >> >2) Security and Threats Analysis >> >> > >> >> >_______________________________________________ >> >> >Geopriv mailing list >> >> >Geopriv@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/geopriv >> >> > >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> >Ecrit mailing list >> >> >Ecrit@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/ecrit >> >> > >> >> >> > >> > >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 13:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJAW-0001rV-37; Wed, 20 Apr 2005 13:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJAU-0001rL-Fg; Wed, 20 Apr 2005 13:39:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00961; Wed, 20 Apr 2005 13:39:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJLj-0002Ov-Sa; Wed, 20 Apr 2005 13:50:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2005 10:38:54 -0700 X-IronPort-AV: i="3.92,117,1112598000"; d="scan'208,217"; a="252330175:sNHT1847132934" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3KHcmKx025229; Wed, 20 Apr 2005 10:38:49 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA00138; Wed, 20 Apr 2005 10:38:50 -0700 (PDT) Message-Id: <200504201738.KAA00138@malone.cisco.com> From: "Marc Linsner" To: Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRITInterimMeeting Date: Wed, 20 Apr 2005 13:38:46 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVFzZWTd8vaxlzBS/e0NHcBRBpmGwAAbnZw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.3 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0549447944==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0549447944== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DC9_01C545AE.47BA39A0" This is a multi-part message in MIME format. ------=_NextPart_000_0DC9_01C545AE.47BA39A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit snip... It would indeed be unfortunate to add a third approach ... or a forth .... I am not familiar with whatever the DSL approach would be, but do not off-hand see why a DHCP relay approach would not work there. Anything written up to look at on it? Peter [[ml]] Peter, take a look at: http://www.dslforum.org/aboutdsl/Technical_Reports/TR-069.pdf -Marc- ------=_NextPart_000_0DC9_01C545AE.47BA39A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

snip…..

 


It would indeed be unfortunate to add a third = approach ... or a forth ....   I am not familiar with whatever the DSL = approach would be, but do not off-hand see why a DHCP relay approach would not = work there.  Anything written up to look at on it?

Peter

[[ml]] Peter, take a look at:

ht= tp://www.dslforum.org/aboutdsl/Technical_Reports/TR-069.pdf

-Marc-

=

 

=
------=_NextPart_000_0DC9_01C545AE.47BA39A0-- --===============0549447944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0549447944==-- From ecrit-bounces@ietf.org Wed Apr 20 13:48:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJJ3-0003CP-Nk; Wed, 20 Apr 2005 13:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJJ2-0003Br-5M; Wed, 20 Apr 2005 13:48:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01759; Wed, 20 Apr 2005 13:48:05 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJUG-0002j4-LQ; Wed, 20 Apr 2005 13:59:47 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3KHlrIP004600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2005 10:47:53 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3KHlnLU008191; Wed, 20 Apr 2005 10:47:50 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <00b444334545222d572fc588237e6742@hxr.us> References: <00b444334545222d572fc588237e6742@hxr.us> Date: Wed, 20 Apr 2005 10:47:47 -0700 To: Andrew Newton , peter_blatherwick@mitel.com From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: GEOPRIV WG , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 9:52 AM -0400 4/20/05, Andrew Newton wrote: >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last Call >and in the RFC Editor's queue? It seemed to have been settled on the >list, and waiting on AD action. I'm awaiting a revision of this, as there was a last call comment by Ralph Droms asking for clarification of whether the option could be sent from server-to-host and host-to-server. Here's an excerpt of his comment: > >So, I think the draft needs to be extended with a section on whether the >option can be sent from the server to the host, from the host to the server. >Might also be good to be specific about whether the client can request the >option and whether the server can send it unsolicited. Here's Henning's reply: >Ralph, > >thanks for your comments. I think your observation applies to both >this draft and RFC 3825 (on geo long/lat coordinates). I agree that >both directions are useful, although the direction from host to >server might necessitate the inclusion of the core privacy elements >into the object (distribution, retention). > >The draft assumes, probably without the appropriately clear wording, >beyond the introductory "End systems that obtain location >information via the mechanism" sentence, that this is server-to-host. Because the draft is in a fairly late state, I had to approve an update to make this clarification; I did so last Friday. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 13:58:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJSp-0004la-Vx; Wed, 20 Apr 2005 13:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJSn-0004lN-My; Wed, 20 Apr 2005 13:58:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02407; Wed, 20 Apr 2005 13:58:12 -0400 (EDT) Message-Id: <200504201758.NAA02407@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJe3-00030C-Ly; Wed, 20 Apr 2005 14:09:52 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOJSc-0002Yl-Ko; Wed, 20 Apr 2005 12:58:03 -0500 From: "Brian Rosen" To: Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 13:57:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVFzQtKCi3rAWwaRkiwoVEz3TatVgAAaAkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Peter For some time, I have accepted the fact that we aren=92t going to be = able to have one mechanism. I don=92t like it, but it seems inevitable. You = have to admit that once you say =93more than one=94 and your reasoning is = =93different scenarios=94 you open the door to the next guy who gets to make the same argument. What are the phone vendors going to do? You really, really = don=92t want a phone making one assumption and the network L2 vendors another. = The scenarios where LLDP-MED works COULD, reasonably, use DHCP. You might = like LLDP-MED for any number of reasons, but it=92s not the case that DHCP = wouldn=92t work. The reverse is not true; there are many networks where there is = no switch that could reasonably implement LLDP-MED. CableModem is an = obvious one. At the moment, I=92m rationalizing =93home=3DDHCP, = enterprise=3DLLDP-MED=94, but I don=92t want a phone vendor assuming he is only serving one of those markets. You guys have made our life difficult, and I don=92t really = think it had to be, but its reality. The appeal of the L7 mechanism was that we could have one. Alas, I = don=92t see how to make it work. Ethernet connected devices will probably need LLDP-MED and DHCP. That=92s my current message to phone vendors. At the moment, all the DSL folks I talk to insist that they won=92t = deploy a DHCP mechanism or an LLDP-MED mechanism. They want something else. = That=92s the immediate impetuous for the L7 discussion. If L7 mechanisms don=92t = work, and I don=92t think they do, then we either need a DSL L2 mechanism, or = we need them to buy my =93home router uses DHCP to clients, and anything = the want to the DSL side=94 argument. The DSL guys have some allies; basically = boxes in the middle of L2 that don=92t have a relationship with the DHCP box. = The example is the WiFi management boxes. They know which AP you are = connected to; some may even triangulate. But those boxes don=92t run DHCP, and = they don=92t have an interface to them. L7 works for them too; especially = because they can limit the domain to the subnet(s) their management boxes = handle. Maybe that=92s the angle to attack; define an interface to the DHCP = server that lets it get location so it can hand it out to the endpoints. = I=92ve tried to argue that they could implement LLDP-MED. I got push back from = one of them, but the reasons don=92t make sense to me yet. I=92ve been working on this for some time. The inclination of EVERY L2 = player is =93we need a mechanism just for us=94. That, clearly, won=92t work. = What I tell them is =93if you can control the specification of every end device = that directly or indirectly connects to your L2, then use anything you like, = as long as EVERY device that is connected to your L2 can get location. If = you can=92t control endpoints like that, use DHCP (or LLDP-MED)=94. 3G is = an example of an L2 where they can control all the endpoints. They have a = way to get location, and that=92s good enough for me. =20 Brian ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, April 20, 2005 1:21 PM To: Brian Rosen Cc: ecrit@ietf.org; 'GEOPRIV WG'; 'Michael Hammer (mhammer)' Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Seems a simple-minded question has sparked a flurry of debate ;-) =A0 = =A0Some thoughts, just to stir the pot some more... not that it appears to need it...=20 I do not at all see the purely L2 LLDP-MED approach and the call it L2.5 DHCP approach as being in conflict. =A0They are merely different ways = suited to different scenarios. =A0=20 I do not see implementing both LLDP-based and DHCP-based methods in a = phone as being a big deal, since in the end they both are simple, would = deliver the exact same data to the application above, and they start in a strict order (LLDP always before DHCP). =A0The harder issue is really what = would the poor phone do if it received by both mechanisms, and the received data = were different -- it would need to pick one, or sort out the conflict itself (yech!). =A0=20 Since LLDP (hence LLDP-MED) is strictly contained to a physical link, = its security is very contained. =A0=20 IEEE 802.1X is applied to that same link before LLDP gets to run (or = before DHCP for that matter), so at least the endpoint can be well = authenticated before hand. =A0Also, it intuitively makes sense at least in my fuzzy = brain, that the X509 certs which could be part of the 802.1X authentication exchange (if EAP-TLS is used) could also be useful in the upward authentication process. =A0(If I have messed up the acronyms, please do = not jump down my throat .. hopefully close enough.)=20 It would indeed be unfortunate to add a third approach ... or a forth = .... =A0 I am not familiar with whatever the DSL approach would be, but do not off-hand see why a DHCP relay approach would not work there. =A0Anything written up to look at on it?=20 Peter=20 "Brian Rosen" =20 20.04.05 10:47=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"'Michael Hammer (mhammer)'" = , =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"'GEOPRIV WG'" , = =20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] RE: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT InterimMeeting The idea is that, say, you are in your home, served by a DSL provider. The domain is then that of the DSL vendor. =A0Your phone asks for its = location from the server in the DSL domain. =A0It would be given the location corresponding to the IP address of the request. =A0Note that this would = be pretty good for the requested case, even in the presence of a NATed = local area network in your home. =A0The phone would do this on boot, before = any VPN tunnels were established. I get the idea that a single delivery mechanism is desirable. =A0I'm = skeptical we can do that because of the security issues. =A0When you make the = delivery mechanism L2 dependent, you can control the possible attacks to a finer grain than the L7 local domain. Please keep in mind that some of the folks wishing to use the L7 = mechanism don't really want to just return location to the endpoint; they want to retain the location and give it out to authorized entities upon = presentation of the IP address of the endpoint. =A0That is a business decision. = =A0They can charge for such a service. =A0I think the privacy implications of that = are dicey, but the reality is that's the model that will probably be = implemented if we do this. =A0 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 10:14 AM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting >=20 > Brian, >=20 > Could you clarify the domain statement. =A0Given nomadicity, it would = seem > that location delivery would need to be cross-domain. =A0The E911 PSAP = will > not always be the same domain as the roaming endpoint. >=20 > My impression is that Location discovery is a L2 issue, tied to the = fact > that L2 is supposed to be a single physical hop at most between the = end- > user terminal and an adjacent location-determining network node. = =A0(Of > course those trying to make L2 protocols a replacement for IP sort of > screw this assumption up.) >=20 > The location delivery mechanism is an application-layer or L7 service. > The argument there is that since multiple applications will need to = rely > on location information, a general purpose delivery mechanism will = provide > consistency and generality that is so often sought in IETF work. = =A0Security > can be built-in to the chosen delivery mechanism. =A0Note, that = delivery > could be a choice of an existing transfer mechanism. =A0This does not > preclude other L7 protocols from defining a place in their messages = that > could also carry location information. >=20 > So, I believe: > Location discovery is local, with associated security being local, > Location delivery is global, with associated security being global. >=20 > The real issues are making those happen. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Brian Rosen > >Sent: Wednesday, April 20, 2005 9:54 AM > >To: peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >There turns out to be a large set of issues around this > >problem, which I fear is leading to Balkanization. =A0There are > >two really important problems we need to solve. > > > >One fundamental problem is that every client needs to > >implement every possible LI transfer mechanism that its > >environment could provide. > > > >We have DHCP. =A0You guys are working on LLDP-MED. =A0 The DSL > >guys reject both > >of these and want a something else. =A0Every phone has to > >implement every protocol.=20 > > > >There are some who have observed that the mechanisms at hand > >are L2 specific. =A0They claim as long as you have an L2 > >specific mechanism, you need one or more for each L2. =A0To get > >out of that, they propose that we use an L7 mechanism (think > >some version of HTTP, although that might not fly). =A0They > >would say, lets do that once, and every L2 can use it. =A0The > >problem is that you then have to deal with the security issues > >of an L7 mechanism, and in particular, you have to use IP > >address as the "key" for what location to return. =A0If you can > >spoof IP address, you can get someone else's location. > > > >Those advocating L7 mechanisms claim that the mechanism would > >only be implemented within a domain, and the domain would have > >to take anti-spoofing steps. =A0They note that the mechanism > >would need at least a complete round trip, and probably more > >than one, so spoofing requires the ability to > >intercept packets not addressed to the attacker. =A0 The > >returned data could > >be precisely a PIDF-LO. > > > >Then on top of that, we turn out to need some more security, > >especially for emergency calls. =A0We need to prevent forged > >locations. =A0That means we need to sign the PIDF-LO. =A0If you > >get location via DHCP, or LLDP-MED, and the endpoint > >constructs a PIDF-LO from that, how do we construct a > >signature from the entity that actually determined location? > > > >Brian > > > > > >________________________________________ > >From: geopriv-bounces@ietf.org > >[mailto:geopriv-bounces@ietf.org] On Behalf Of > >peter_blatherwick@mitel.com > >Sent: Wednesday, April 20, 2005 9:30 AM > >To: Andrew Newton > >Cc: GEOPRIV WG; ecrit@ietf.org > >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >Interim Meeting > > > > > >Hi Andrew, lists, > > > >I'd like to better understand the meaning of the following > >agenda items: > >=A0 " > >=A0 2) Properties of network elements in transferring LI from layer 2 > >=A0upward to PIDF-LO. > >=A03) Proposed enhancements to PIDF-LO to support #2. > >=A0" > > > >Is there a summary of what these really mean, or examples of > >what the outcome could be in terms of protocol or layer > >interactions? > > > >Reason I'm asking is I am deeply involved in a layer 2 > >approach which would be able to deliver location information > >to endpoints from the L2 LAN infrastructure they are connected > >to. =A0The work is going on in TIA and is called Link Layer > >Discovery Protocol - Media Endpoint Discovery (LLDP-MED), > >which is an extension of IEEE 802.1AB, specific to VoIP > >systems. =A0In LLDP-MED, among several other things, we have > >specified ways to pass equivalent data to the DHCP > >coordinate-based LCI (RFC 3825) and civic location LCI > >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). =A0We see this method of delivery as a non-competing > >alternative to the DHCP-based approach, with the same end > >result to the overall ECS system (the endpoint receives the > >exact same data), which has some advantages particularly in > >enterprise deployment scenarios. =A0(The DHCP-based method has > >advantages in different scenarios.) =A0 I am Editor of thi s > >document, and it is now in ballot process in TIA (more or less > >equivalent to Last Call in IETF). > > > >Sorry, I expect I am suffering lack of context here, since I > >only joined the list relatively recently. > > > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past > >Last Call and in the RFC Editor's queue? =A0It seemed to have > >been settled on the list, and waiting on AD action. > > > >-- Peter Blatherwick > > > > > > > > > >Andrew Newton > >Sent by: geopriv-bounces@ietf.org > >13.04.05 16:34 > > > >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >=A0 =A0 =A0 =A0 cc: > >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint > >GEOPRIV/ECRIT Interim Meeting > > > > > > > > > >The GEOPRIV and ECRIT working groups will be holding a joint > >interim meeting. > > > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >=A0 =A0 =A0Where: Columbia University > >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >Directions: http://www.cs.columbia.edu/directions.html=20 > >=A0 =A0 =A0 Also: WiFi provided. > >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > > >Proposed GEOPRIV Agenda: > >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use > >of LI in HTTP/HTML for web browsing. > >2) Properties of network elements in transferring LI from > >layer 2 upward to PIDF-LO. > >3) Proposed enhancements to PIDF-LO to support #2. > > > >Proposed ECRIT Agenda: > >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >1) Emergency Call Routing Requirements > >2) Security and Threats Analysis > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 14:08:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJcJ-0006sd-2D; Wed, 20 Apr 2005 14:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJcG-0006rx-J8; Wed, 20 Apr 2005 14:08:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03774; Wed, 20 Apr 2005 14:07:59 -0400 (EDT) Message-Id: <200504201807.OAA03774@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJnW-0003X5-TW; Wed, 20 Apr 2005 14:19:39 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOJc6-0003Od-2n; Wed, 20 Apr 2005 13:07:50 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 14:07:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3113B4B@xmb-rtp-20b.amer.cisco.com> Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACuDTwAABc4NAAAh/ZEAAB1+tQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org "Routing" in this context is session (SIP) routing, as you suspected. The first hop (LIS to endpoint) is what we are discussing. DHCP is not an L3+ protocol. Neither is LLDP-MED. The thread has discussed a number of problems with an L7 mechanism, but laying them out: 1. You are subject to IP address spoofing (albeit you need to be able to = get the packets sent from the LIS to the IP address you are spoofing) 2. VPN or other tunnels may have been created before you run this = protocol. That will cause a failure; you need the location corresponding to the original "outermost" IP address. 3. It is difficult to control the security (beyond IP spoofing) because = you don't have a generally good authentication mechanism. This is a bare = phone, or equivalent, during its boot phase.=20 There are probably others as well. 2) is the real problem. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 1:34 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting >=20 > Brian, >=20 > You describe the NENA phase i2 options, ESQK etc. Your routing = element, I > assume is doing session routing. >=20 > The elements you detail are all (or would appear to be) = application-layer > entities and the signaling hops are likewise application-layer hops, = not > L2 hops (except for maybe the LIS-->EP). >=20 > So, where is the L2 "dependency" coming from? >=20 > I understand that a network node that is immediately adjacent to the > endpoint is most likely to know where the other end of the link > terminates, but does that force the delivery protocol aspects of this = to > be a L2 issue? >=20 > Each of the myriad link types carry IP packets, no? And IP packets = can > carry an application packet, no? So, wouldn't the application-layer > solution be the more general one? I thought that was in line with = IETF > principles. >=20 > You are probably just laying out the options, not promoting a = particular > one. I would be interested in seeing what the champions of one = approach > or another have to say. (I did a search on LLDP-MED and drew a = blank.) >=20 > Mike >=20 > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 12:13 PM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The basic picture is: > > > >LIS ---> endpoint ---> routing element ---> psap > > > >The LIS knows where the endpoint is. > >The endpoint gets location from the LIS > >The endpoint includes location on the emergency call The > >routing element uses location to route the call to the right > >PSAP The PSAP gets the call, and the location. > > > >The discussion is, how does the endpoint get location from the LIS? > >DHCP is one answer. LLDP-MED is another. A proposed L7 > >mechanism is another. > > > > > >To be sure, there are folks who want to make the picture: > > > >LIS --> endpoint --> routing element ---> psap > > ^ | | > > | | | > > +------------------------+ | > > | | > > +------------------------------------------+ > > > >The LIS gives the endpoint a "key" > >The endpoint includes the key in the emergency call The > >routing element gets the key and exchanges it for location at > >the LIS The psap gets the key and exchanges it for location at the = LIS > > > >The key could be an IP address. > > > >Brian > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 12:00 PM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> I still get the feeling that "delivery" is being used in two > >different > >> contexts: > >> > >> (1) (2) > >> Local node---?---->endpoint-----/many hops/----->PSAP > >> ---------------------/many hops/-----> > >> (2) > >> > >> How can "delivery" be L2 dependent, when it must reach a PSAP many > >> hops away? > >> Color me confused. > >> > >> Mike > >> > >> > >> >-----Original Message----- > >> >From: Brian Rosen [mailto:br@brianrosen.net] > >> >Sent: Wednesday, April 20, 2005 10:47 AM > >> >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >> >GEOPRIV/ECRIT InterimMeeting > >> > > >> >The idea is that, say, you are in your home, served by a > >DSL provider. > >> >The domain is then that of the DSL vendor. Your phone asks for = its > >> >location from the server in the DSL domain. It would be given the > >> >location corresponding to the IP address of the request. Note = that > >> >this would be pretty good for the requested case, even in the > >> >presence of a NATed local area network in your home. The > >phone would > >> >do this on boot, before any VPN tunnels were established. > >> > > >> >I get the idea that a single delivery mechanism is desirable. > >> >I'm skeptical we can do that because of the security issues. > >> >When you make the delivery mechanism L2 dependent, you can control > >> >the possible attacks to a finer grain than the L7 local domain. > >> > > >> >Please keep in mind that some of the folks wishing to use the > >> >L7 mechanism don't really want to just return location to the > >> >endpoint; they want to retain the location and give it out to > >> >authorized entities upon presentation of the IP address of the > >> >endpoint. That is a business decision. They can charge for such = a > >> >service. I think the privacy implications of that are > >dicey, but the > >> >reality is that's the model that will probably be implemented if = we > >> >do this. > >> > > >> >Brian > >> > > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> >> Sent: Wednesday, April 20, 2005 10:14 AM > >> >> To: Brian Rosen; peter_blatherwick@mitel.com > >> >> Cc: GEOPRIV WG; ecrit@ietf.org > >> >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >> >GEOPRIV/ECRIT > >> >> InterimMeeting > >> >> > >> >> Brian, > >> >> > >> >> Could you clarify the domain statement. Given > >nomadicity, it would > >> >> seem that location delivery would need to be cross-domain. The > >> >> E911 PSAP will not always be the same domain as the > >roaming endpoint. > >> >> > >> >> My impression is that Location discovery is a L2 issue, > >tied to the > >> >> fact that L2 is supposed to be a single physical hop at most > >> >> between the end- user terminal and an adjacent > >location-determining > >> >> network node. (Of course those trying to make L2 protocols a > >> >replacement for > >> >> IP sort of screw this assumption up.) > >> >> > >> >> The location delivery mechanism is an application-layer or > >> >L7 service. > >> >> The argument there is that since multiple applications > >will need to > >> >> rely on location information, a general purpose delivery > >mechanism > >> >> will provide consistency and generality that is so often > >sought in > >> >> IETF work. Security can be built-in to the chosen delivery > >> >mechanism. > >> >> Note, that delivery could be a choice of an existing transfer > >> >> mechanism. This does not preclude other L7 protocols from > >> >defining a > >> >> place in their messages that could also carry location > >information. > >> >> > >> >> So, I believe: > >> >> Location discovery is local, with associated security > >being local, > >> >> Location delivery is global, with associated security > >being global. > >> >> > >> >> The real issues are making those happen. > >> >> > >> >> Mike > >> >> > >> >> >-----Original Message----- > >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >> >Behalf Of Brian Rosen > >> >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >> >To: peter_blatherwick@mitel.com > >> >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >> >InterimMeeting > >> >> > > >> >> >There turns out to be a large set of issues around this = problem, > >> >> >which I fear is leading to Balkanization. There are two really > >> >> >important problems we need to solve. > >> >> > > >> >> >One fundamental problem is that every client needs to > >> >implement every > >> >> >possible LI transfer mechanism that its environment > >could provide. > >> >> > > >> >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >> >guys reject both > >> >> >of these and want a something else. Every phone has to > >implement > >> >> >every protocol. > >> >> > > >> >> >There are some who have observed that the mechanisms at hand = are > >> >> >L2 specific. They claim as long as you have an L2 specific > >> >> >mechanism, you need one or more for each L2. To get out > >of that, > >> >> >they propose that we use an L7 mechanism (think some version of > >> >> >HTTP, although that might not fly). They would say, > >lets do that > >> >> >once, > >> >and every L2 > >> >> >can use it. The problem is that you then have to deal with the > >> >> >security issues of an L7 mechanism, and in particular, > >you have to > >> >> >use IP address as the "key" for what location to return. > >> >If you can > >> >> >spoof IP address, you can get someone else's location. > >> >> > > >> >> >Those advocating L7 mechanisms claim that the mechanism > >> >would only be > >> >> >implemented within a domain, and the domain would have to take > >> >> >anti-spoofing steps. They note that the mechanism would need = at > >> >> >least a complete round trip, and probably more than one, so > >> >spoofing > >> >> >requires the ability to > >> >> >intercept packets not addressed to the attacker. The > >> >> >returned data could > >> >> >be precisely a PIDF-LO. > >> >> > > >> >> >Then on top of that, we turn out to need some more security, > >> >> >especially for emergency calls. We need to prevent forged > >> >locations. > >> >> >That means we need to sign the PIDF-LO. If you get location = via > >> >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from > >> >> >that, how do we construct a signature from the entity that > >> >> >actually determined location? > >> >> > > >> >> >Brian > >> >> > > >> >> > > >> >> >________________________________________ > >> >> >From: geopriv-bounces@ietf.org > >> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of > >> >> >peter_blatherwick@mitel.com > >> >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >> >To: Andrew Newton > >> >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >> >Subject: Re: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT Interim > >> >> >Meeting > >> >> > > >> >> > > >> >> >Hi Andrew, lists, > >> >> > > >> >> >I'd like to better understand the meaning of the following = agenda > >> >> >items: > >> >> >=A0 " > >> >> >=A0 2) Properties of network elements in transferring LI > >from layer > >> >> >2 > >> >> >=A0upward to PIDF-LO. > >> >> >=A03) Proposed enhancements to PIDF-LO to support #2. > >> >> >=A0" > >> >> > > >> >> >Is there a summary of what these really mean, or examples > >> >of what the > >> >> >outcome could be in terms of protocol or layer interactions? > >> >> > > >> >> >Reason I'm asking is I am deeply involved in a layer 2 > >> >approach which > >> >> >would be able to deliver location information to endpoints from > >> >> >the > >> >> >L2 LAN infrastructure they are connected to. =A0The work is > >> >going on in > >> >> >TIA and is called Link Layer Discovery Protocol - Media = Endpoint > >> >> >Discovery (LLDP-MED), which is an extension of IEEE > >> >802.1AB, specific > >> >> >to VoIP systems. =A0In LLDP-MED, among several other > >things, we have > >> >> >specified ways to pass equivalent data to the DHCP > >> >> >coordinate-based LCI (RFC 3825) and civic location LCI > >> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >> >believe). > >> >> >We see this method of delivery as a non-competing > >> >alternative to the > >> >> >DHCP-based approach, with the same end result to the overall = ECS > >> >> >system (the endpoint receives the exact same data), > >which has some > >> >> >advantages particularly in enterprise deployment > >scenarios. =A0(The > >> >> >DHCP-based method has advantages in different scenarios.) =A0 I = am > >> >> >Editor of thi s document, and it is now in ballot process in = TIA > >> >> >(more or less equivalent to Last Call in IETF). > >> >> > > >> >> >Sorry, I expect I am suffering lack of context here, > >since I only > >> >> >joined the list relatively recently. > >> >> > > >> >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now > >past Last > >> >> >Call and in the RFC Editor's queue? =A0It seemed to have been > >> >> >settled on the list, and waiting on AD action. > >> >> > > >> >> >-- Peter Blatherwick > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >Andrew Newton > >> >> >Sent by: geopriv-bounces@ietf.org > >> >> >13.04.05 16:34 > >> >> > > >> >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG = > >> >> >=A0 =A0 =A0 =A0 cc: > >> >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement = of Joint > >> >GEOPRIV/ECRIT > >> >> >Interim Meeting > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >The GEOPRIV and ECRIT working groups will be holding a > >> >joint interim > >> >> >meeting. > >> >> > > >> >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >> >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >> >> >=A0 =A0 =A0Where: Columbia University > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th = St.) > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >> >> >Directions: http://www.cs.columbia.edu/directions.html > >> >> >=A0 =A0 =A0 Also: WiFi provided. > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >> >> >=A0 =A0 =A0Hotel: = http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > >> >> > > >> >> >Proposed GEOPRIV Agenda: > >> >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >> >use of LI > >> >> >in HTTP/HTML for web browsing. > >> >> >2) Properties of network elements in transferring LI > >from layer 2 > >> >> >upward to PIDF-LO. > >> >> >3) Proposed enhancements to PIDF-LO to support #2. > >> >> > > >> >> >Proposed ECRIT Agenda: > >> >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >> >1) Emergency Call Routing Requirements > >> >> >2) Security and Threats Analysis > >> >> > > >> >> >_______________________________________________ > >> >> >Geopriv mailing list > >> >> >Geopriv@ietf.org > >> >> >https://www1.ietf.org/mailman/listinfo/geopriv > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >Ecrit mailing list > >> >> >Ecrit@ietf.org > >> >> >https://www1.ietf.org/mailman/listinfo/ecrit > >> >> > > >> >> > >> > > >> > > >> > > > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 14:15:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJjx-00086o-Eg; Wed, 20 Apr 2005 14:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJjw-00086g-2h; Wed, 20 Apr 2005 14:15:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04451; Wed, 20 Apr 2005 14:15:55 -0400 (EDT) Message-Id: <200504201815.OAA04451@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOJvC-0003nP-Cu; Wed, 20 Apr 2005 14:27:35 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOJjl-00043W-15; Wed, 20 Apr 2005 13:15:45 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRITInterimMeeting Date: Wed, 20 Apr 2005 14:15:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200504201807.OAA03774@ietf.org> Thread-Index: AcVFrYhmxTho0nmmTYm23JF4ZdqckAAAFPnQAAEDlWAAASJSUAACuDTwAABc4NAAAh/ZEAAB1+tQAABzcIA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One more little tidbit about 2) The failure is really, really bad. You can get a location which is = wrong, and there is no way to figure out that it happened. You ask for = location inside the tunnel, and the local domain replies with what it thinks the location is (typically that of the site where the tunnel terminates). = In some environments, the location mechanism can figure out that you are = coming in on an IP address that is not known to be local, and at least fail = better than giving out the wrong location. Wrong location is much worse that = not getting a location, or getting one, but knowing there was a problem. Brian > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf > Of Brian Rosen > Sent: Wednesday, April 20, 2005 2:08 PM > To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com > Cc: 'GEOPRIV WG'; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > GEOPRIV/ECRITInterimMeeting >=20 > "Routing" in this context is session (SIP) routing, as you suspected. >=20 > The first hop (LIS to endpoint) is what we are discussing. > DHCP is not an L3+ protocol. Neither is LLDP-MED. >=20 > The thread has discussed a number of problems with an L7 mechanism, = but > laying them out: >=20 > 1. You are subject to IP address spoofing (albeit you need to be able = to > get > the packets sent from the LIS to the IP address you are spoofing) >=20 > 2. VPN or other tunnels may have been created before you run this > protocol. > That will cause a failure; you need the location corresponding to the > original "outermost" IP address. >=20 > 3. It is difficult to control the security (beyond IP spoofing) = because > you > don't have a generally good authentication mechanism. This is a bare > phone, > or equivalent, during its boot phase. >=20 > There are probably others as well. 2) is the real problem. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, April 20, 2005 1:34 PM > > To: Brian Rosen; peter_blatherwick@mitel.com > > Cc: GEOPRIV WG; ecrit@ietf.org > > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint = GEOPRIV/ECRIT > > InterimMeeting > > > > Brian, > > > > You describe the NENA phase i2 options, ESQK etc. Your routing = element, > I > > assume is doing session routing. > > > > The elements you detail are all (or would appear to be) application- > layer > > entities and the signaling hops are likewise application-layer hops, = not > > L2 hops (except for maybe the LIS-->EP). > > > > So, where is the L2 "dependency" coming from? > > > > I understand that a network node that is immediately adjacent to the > > endpoint is most likely to know where the other end of the link > > terminates, but does that force the delivery protocol aspects of = this to > > be a L2 issue? > > > > Each of the myriad link types carry IP packets, no? And IP packets = can > > carry an application packet, no? So, wouldn't the application-layer > > solution be the more general one? I thought that was in line with = IETF > > principles. > > > > You are probably just laying out the options, not promoting a = particular > > one. I would be interested in seeing what the champions of one = approach > > or another have to say. (I did a search on LLDP-MED and drew a = blank.) > > > > Mike > > > > >-----Original Message----- > > >From: Brian Rosen [mailto:br@brianrosen.net] > > >Sent: Wednesday, April 20, 2005 12:13 PM > > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > > >GEOPRIV/ECRIT InterimMeeting > > > > > >The basic picture is: > > > > > >LIS ---> endpoint ---> routing element ---> psap > > > > > >The LIS knows where the endpoint is. > > >The endpoint gets location from the LIS > > >The endpoint includes location on the emergency call The > > >routing element uses location to route the call to the right > > >PSAP The PSAP gets the call, and the location. > > > > > >The discussion is, how does the endpoint get location from the LIS? > > >DHCP is one answer. LLDP-MED is another. A proposed L7 > > >mechanism is another. > > > > > > > > >To be sure, there are folks who want to make the picture: > > > > > >LIS --> endpoint --> routing element ---> psap > > > ^ | | > > > | | | > > > +------------------------+ | > > > | | > > > +------------------------------------------+ > > > > > >The LIS gives the endpoint a "key" > > >The endpoint includes the key in the emergency call The > > >routing element gets the key and exchanges it for location at > > >the LIS The psap gets the key and exchanges it for location at the = LIS > > > > > >The key could be an IP address. > > > > > >Brian > > > > > > > > >> -----Original Message----- > > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >> Sent: Wednesday, April 20, 2005 12:00 PM > > >> To: Brian Rosen; peter_blatherwick@mitel.com > > >> Cc: GEOPRIV WG; ecrit@ietf.org > > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > > >GEOPRIV/ECRIT > > >> InterimMeeting > > >> > > >> I still get the feeling that "delivery" is being used in two > > >different > > >> contexts: > > >> > > >> (1) (2) > > >> Local node---?---->endpoint-----/many hops/----->PSAP > > >> ---------------------/many hops/-----> > > >> (2) > > >> > > >> How can "delivery" be L2 dependent, when it must reach a PSAP = many > > >> hops away? > > >> Color me confused. > > >> > > >> Mike > > >> > > >> > > >> >-----Original Message----- > > >> >From: Brian Rosen [mailto:br@brianrosen.net] > > >> >Sent: Wednesday, April 20, 2005 10:47 AM > > >> >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > > >> >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > > >> >GEOPRIV/ECRIT InterimMeeting > > >> > > > >> >The idea is that, say, you are in your home, served by a > > >DSL provider. > > >> >The domain is then that of the DSL vendor. Your phone asks for = its > > >> >location from the server in the DSL domain. It would be given = the > > >> >location corresponding to the IP address of the request. Note = that > > >> >this would be pretty good for the requested case, even in the > > >> >presence of a NATed local area network in your home. The > > >phone would > > >> >do this on boot, before any VPN tunnels were established. > > >> > > > >> >I get the idea that a single delivery mechanism is desirable. > > >> >I'm skeptical we can do that because of the security issues. > > >> >When you make the delivery mechanism L2 dependent, you can = control > > >> >the possible attacks to a finer grain than the L7 local domain. > > >> > > > >> >Please keep in mind that some of the folks wishing to use the > > >> >L7 mechanism don't really want to just return location to the > > >> >endpoint; they want to retain the location and give it out to > > >> >authorized entities upon presentation of the IP address of the > > >> >endpoint. That is a business decision. They can charge for = such a > > >> >service. I think the privacy implications of that are > > >dicey, but the > > >> >reality is that's the model that will probably be implemented if = we > > >> >do this. > > >> > > > >> >Brian > > >> > > > >> > > > >> > > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >> >> Sent: Wednesday, April 20, 2005 10:14 AM > > >> >> To: Brian Rosen; peter_blatherwick@mitel.com > > >> >> Cc: GEOPRIV WG; ecrit@ietf.org > > >> >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > > >> >GEOPRIV/ECRIT > > >> >> InterimMeeting > > >> >> > > >> >> Brian, > > >> >> > > >> >> Could you clarify the domain statement. Given > > >nomadicity, it would > > >> >> seem that location delivery would need to be cross-domain. = The > > >> >> E911 PSAP will not always be the same domain as the > > >roaming endpoint. > > >> >> > > >> >> My impression is that Location discovery is a L2 issue, > > >tied to the > > >> >> fact that L2 is supposed to be a single physical hop at most > > >> >> between the end- user terminal and an adjacent > > >location-determining > > >> >> network node. (Of course those trying to make L2 protocols a > > >> >replacement for > > >> >> IP sort of screw this assumption up.) > > >> >> > > >> >> The location delivery mechanism is an application-layer or > > >> >L7 service. > > >> >> The argument there is that since multiple applications > > >will need to > > >> >> rely on location information, a general purpose delivery > > >mechanism > > >> >> will provide consistency and generality that is so often > > >sought in > > >> >> IETF work. Security can be built-in to the chosen delivery > > >> >mechanism. > > >> >> Note, that delivery could be a choice of an existing transfer > > >> >> mechanism. This does not preclude other L7 protocols from > > >> >defining a > > >> >> place in their messages that could also carry location > > >information. > > >> >> > > >> >> So, I believe: > > >> >> Location discovery is local, with associated security > > >being local, > > >> >> Location delivery is global, with associated security > > >being global. > > >> >> > > >> >> The real issues are making those happen. > > >> >> > > >> >> Mike > > >> >> > > >> >> >-----Original Message----- > > >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On > > >> >> >Behalf Of Brian Rosen > > >> >> >Sent: Wednesday, April 20, 2005 9:54 AM > > >> >> >To: peter_blatherwick@mitel.com > > >> >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > > >> >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > > >GEOPRIV/ECRIT > > >> >> >InterimMeeting > > >> >> > > > >> >> >There turns out to be a large set of issues around this = problem, > > >> >> >which I fear is leading to Balkanization. There are two = really > > >> >> >important problems we need to solve. > > >> >> > > > >> >> >One fundamental problem is that every client needs to > > >> >implement every > > >> >> >possible LI transfer mechanism that its environment > > >could provide. > > >> >> > > > >> >> >We have DHCP. You guys are working on LLDP-MED. The DSL > > >> >> >guys reject both > > >> >> >of these and want a something else. Every phone has to > > >implement > > >> >> >every protocol. > > >> >> > > > >> >> >There are some who have observed that the mechanisms at hand = are > > >> >> >L2 specific. They claim as long as you have an L2 specific > > >> >> >mechanism, you need one or more for each L2. To get out > > >of that, > > >> >> >they propose that we use an L7 mechanism (think some version = of > > >> >> >HTTP, although that might not fly). They would say, > > >lets do that > > >> >> >once, > > >> >and every L2 > > >> >> >can use it. The problem is that you then have to deal with = the > > >> >> >security issues of an L7 mechanism, and in particular, > > >you have to > > >> >> >use IP address as the "key" for what location to return. > > >> >If you can > > >> >> >spoof IP address, you can get someone else's location. > > >> >> > > > >> >> >Those advocating L7 mechanisms claim that the mechanism > > >> >would only be > > >> >> >implemented within a domain, and the domain would have to = take > > >> >> >anti-spoofing steps. They note that the mechanism would need = at > > >> >> >least a complete round trip, and probably more than one, so > > >> >spoofing > > >> >> >requires the ability to > > >> >> >intercept packets not addressed to the attacker. The > > >> >> >returned data could > > >> >> >be precisely a PIDF-LO. > > >> >> > > > >> >> >Then on top of that, we turn out to need some more security, > > >> >> >especially for emergency calls. We need to prevent forged > > >> >locations. > > >> >> >That means we need to sign the PIDF-LO. If you get location = via > > >> >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from > > >> >> >that, how do we construct a signature from the entity that > > >> >> >actually determined location? > > >> >> > > > >> >> >Brian > > >> >> > > > >> >> > > > >> >> >________________________________________ > > >> >> >From: geopriv-bounces@ietf.org > > >> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of > > >> >> >peter_blatherwick@mitel.com > > >> >> >Sent: Wednesday, April 20, 2005 9:30 AM > > >> >> >To: Andrew Newton > > >> >> >Cc: GEOPRIV WG; ecrit@ietf.org > > >> >> >Subject: Re: [Geopriv] Announcement of Joint > > >GEOPRIV/ECRIT Interim > > >> >> >Meeting > > >> >> > > > >> >> > > > >> >> >Hi Andrew, lists, > > >> >> > > > >> >> >I'd like to better understand the meaning of the following = agenda > > >> >> >items: > > >> >> >=A0 " > > >> >> >=A0 2) Properties of network elements in transferring LI > > >from layer > > >> >> >2 > > >> >> >=A0upward to PIDF-LO. > > >> >> >=A03) Proposed enhancements to PIDF-LO to support #2. > > >> >> >=A0" > > >> >> > > > >> >> >Is there a summary of what these really mean, or examples > > >> >of what the > > >> >> >outcome could be in terms of protocol or layer interactions? > > >> >> > > > >> >> >Reason I'm asking is I am deeply involved in a layer 2 > > >> >approach which > > >> >> >would be able to deliver location information to endpoints = from > > >> >> >the > > >> >> >L2 LAN infrastructure they are connected to. =A0The work is > > >> >going on in > > >> >> >TIA and is called Link Layer Discovery Protocol - Media = Endpoint > > >> >> >Discovery (LLDP-MED), which is an extension of IEEE > > >> >802.1AB, specific > > >> >> >to VoIP systems. =A0In LLDP-MED, among several other > > >things, we have > > >> >> >specified ways to pass equivalent data to the DHCP > > >> >> >coordinate-based LCI (RFC 3825) and civic location LCI > > >> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > > >> >believe). > > >> >> >We see this method of delivery as a non-competing > > >> >alternative to the > > >> >> >DHCP-based approach, with the same end result to the overall = ECS > > >> >> >system (the endpoint receives the exact same data), > > >which has some > > >> >> >advantages particularly in enterprise deployment > > >scenarios. =A0(The > > >> >> >DHCP-based method has advantages in different scenarios.) =A0 = I am > > >> >> >Editor of thi s document, and it is now in ballot process in = TIA > > >> >> >(more or less equivalent to Last Call in IETF). > > >> >> > > > >> >> >Sorry, I expect I am suffering lack of context here, > > >since I only > > >> >> >joined the list relatively recently. > > >> >> > > > >> >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now > > >past Last > > >> >> >Call and in the RFC Editor's queue? =A0It seemed to have been > > >> >> >settled on the list, and waiting on AD action. > > >> >> > > > >> >> >-- Peter Blatherwick > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> >Andrew Newton > > >> >> >Sent by: geopriv-bounces@ietf.org > > >> >> >13.04.05 16:34 > > >> >> > > > >> >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG = > > >> >> >=A0 =A0 =A0 =A0 cc: > > >> >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] = Announcement of Joint > > >> >GEOPRIV/ECRIT > > >> >> >Interim Meeting > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> >The GEOPRIV and ECRIT working groups will be holding a > > >> >joint interim > > >> >> >meeting. > > >> >> > > > >> >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > > >> >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > > >> >> >=A0 =A0 =A0Where: Columbia University > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th = St.) > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > > >> >> >Directions: http://www.cs.columbia.edu/directions.html > > >> >> >=A0 =A0 =A0 Also: WiFi provided. > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > > >> >> >=A0 =A0 =A0Hotel: = http://www.cs.columbia.edu/~hgs/etc/hotels.html > > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > >> >> > > > >> >> >Proposed GEOPRIV Agenda: > > >> >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > > >> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > > >> >use of LI > > >> >> >in HTTP/HTML for web browsing. > > >> >> >2) Properties of network elements in transferring LI > > >from layer 2 > > >> >> >upward to PIDF-LO. > > >> >> >3) Proposed enhancements to PIDF-LO to support #2. > > >> >> > > > >> >> >Proposed ECRIT Agenda: > > >> >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > > >> >> >1) Emergency Call Routing Requirements > > >> >> >2) Security and Threats Analysis > > >> >> > > > >> >> >_______________________________________________ > > >> >> >Geopriv mailing list > > >> >> >Geopriv@ietf.org > > >> >> >https://www1.ietf.org/mailman/listinfo/geopriv > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> >_______________________________________________ > > >> >> >Ecrit mailing list > > >> >> >Ecrit@ietf.org > > >> >> >https://www1.ietf.org/mailman/listinfo/ecrit > > >> >> > > > >> >> > > >> > > > >> > > > >> > > > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 15:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKaC-0006B5-JE; Wed, 20 Apr 2005 15:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKaA-0006Ax-Nn; Wed, 20 Apr 2005 15:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09266; Wed, 20 Apr 2005 15:09:53 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKlQ-0005SV-NJ; Wed, 20 Apr 2005 15:21:33 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j3KJ9KF05876; Wed, 20 Apr 2005 15:09:20 -0400 (EDT) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005042015091812919 ; Wed, 20 Apr 2005 15:09:18 -0400 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 15:09:18 -0400 Message-ID: From: "Abbott, Nadine B." To: "'Brian Rosen'" , peter_blatherwick@mitel.com Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Wed, 20 Apr 2005 15:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Really need to change the name of this thread... -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Wednesday, April 20, 2005 1:58 PM To: peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Michael Hammer (mhammer)' Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Peter For some time, I have accepted the fact that we aren't going to be able = to have one mechanism. I don't like it, but it seems inevitable. You = have to admit that once you say "more than one" and your reasoning is = "different scenarios" you open the door to the next guy who gets to make the same argument. What are the phone vendors going to do? You really, really = don't want a phone making one assumption and the network L2 vendors another. = The scenarios where LLDP-MED works COULD, reasonably, use DHCP. You might = like LLDP-MED for any number of reasons, but it's not the case that DHCP = wouldn't work. The reverse is not true; there are many networks where there is = no switch that could reasonably implement LLDP-MED. CableModem is an = obvious one. At the moment, I'm rationalizing "home=3DDHCP, = enterprise=3DLLDP-MED", but I don't want a phone vendor assuming he is only serving one of those markets. You guys have made our life difficult, and I don't really = think it had to be, but its reality. The appeal of the L7 mechanism was that we could have one. Alas, I = don't see how to make it work. Ethernet connected devices will probably need LLDP-MED and DHCP. That's my current message to phone vendors. At the moment, all the DSL folks I talk to insist that they won't = deploy a DHCP mechanism or an LLDP-MED mechanism. They want something else. = That's the immediate impetuous for the L7 discussion. If L7 mechanisms don't = work, and I don't think they do, then we either need a DSL L2 mechanism, or = we need them to buy my "home router uses DHCP to clients, and anything the = want to the DSL side" argument. The DSL guys have some allies; basically = boxes in the middle of L2 that don't have a relationship with the DHCP box. = The example is the WiFi management boxes. They know which AP you are = connected to; some may even triangulate. But those boxes don't run DHCP, and = they don't have an interface to them. L7 works for them too; especially = because they can limit the domain to the subnet(s) their management boxes = handle. Maybe that's the angle to attack; define an interface to the DHCP = server that lets it get location so it can hand it out to the endpoints. I've tried to argue that they could implement LLDP-MED. I got push back = from one of them, but the reasons don't make sense to me yet. I've been working on this for some time. The inclination of EVERY L2 = player is "we need a mechanism just for us". That, clearly, won't work. What = I tell them is "if you can control the specification of every end device = that directly or indirectly connects to your L2, then use anything you like, = as long as EVERY device that is connected to your L2 can get location. If = you can't control endpoints like that, use DHCP (or LLDP-MED)". 3G is an example of an L2 where they can control all the endpoints. They have a = way to get location, and that's good enough for me. =20 Brian ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, April 20, 2005 1:21 PM To: Brian Rosen Cc: ecrit@ietf.org; 'GEOPRIV WG'; 'Michael Hammer (mhammer)' Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Seems a simple-minded question has sparked a flurry of debate ;-) =A0 = =A0Some thoughts, just to stir the pot some more... not that it appears to need it...=20 I do not at all see the purely L2 LLDP-MED approach and the call it = L2.5 DHCP approach as being in conflict. =A0They are merely different ways = suited to different scenarios. =A0=20 I do not see implementing both LLDP-based and DHCP-based methods in a = phone as being a big deal, since in the end they both are simple, would = deliver the exact same data to the application above, and they start in a = strict order (LLDP always before DHCP). =A0The harder issue is really what = would the poor phone do if it received by both mechanisms, and the received data = were different -- it would need to pick one, or sort out the conflict itself (yech!). =A0=20 Since LLDP (hence LLDP-MED) is strictly contained to a physical link, = its security is very contained. =A0=20 IEEE 802.1X is applied to that same link before LLDP gets to run (or = before DHCP for that matter), so at least the endpoint can be well = authenticated before hand. =A0Also, it intuitively makes sense at least in my fuzzy = brain, that the X509 certs which could be part of the 802.1X authentication exchange (if EAP-TLS is used) could also be useful in the upward authentication process. =A0(If I have messed up the acronyms, please do = not jump down my throat .. hopefully close enough.)=20 It would indeed be unfortunate to add a third approach ... or a forth = .... =A0 I am not familiar with whatever the DSL approach would be, but do not off-hand see why a DHCP relay approach would not work there. = =A0Anything written up to look at on it?=20 Peter=20 "Brian Rosen" =20 20.04.05 10:47=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"'Michael Hammer (mhammer)'" = , =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"'GEOPRIV WG'" , = =20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] RE: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT InterimMeeting The idea is that, say, you are in your home, served by a DSL provider. = The domain is then that of the DSL vendor. =A0Your phone asks for its = location from the server in the DSL domain. =A0It would be given the location corresponding to the IP address of the request. =A0Note that this would = be pretty good for the requested case, even in the presence of a NATed = local area network in your home. =A0The phone would do this on boot, before = any VPN tunnels were established. I get the idea that a single delivery mechanism is desirable. =A0I'm = skeptical we can do that because of the security issues. =A0When you make the = delivery mechanism L2 dependent, you can control the possible attacks to a finer grain than the L7 local domain. Please keep in mind that some of the folks wishing to use the L7 = mechanism don't really want to just return location to the endpoint; they want to retain the location and give it out to authorized entities upon = presentation of the IP address of the endpoint. =A0That is a business decision. = =A0They can charge for such a service. =A0I think the privacy implications of that = are dicey, but the reality is that's the model that will probably be = implemented if we do this. =A0 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 10:14 AM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint = GEOPRIV/ECRIT=20 > InterimMeeting >=20 > Brian, >=20 > Could you clarify the domain statement. =A0Given nomadicity, it would = > seem that location delivery would need to be cross-domain. =A0The = E911=20 > PSAP will not always be the same domain as the roaming endpoint. >=20 > My impression is that Location discovery is a L2 issue, tied to the=20 > fact that L2 is supposed to be a single physical hop at most between=20 > the end- user terminal and an adjacent location-determining network=20 > node. =A0(Of course those trying to make L2 protocols a replacement = for=20 > IP sort of screw this assumption up.) >=20 > The location delivery mechanism is an application-layer or L7 = service.=20 > The argument there is that since multiple applications will need to > rely on location information, a general purpose delivery mechanism=20 > will provide consistency and generality that is so often sought in=20 > IETF work. =A0Security can be built-in to the chosen delivery = mechanism. =A0 > Note, that delivery could be a choice of an existing transfer=20 > mechanism. =A0This does not preclude other L7 protocols from defining = a=20 > place in their messages that could also carry location information. >=20 > So, I believe: > Location discovery is local, with associated security being local,=20 > Location delivery is global, with associated security being global. >=20 > The real issues are making those happen. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >Behalf Of Brian Rosen > >Sent: Wednesday, April 20, 2005 9:54 AM > >To: peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > >InterimMeeting > > > >There turns out to be a large set of issues around this problem,=20 > >which I fear is leading to Balkanization. =A0There are two really=20 > >important problems we need to solve. > > > >One fundamental problem is that every client needs to implement = every=20 > >possible LI transfer mechanism that its environment could provide. > > > >We have DHCP. =A0You guys are working on LLDP-MED. =A0 The DSL guys=20 > >reject both of these and want a something else. =A0Every phone has = to > >implement every protocol.=20 > > > >There are some who have observed that the mechanisms at hand are L2=20 > >specific. =A0They claim as long as you have an L2 specific = mechanism,=20 > >you need one or more for each L2. =A0To get out of that, they = propose=20 > >that we use an L7 mechanism (think some version of HTTP, although=20 > >that might not fly). =A0They would say, lets do that once, and every = L2=20 > >can use it. =A0The problem is that you then have to deal with the=20 > >security issues of an L7 mechanism, and in particular, you have to=20 > >use IP address as the "key" for what location to return. =A0If you = can > >spoof IP address, you can get someone else's location. > > > >Those advocating L7 mechanisms claim that the mechanism would only = be=20 > >implemented within a domain, and the domain would have to take=20 > >anti-spoofing steps. =A0They note that the mechanism would need at=20 > >least a complete round trip, and probably more than one, so spoofing = > >requires the ability to intercept packets not addressed to the=20 > >attacker. =A0 The returned data could > >be precisely a PIDF-LO. > > > >Then on top of that, we turn out to need some more security,=20 > >especially for emergency calls. =A0We need to prevent forged = locations. =A0 > >That means we need to sign the PIDF-LO. =A0If you get location via=20 > >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that,=20 > >how do we construct a signature from the entity that actually=20 > >determined location? > > > >Brian > > > > > >________________________________________ > >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On=20 > >Behalf Of peter_blatherwick@mitel.com > >Sent: Wednesday, April 20, 2005 9:30 AM > >To: Andrew Newton > >Cc: GEOPRIV WG; ecrit@ietf.org > >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >Interim Meeting > > > > > >Hi Andrew, lists, > > > >I'd like to better understand the meaning of the following agenda=20 > >items: > >=A0 " > >=A0 2) Properties of network elements in transferring LI from layer = 2 > >=A0upward to PIDF-LO. > >=A03) Proposed enhancements to PIDF-LO to support #2. > >=A0" > > > >Is there a summary of what these really mean, or examples of what = the=20 > >outcome could be in terms of protocol or layer interactions? > > > >Reason I'm asking is I am deeply involved in a layer 2 approach = which=20 > >would be able to deliver location information to endpoints from the=20 > >L2 LAN infrastructure they are connected to. =A0The work is going on = in=20 > >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20 > >Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, = specific=20 > >to VoIP systems. =A0In LLDP-MED, among several other things, we have > >specified ways to pass equivalent data to the DHCP > >coordinate-based LCI (RFC 3825) and civic location LCI > >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). =A0We see this method of delivery as a non-competing > >alternative to the DHCP-based approach, with the same end > >result to the overall ECS system (the endpoint receives the > >exact same data), which has some advantages particularly in > >enterprise deployment scenarios. =A0(The DHCP-based method has > >advantages in different scenarios.) =A0 I am Editor of thi s > >document, and it is now in ballot process in TIA (more or less > >equivalent to Last Call in IETF). > > > >Sorry, I expect I am suffering lack of context here, since I only=20 > >joined the list relatively recently. > > > >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last = > >Call and in the RFC Editor's queue? =A0It seemed to have been = settled=20 > >on the list, and waiting on AD action. > > > >-- Peter Blatherwick > > > > > > > > > >Andrew Newton > >Sent by: geopriv-bounces@ietf.org > >13.04.05 16:34 > > > >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >=A0 =A0 =A0 =A0 cc: > >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of = Joint GEOPRIV/ECRIT=20 > >Interim Meeting > > > > > > > > > >The GEOPRIV and ECRIT working groups will be holding a joint interim = > >meeting. > > > >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >=A0 =A0 =A0Where: Columbia University > >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >Directions: http://www.cs.columbia.edu/directions.html > >=A0 =A0 =A0 Also: WiFi provided. > >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > > > >Proposed GEOPRIV Agenda: > >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI = > >in HTTP/HTML for web browsing. > >2) Properties of network elements in transferring LI from layer 2=20 > >upward to PIDF-LO. > >3) Proposed enhancements to PIDF-LO to support #2. > > > >Proposed ECRIT Agenda: > >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >1) Emergency Call Routing Requirements > >2) Security and Threats Analysis > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 15:23:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKn2-0007fT-Ah; Wed, 20 Apr 2005 15:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKmz-0007fL-JD; Wed, 20 Apr 2005 15:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10716; Wed, 20 Apr 2005 15:23:08 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKyF-0005kU-Lx; Wed, 20 Apr 2005 15:34:49 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j3KJMvF08303; Wed, 20 Apr 2005 15:22:57 -0400 (EDT) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005042015225514666 ; Wed, 20 Apr 2005 15:22:55 -0400 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 15:22:55 -0400 Message-ID: From: "Abbott, Nadine B." Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Wed, 20 Apr 2005 15:22:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dnsmx1rrc.telcordia.com id j3KJMvF08303 X-Spam-Score: 0.0 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Content-Transfer-Encoding: quoted-printable Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, Not clear to me why #2 is any more of a problem for an application query method, than the DHCP method. You have to have internet access before you can create the VPN (at least = on my software)--since we are talking about VPNs, I assume that we are talki= ng about softphones. If you have internet access, an application can perform a query to an LIS and get its location as soon as it gets its configuration information (by whatever mechanism). This can happen BEFORE you create the VPN (certainly what is assumed by t= he DHCP download mechanism). Then the endpoint has its location information and can provide it when it starts its VoIP application.=20 Nadine =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, April 20, 2005 2:08 PM To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting "Routing" in this context is session (SIP) routing, as you suspected. The first hop (LIS to endpoint) is what we are discussing. DHCP is not an L3+ protocol. Neither is LLDP-MED. The thread has discussed a number of problems with an L7 mechanism, but laying them out: 1. You are subject to IP address spoofing (albeit you need to be able to = get the packets sent from the LIS to the IP address you are spoofing) 2. VPN or other tunnels may have been created before you run this protoco= l. That will cause a failure; you need the location corresponding to the original "outermost" IP address. 3. It is difficult to control the security (beyond IP spoofing) because y= ou don't have a generally good authentication mechanism. This is a bare pho= ne, or equivalent, during its boot phase.=20 There are probably others as well. 2) is the real problem. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 1:34 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > InterimMeeting >=20 > Brian, >=20 > You describe the NENA phase i2 options, ESQK etc. Your routing=20 > element, I assume is doing session routing. >=20 > The elements you detail are all (or would appear to be)=20 > application-layer entities and the signaling hops are likewise=20 > application-layer hops, not L2 hops (except for maybe the LIS-->EP). >=20 > So, where is the L2 "dependency" coming from? >=20 > I understand that a network node that is immediately adjacent to the=20 > endpoint is most likely to know where the other end of the link=20 > terminates, but does that force the delivery protocol aspects of this=20 > to be a L2 issue? >=20 > Each of the myriad link types carry IP packets, no? And IP packets=20 > can carry an application packet, no? So, wouldn't the=20 > application-layer solution be the more general one? I thought that=20 > was in line with IETF principles. >=20 > You are probably just laying out the options, not promoting a=20 > particular one. I would be interested in seeing what the champions of=20 > one approach or another have to say. (I did a search on LLDP-MED and=20 > drew a blank.) >=20 > Mike >=20 > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 12:13 PM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 > >GEOPRIV/ECRIT InterimMeeting > > > >The basic picture is: > > > >LIS ---> endpoint ---> routing element ---> psap > > > >The LIS knows where the endpoint is. > >The endpoint gets location from the LIS > >The endpoint includes location on the emergency call The routing=20 > >element uses location to route the call to the right PSAP The PSAP=20 > >gets the call, and the location. > > > >The discussion is, how does the endpoint get location from the LIS?=20 > >DHCP is one answer. LLDP-MED is another. A proposed L7 mechanism is=20 > >another. > > > > > >To be sure, there are folks who want to make the picture: > > > >LIS --> endpoint --> routing element ---> psap > > ^ | | > > | | | > > +------------------------+ | > > | | > > +------------------------------------------+ > > > >The LIS gives the endpoint a "key" > >The endpoint includes the key in the emergency call The routing=20 > >element gets the key and exchanges it for location at the LIS The=20 > >psap gets the key and exchanges it for location at the LIS > > > >The key could be an IP address. > > > >Brian > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 12:00 PM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> I still get the feeling that "delivery" is being used in two > >different > >> contexts: > >> > >> (1) (2) > >> Local node---?---->endpoint-----/many hops/----->PSAP > >> ---------------------/many hops/-----> > >> (2) > >> > >> How can "delivery" be L2 dependent, when it must reach a PSAP many=20 > >> hops away? Color me confused. > >> > >> Mike > >> > >> > >> >-----Original Message----- > >> >From: Brian Rosen [mailto:br@brianrosen.net] > >> >Sent: Wednesday, April 20, 2005 10:47 AM > >> >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 > >> >GEOPRIV/ECRIT InterimMeeting > >> > > >> >The idea is that, say, you are in your home, served by a > >DSL provider. > >> >The domain is then that of the DSL vendor. Your phone asks for=20 > >> >its location from the server in the DSL domain. It would be given=20 > >> >the location corresponding to the IP address of the request. Note=20 > >> >that this would be pretty good for the requested case, even in the=20 > >> >presence of a NATed local area network in your home. The > >phone would > >> >do this on boot, before any VPN tunnels were established. > >> > > >> >I get the idea that a single delivery mechanism is desirable. I'm=20 > >> >skeptical we can do that because of the security issues. When you=20 > >> >make the delivery mechanism L2 dependent, you can control the=20 > >> >possible attacks to a finer grain than the L7 local domain. > >> > > >> >Please keep in mind that some of the folks wishing to use the L7=20 > >> >mechanism don't really want to just return location to the=20 > >> >endpoint; they want to retain the location and give it out to=20 > >> >authorized entities upon presentation of the IP address of the=20 > >> >endpoint. That is a business decision. They can charge for such=20 > >> >a service. I think the privacy implications of that are > >dicey, but the > >> >reality is that's the model that will probably be implemented if=20 > >> >we do this. > >> > > >> >Brian > >> > > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> >> Sent: Wednesday, April 20, 2005 10:14 AM > >> >> To: Brian Rosen; peter_blatherwick@mitel.com > >> >> Cc: GEOPRIV WG; ecrit@ietf.org > >> >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >> >GEOPRIV/ECRIT > >> >> InterimMeeting > >> >> > >> >> Brian, > >> >> > >> >> Could you clarify the domain statement. Given > >nomadicity, it would > >> >> seem that location delivery would need to be cross-domain. The=20 > >> >> E911 PSAP will not always be the same domain as the > >roaming endpoint. > >> >> > >> >> My impression is that Location discovery is a L2 issue, > >tied to the > >> >> fact that L2 is supposed to be a single physical hop at most=20 > >> >> between the end- user terminal and an adjacent > >location-determining > >> >> network node. (Of course those trying to make L2 protocols a > >> >replacement for > >> >> IP sort of screw this assumption up.) > >> >> > >> >> The location delivery mechanism is an application-layer or > >> >L7 service. > >> >> The argument there is that since multiple applications > >will need to > >> >> rely on location information, a general purpose delivery > >mechanism > >> >> will provide consistency and generality that is so often > >sought in > >> >> IETF work. Security can be built-in to the chosen delivery > >> >mechanism. > >> >> Note, that delivery could be a choice of an existing transfer=20 > >> >> mechanism. This does not preclude other L7 protocols from > >> >defining a > >> >> place in their messages that could also carry location > >information. > >> >> > >> >> So, I believe: > >> >> Location discovery is local, with associated security > >being local, > >> >> Location delivery is global, with associated security > >being global. > >> >> > >> >> The real issues are making those happen. > >> >> > >> >> Mike > >> >> > >> >> >-----Original Message----- > >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> >> >Behalf Of Brian Rosen > >> >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >> >To: peter_blatherwick@mitel.com > >> >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >> >InterimMeeting > >> >> > > >> >> >There turns out to be a large set of issues around this=20 > >> >> >problem, which I fear is leading to Balkanization. There are=20 > >> >> >two really important problems we need to solve. > >> >> > > >> >> >One fundamental problem is that every client needs to > >> >implement every > >> >> >possible LI transfer mechanism that its environment > >could provide. > >> >> > > >> >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >> >guys reject both > >> >> >of these and want a something else. Every phone has to > >implement > >> >> >every protocol. > >> >> > > >> >> >There are some who have observed that the mechanisms at hand=20 > >> >> >are L2 specific. They claim as long as you have an L2 specific=20 > >> >> >mechanism, you need one or more for each L2. To get out > >of that, > >> >> >they propose that we use an L7 mechanism (think some version of=20 > >> >> >HTTP, although that might not fly). They would say, > >lets do that > >> >> >once, > >> >and every L2 > >> >> >can use it. The problem is that you then have to deal with the=20 > >> >> >security issues of an L7 mechanism, and in particular, > >you have to > >> >> >use IP address as the "key" for what location to return. > >> >If you can > >> >> >spoof IP address, you can get someone else's location. > >> >> > > >> >> >Those advocating L7 mechanisms claim that the mechanism > >> >would only be > >> >> >implemented within a domain, and the domain would have to take=20 > >> >> >anti-spoofing steps. They note that the mechanism would need=20 > >> >> >at least a complete round trip, and probably more than one, so > >> >spoofing > >> >> >requires the ability to > >> >> >intercept packets not addressed to the attacker. The > >> >> >returned data could > >> >> >be precisely a PIDF-LO. > >> >> > > >> >> >Then on top of that, we turn out to need some more security,=20 > >> >> >especially for emergency calls. We need to prevent forged > >> >locations. > >> >> >That means we need to sign the PIDF-LO. If you get location=20 > >> >> >via DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO=20 > >> >> >from that, how do we construct a signature from the entity that=20 > >> >> >actually determined location? > >> >> > > >> >> >Brian > >> >> > > >> >> > > >> >> >________________________________________ > >> >> >From: geopriv-bounces@ietf.org=20 > >> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of=20 > >> >> >peter_blatherwick@mitel.com > >> >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >> >To: Andrew Newton > >> >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >> >Subject: Re: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT Interim > >> >> >Meeting > >> >> > > >> >> > > >> >> >Hi Andrew, lists, > >> >> > > >> >> >I'd like to better understand the meaning of the following=20 > >> >> >agenda > >> >> >items: > >> >> >=A0 " > >> >> >=A0 2) Properties of network elements in transferring LI > >from layer > >> >> >2 > >> >> >=A0upward to PIDF-LO. > >> >> >=A03) Proposed enhancements to PIDF-LO to support #2. > >> >> >=A0" > >> >> > > >> >> >Is there a summary of what these really mean, or examples > >> >of what the > >> >> >outcome could be in terms of protocol or layer interactions? > >> >> > > >> >> >Reason I'm asking is I am deeply involved in a layer 2 > >> >approach which > >> >> >would be able to deliver location information to endpoints from=20 > >> >> >the L2 LAN infrastructure they are connected to. =A0The work is > >> >going on in > >> >> >TIA and is called Link Layer Discovery Protocol - Media=20 > >> >> >Endpoint Discovery (LLDP-MED), which is an extension of IEEE > >> >802.1AB, specific > >> >> >to VoIP systems. =A0In LLDP-MED, among several other > >things, we have > >> >> >specified ways to pass equivalent data to the DHCP=20 > >> >> >coordinate-based LCI (RFC 3825) and civic location LCI=20 > >> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >> >believe). > >> >> >We see this method of delivery as a non-competing > >> >alternative to the > >> >> >DHCP-based approach, with the same end result to the overall=20 > >> >> >ECS system (the endpoint receives the exact same data), > >which has some > >> >> >advantages particularly in enterprise deployment > >scenarios. =A0(The > >> >> >DHCP-based method has advantages in different scenarios.) =A0 I=20 > >> >> >am Editor of thi s document, and it is now in ballot process in=20 > >> >> >TIA (more or less equivalent to Last Call in IETF). > >> >> > > >> >> >Sorry, I expect I am suffering lack of context here, > >since I only > >> >> >joined the list relatively recently. > >> >> > > >> >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now > >past Last > >> >> >Call and in the RFC Editor's queue? =A0It seemed to have been=20 > >> >> >settled on the list, and waiting on AD action. > >> >> > > >> >> >-- Peter Blatherwick > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >Andrew Newton > >> >> >Sent by: geopriv-bounces@ietf.org > >> >> >13.04.05 16:34 > >> >> > > >> >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >> >> >=A0 =A0 =A0 =A0 cc: > >> >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement o= f Joint > >> >GEOPRIV/ECRIT > >> >> >Interim Meeting > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >The GEOPRIV and ECRIT working groups will be holding a > >> >joint interim > >> >> >meeting. > >> >> > > >> >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >> >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >> >> >=A0 =A0 =A0Where: Columbia University > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St= .) > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >> >> >Directions: http://www.cs.columbia.edu/directions.html > >> >> >=A0 =A0 =A0 Also: WiFi provided. > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >> >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.htm= l > >> >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > >> >> > > >> >> >Proposed GEOPRIV Agenda: > >> >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >> >use of LI > >> >> >in HTTP/HTML for web browsing. > >> >> >2) Properties of network elements in transferring LI > >from layer 2 > >> >> >upward to PIDF-LO. > >> >> >3) Proposed enhancements to PIDF-LO to support #2. > >> >> > > >> >> >Proposed ECRIT Agenda: > >> >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >> >1) Emergency Call Routing Requirements > >> >> >2) Security and Threats Analysis > >> >> > > >> >> >_______________________________________________ > >> >> >Geopriv mailing list > >> >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >Ecrit mailing list > >> >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >> >> > > >> >> > >> > > >> > > >> > > > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 15:47:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLAw-0001rc-JF; Wed, 20 Apr 2005 15:47:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLAv-0001rB-Ew; Wed, 20 Apr 2005 15:47:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12353; Wed, 20 Apr 2005 15:47:52 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLMC-0006HB-3H; Wed, 20 Apr 2005 15:59:33 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3KJleh3011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 15:47:46 -0400 (EDT) Message-ID: <4266B1D7.2010506@cs.columbia.edu> Date: Wed, 20 Apr 2005 15:47:35 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <200504201807.OAA03774@ietf.org> In-Reply-To: <200504201807.OAA03774@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There are at least two separate sets of issues that depend on the architecture, and it seems dangerous to conflate the two: (First-person) I get my own location from a server. This makes address spoofing more difficult, with return routability. Drawback: If I'm behind a NAT, and the location server isn't, this works only if the IP address in the IP packet is used, not something in the query. VPNs should not be a big deal here. (Third-person) I ask for an address for an IP address. Address spoofing and VPN issues matter, possibly NAT issues (since the IP address I get may be a NAT address, given the typical circles of NAT hell in various networks.) I think first-person is much more palatable than third-person. Brian Rosen wrote: > "Routing" in this context is session (SIP) routing, as you suspected. > > The first hop (LIS to endpoint) is what we are discussing. > DHCP is not an L3+ protocol. Neither is LLDP-MED. > > The thread has discussed a number of problems with an L7 mechanism, but > laying them out: > > 1. You are subject to IP address spoofing (albeit you need to be able to get > the packets sent from the LIS to the IP address you are spoofing) > > 2. VPN or other tunnels may have been created before you run this protocol. > That will cause a failure; you need the location corresponding to the > original "outermost" IP address. > > 3. It is difficult to control the security (beyond IP spoofing) because you > don't have a generally good authentication mechanism. This is a bare phone, > or equivalent, during its boot phase. > > There are probably others as well. 2) is the real problem. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 16:00:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLMs-0003HC-Iv; Wed, 20 Apr 2005 16:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLMr-0003H1-UC; Wed, 20 Apr 2005 16:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13411; Wed, 20 Apr 2005 16:00:12 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLY9-0006fl-JV; Wed, 20 Apr 2005 16:11:53 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3KJwwh3011936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 15:58:59 -0400 (EDT) Message-ID: <4266B47D.9090006@cs.columbia.edu> Date: Wed, 20 Apr 2005 15:58:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <072C5B76F7CEAB488172C6F64B30B5E3113B4B@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3113B4B@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The basic problem for the end system is "Get the physically closest box that knows to tell me where I am" The core requirement is zero client configuration. L2 and DHCP mechanisms have the advantage that they usually are as close as you're going to get. You can make this indirect, i.e., have DHCP, PPP or L2 tell the client where to get its address. L2 (LLDP-MED) has the advantage that the physical structure ensures that I get the correct answer, without doing mappings. Mappings are always subject to being out-of-date or ambiguous or not have the right lookup-key information (e.g., real MAC address, lost on its way through a router or MAC-spoofing bridge). (This is even true for DHCP, where the DHCP server may have to derive from switch port tracing where a device is, which is subject to a variety of failure modes.) Michael Hammer (mhammer) wrote: > Brian, > > You describe the NENA phase i2 options, ESQK etc. Your routing element, I assume is doing session routing. > > The elements you detail are all (or would appear to be) application-layer entities and the signaling hops are likewise application-layer hops, not L2 hops (except for maybe the LIS-->EP). > > So, where is the L2 "dependency" coming from? > > I understand that a network node that is immediately adjacent to the endpoint is most likely to know where the other end of the link terminates, but does that force the delivery protocol aspects of this to be a L2 issue? > > Each of the myriad link types carry IP packets, no? And IP packets can carry an application packet, no? So, wouldn't the application-layer solution be the more general one? I thought that was in line with IETF principles. > > You are probably just laying out the options, not promoting a particular one. I would be interested in seeing what the champions of one approach or another have to say. (I did a search on LLDP-MED and drew a blank.) > > Mike > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 16:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLfG-0005I6-6S; Wed, 20 Apr 2005 16:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLfE-0005Hu-Gh; Wed, 20 Apr 2005 16:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14920; Wed, 20 Apr 2005 16:19:10 -0400 (EDT) Message-Id: <200504202019.QAA14920@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLqV-000775-Tg; Wed, 20 Apr 2005 16:30:52 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOLf4-0005cq-1s; Wed, 20 Apr 2005 15:19:02 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 16:18:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4266B1D7.2010506@cs.columbia.edu> Thread-Index: AcVF4dTLswGyAEJoQTa3WbwpXLxpmAAAX3Gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm having some off line discussions that lead me to the following: If you have a box that opens a VPN tunnel on the raw Internet connection that feeds a LAN that has endpoints, and passes ALL LAN traffic through the tunnel, you are hosed. The box has to be location aware in some way. This is because there is no way, L2 or L7, that you can get a packet to anything that knows about the location; the box is forcing everything through the tunnel. The box is physically between the uplink and the LAN, and you can't go around it. The box has to do something that lets you get at the right LIS. If the box supplies IP addresses (it's the DHCP server), then it only has to relay the location option. If the box doesn't supply addresses, it would have to run something that either the client could access, or something the DHCP server would access. We have no solutions. L7 doesn't help; the box has to do something that would allow you to get to the local LIS, with the boxe's public IP address. Softclients are much easier, because the system can get location before the tunnel is established. Tunnels downstream of the local infrastructure are problematic for L7, but not for L2. This is bad news. All the boxes have to change. If we have to change all the softclients for L7, is that a big enough reason to not use L7? Hmmm. I don't know enough about how the boxes work. To make DHCP work with the DHCP server in the corporate network, not in the box, the box has to pass the DHCP packets; they aren't IP packets. Does that mean it's always a DHCP relay? That would help. The boxes have to change, but if they are already doing DHCP relay, adding the location option would be the least amount of work. I keep hoping I've missed something here. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 20, 2005 3:48 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV WG'; > ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > There are at least two separate sets of issues that depend on the > architecture, and it seems dangerous to conflate the two: > > (First-person) I get my own location from a server. This makes address > spoofing more difficult, with return routability. Drawback: If I'm > behind a NAT, and the location server isn't, this works only if the IP > address in the IP packet is used, not something in the query. VPNs > should not be a big deal here. > > (Third-person) I ask for an address for an IP address. Address spoofing > and VPN issues matter, possibly NAT issues (since the IP address I get > may be a NAT address, given the typical circles of NAT hell in various > networks.) > > I think first-person is much more palatable than third-person. > > Brian Rosen wrote: > > "Routing" in this context is session (SIP) routing, as you suspected. > > > > The first hop (LIS to endpoint) is what we are discussing. > > DHCP is not an L3+ protocol. Neither is LLDP-MED. > > > > The thread has discussed a number of problems with an L7 mechanism, but > > laying them out: > > > > 1. You are subject to IP address spoofing (albeit you need to be able to > get > > the packets sent from the LIS to the IP address you are spoofing) > > > > 2. VPN or other tunnels may have been created before you run this > protocol. > > That will cause a failure; you need the location corresponding to the > > original "outermost" IP address. > > > > 3. It is difficult to control the security (beyond IP spoofing) because > you > > don't have a generally good authentication mechanism. This is a bare > phone, > > or equivalent, during its boot phase. > > > > There are probably others as well. 2) is the real problem. > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 16:42:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOM21-0000Zs-J5; Wed, 20 Apr 2005 16:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOM1z-0000Zj-TU; Wed, 20 Apr 2005 16:42:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17948; Wed, 20 Apr 2005 16:42:42 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOMDH-0007ul-1a; Wed, 20 Apr 2005 16:54:24 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3KKgYh3014262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 16:42:35 -0400 (EDT) Message-ID: <4266BEB5.8090009@cs.columbia.edu> Date: Wed, 20 Apr 2005 16:42:29 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <200504202019.j3KKJ8qt003546@cs.columbia.edu> In-Reply-To: <200504202019.j3KKJ8qt003546@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Hmmm. I don't know enough about how the boxes work. To make DHCP work with > the DHCP server in the corporate network, not in the box, the box has to > pass the DHCP packets; they aren't IP packets. Does that mean it's always a ^^^^^^^^^^^^^^^^^^^^^^^ They are normal IP packets, see RFC 951 (BOOTP description), running on port 67/68. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 16:57:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOMGA-0002Kd-Bw; Wed, 20 Apr 2005 16:57:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOMG6-0002Iq-5Z; Wed, 20 Apr 2005 16:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19622; Wed, 20 Apr 2005 16:57:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOMRN-0008Jx-A6; Wed, 20 Apr 2005 17:08:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2005 13:57:08 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3KKv5hu022390; Wed, 20 Apr 2005 13:57:05 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA03330; Wed, 20 Apr 2005 13:57:03 -0700 (PDT) Message-Id: <200504202057.NAA03330@malone.cisco.com> From: "Marc Linsner" To: "'Henning Schulzrinne'" Date: Wed, 20 Apr 2005 16:56:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4266B47D.9090006@cs.columbia.edu> Thread-Index: AcVF4+TkkfpP1ft1RnGp8YBuSqvj8wABU5uA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ----note the subject change to reflect the topic------ In-line.... > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, April 20, 2005 3:59 PM > To: Michael Hammer (mhammer) > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of JointGEOPRIV/ECRIT > InterimMeeting > > The basic problem for the end system is > > "Get the physically closest box that knows to tell me where I am" > > The core requirement is zero client configuration. > > L2 and DHCP mechanisms have the advantage that they usually are as close > as you're going to get. You can make this indirect, i.e., have DHCP, PPP > or L2 tell the client where to get its address. > > L2 (LLDP-MED) has the advantage that the physical structure ensures that > I get the correct answer, without doing mappings. Mappings are always > subject to being out-of-date or ambiguous or not have the right > lookup-key information (e.g., real MAC address, lost on its way through > a router or MAC-spoofing bridge). (This is even true for DHCP, where the > DHCP server may have to derive from switch port tracing where a device > is, which is subject to a variety of failure modes.) I'm not sure what you mean here. Neither LLDP-MED nor RFC3825 depend on MAC address to associate a location. RFC3825 depends on the switch implementing the RAIO, which should be pretty safe from ambiguous. Certainly the wire map database could be corrupted due to patch cable changes, etc., but this would equally cause pain in either mechanism. I think I'm missing something. -Marc- snip...... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 17:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DON1O-0008Je-FX; Wed, 20 Apr 2005 17:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DON1N-0008J0-Dv; Wed, 20 Apr 2005 17:46:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24865; Wed, 20 Apr 2005 17:46:06 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DONCe-0001Lr-NC; Wed, 20 Apr 2005 17:57:49 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3KLjrh3017190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 17:45:54 -0400 (EDT) Message-ID: <4266CD8C.5040806@cs.columbia.edu> Date: Wed, 20 Apr 2005 17:45:48 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner References: <200504202057.NAA03330@malone.cisco.com> In-Reply-To: <200504202057.NAA03330@malone.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] Re: L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > I'm not sure what you mean here. Neither LLDP-MED nor RFC3825 depend on MAC > address to associate a location. RFC3825 depends on the switch implementing > the RAIO, which should be pretty safe from ambiguous. Certainly the wire > map database could be corrupted due to patch cable changes, etc., but this > would equally cause pain in either mechanism. > > I think I'm missing something. Trying to be brief caused confusion. Let me try to be a bit more clear: I see four levels of indirection, in increasing order: (Direct) The wire or ether tells the client device where it is -> LLDP-MED, 802.11 beacons, BlueTooth beacons, etc. Little room for confusion. No need for addresses of any sort. Fewer privacy issues since the client never identifies itself in any traceable way. (L2-interface/circuit) Server maps some circuit identifier to a location, based on a mapping (RAIO). No MAC address needed, but probably mainly applicable to broadband home networks rather than typical corporate networks. (L2-MAC) The server obtains a MAC address from the client, and then uses various bridge-MIB tracing techniques to find out which port the client is connected to, by checking where the MAC address has been seen. This is subject to some failure scenarios and the problem I mentioned obliquely earlier. (L3) The server gets an IP address and somehow knows the client location. Note that I said "server" above - this could be a DHCP server, but doesn't have to be. Obviously, a DHCP server has the advantage that the client knows how to find it. Also, I don't see the problem with DSL-specific mechanisms, as long as only DSL modems need to know this protocol and all of them implement it. They'd re-export this information via DHCP, for example, to their locally attached devices. Phones and PCs would not even know this mechanism existed. > > -Marc- > > snip...... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 17:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONC1-00020u-4H; Wed, 20 Apr 2005 17:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONBz-00020m-D9; Wed, 20 Apr 2005 17:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26285; Wed, 20 Apr 2005 17:57:05 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DONNH-0001kM-J0; Wed, 20 Apr 2005 18:08:48 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3KLum211521; Wed, 20 Apr 2005 16:56:48 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 07:55:28 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , peter_blatherwick@mitel.com Date: Thu, 21 Apr 2005 07:55:28 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1957218158==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1957218158== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C545F3.A9EA0886" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C545F3.A9EA0886 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that there is one other argument that also lends itself to the returning of the PIDF-LO rather than a layer 2 alternative, and that is = that the contents of PIDF-LO are very likely to change, largely with things = being added to them. To support these changes in PIDF-LO is relatively easy, because XML is by its very nature extensible. It would be difficult, = and I would argue completely undesirable to have to change myriad of layer 2 protocols to support a new attribute that has been added to PIDF-LO. = Case in point is the provided-by parameter that is already there, another = example would be complex shape definitions, and also the signatures that Brian describes below. The problems that I see with the current layer 2 implementation are = also that they are essentially clones of one another with regards to what information is conveyed, so if it is insufficient in one, or plain = simply wrong (and I am not saying that it is wrong), then the task to fix it = is large. -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Wednesday, 20 April 2005 11:54 PM To: peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Andrew Newton' Subject: RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim = Meeting There turns out to be a large set of issues around this problem, which = I fear is leading to Balkanization. There are two really important = problems we need to solve. One fundamental problem is that every client needs to implement every possible LI transfer mechanism that its environment could provide. We have DHCP. You guys are working on LLDP-MED. The DSL guys reject = both of these and want a something else. Every phone has to implement every protocol. There are some who have observed that the mechanisms at hand are L2 specific. They claim as long as you have an L2 specific mechanism, you = need one or more for each L2. To get out of that, they propose that we use = an L7 mechanism (think some version of HTTP, although that might not fly). = They would say, lets do that once, and every L2 can use it. The problem is = that you then have to deal with the security issues of an L7 mechanism, and = in particular, you have to use IP address as the "key" for what location = to return. If you can spoof IP address, you can get someone else's = location. =20 Those advocating L7 mechanisms claim that the mechanism would only be implemented within a domain, and the domain would have to take = anti-spoofing steps. They note that the mechanism would need at least a complete = round trip, and probably more than one, so spoofing requires the ability to intercept packets not addressed to the attacker. The returned data = could be precisely a PIDF-LO. Then on top of that, we turn out to need some more security, especially = for emergency calls. We need to prevent forged locations. That means we = need to sign the PIDF-LO. If you get location via DHCP, or LLDP-MED, and = the endpoint constructs a PIDF-LO from that, how do we construct a = signature from the entity that actually determined location? Brian ________________________________________ From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf Of peter_blatherwick@mitel.com Sent: Wednesday, April 20, 2005 9:30 AM To: Andrew Newton Cc: GEOPRIV WG; ecrit@ietf.org Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim = Meeting Hi Andrew, lists, =A0=20 I'd like to better understand the meaning of the following agenda = items:=20 =A0 "=20 =A0 2) Properties of network elements in transferring LI from layer 2=20 =A0upward to PIDF-LO. =A03) Proposed enhancements to PIDF-LO to support #2. =A0"=20 Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions? =A0=20 Reason I'm asking is I am deeply involved in a layer 2 approach which = would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to. =A0The work is going on in TIA = and is called Link Layer Discovery Protocol - Media Endpoint Discovery = (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems. =A0In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). =A0We see this method of delivery as a non-competing = alternative to the DHCP-based approach, with the same end result to the overall ECS = system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios. =A0(The DHCP-based = method has advantages in different scenarios.) =A0 I am Editor of thi s document, = and it is now in ballot process in TIA (more or less equivalent to Last Call = in IETF). =A0=20 Sorry, I expect I am suffering lack of context here, since I only = joined the list relatively recently. =A0=20 BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Last = Call and in the RFC Editor's queue? =A0It seemed to have been settled on the = list, and waiting on AD action.=20 -- Peter Blatherwick=20 Andrew Newton =20 Sent by: geopriv-bounces@ietf.org=20 13.04.05 16:34=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of Joint = GEOPRIV/ECRIT Interim Meeting The GEOPRIV and ECRIT working groups will be holding a joint interim=20 meeting. =A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting =A0 =A0 =A0 When: 2005 May 16 08:30-17:30 =A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 =A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 =A0 =A0 =A0Where: Columbia University =A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science =A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. =A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) =A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html =A0 =A0 =A0 Also: WiFi provided. =A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. =A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html =A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. Proposed GEOPRIV Agenda: =A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in = HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2=20 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: =A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ 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 ------_=_NextPart_001_01C545F3.A9EA0886 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim = Meeting

I think that there is one other argument that also = lends itself to the returning of the PIDF-LO rather than a layer 2 = alternative, and that is that the contents of PIDF-LO are very likely = to change, largely with things being added to them. To support these = changes in PIDF-LO is relatively easy, because XML is by its very = nature extensible. It would be difficult, and I would argue completely = undesirable to have to change myriad of layer 2 protocols to support a = new attribute that has been added to PIDF-LO. Case in point is the = provided-by parameter that is already there, another example would be = complex shape definitions, and also the signatures that Brian describes = below.

The problems that I see with the current layer 2 = implementation are also that they are essentially clones of one another = with regards to what information is conveyed, so if it is insufficient = in one, or plain simply wrong (and I am not saying that it is wrong), = then the task to fix it is large.

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Wednesday, 20 April 2005 11:54 PM
To: peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Andrew = Newton'
Subject: RE: [Geopriv] Announcement of Joint = GEOPRIV/ECRIT Interim Meeting


There turns out to be a large set of issues around = this problem, which I fear is leading to Balkanization.  There are = two really important problems we need to solve.

One fundamental problem is that every client needs to = implement every possible LI transfer mechanism that its environment = could provide.

We have DHCP.  You guys are working on = LLDP-MED.   The DSL guys reject both
of these and want a something else.  Every = phone has to implement every protocol.

There are some who have observed that the mechanisms = at hand are L2 specific.  They claim as long as you have an L2 = specific mechanism, you need one or more for each L2.  To get out = of that, they propose that we use an L7 mechanism (think some version = of HTTP, although that might not fly).  They would say, lets do = that once, and every L2 can use it.  The problem is that you then = have to deal with the security issues of an L7 mechanism, and in = particular, you have to use IP address as the "key" for what location = to return.  If you can spoof IP address, you can get someone = else's location. 

Those advocating L7 mechanisms claim that the = mechanism would only be implemented within a domain, and the domain = would have to take anti-spoofing steps.  They note that the = mechanism would need at least a complete round trip, and probably more = than one, so spoofing requires the ability to

intercept packets not addressed to the = attacker.   The returned data could
be precisely a PIDF-LO.

Then on top of that, we turn out to need some more = security, especially for emergency calls.  We need to prevent = forged locations.  That means we need to sign the PIDF-LO.  = If you get location via DHCP, or LLDP-MED, and the endpoint constructs = a PIDF-LO from that, how do we construct a signature from the entity = that actually determined location?

Brian


________________________________________
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ] On Behalf Of peter_blatherwick@mitel.com
Sent: Wednesday, April 20, 2005 9:30 AM
To: Andrew Newton
Cc: GEOPRIV WG; ecrit@ietf.org
Subject: Re: [Geopriv] Announcement of Joint = GEOPRIV/ECRIT Interim Meeting


Hi Andrew, lists, =A0

I'd like to better understand the meaning of the = following agenda items:
=A0 "
=A0 2) Properties of network elements in = transferring LI from layer 2
=A0upward to PIDF-LO.
=A03) Proposed enhancements to PIDF-LO to support = #2.
=A0"

Is there a summary of what these really mean, or = examples of what the outcome could be in terms of protocol or layer = interactions? =A0

Reason I'm asking is I am deeply involved in a layer = 2 approach which would be able to deliver location information to = endpoints from the L2 LAN infrastructure they are connected to. =A0The = work is going on in TIA and is called Link Layer Discovery Protocol - = Media Endpoint Discovery (LLDP-MED), which is an extension of IEEE = 802.1AB, specific to VoIP systems. =A0In LLDP-MED, among several other = things, we have specified ways to pass equivalent data to the DHCP = coordinate-based LCI (RFC 3825) and civic location LCI = (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). = =A0We see this method of delivery as a non-competing alternative to the = DHCP-based approach, with the same end result to the overall ECS system = (the endpoint receives the exact same data), which has some advantages = particularly in enterprise deployment scenarios. =A0(The DHCP-based = method has advantages in different scenarios.) =A0 I am Editor of thi s = document, and it is now in ballot process in TIA (more or less = equivalent to Last Call in IETF). =A0

Sorry, I expect I am suffering lack of context here, = since I only joined the list relatively recently. =A0

BTW, what is the state of geopriv-dhcp-civil? =A0Is = it now past Last Call and in the RFC Editor's queue? =A0It seemed to = have been settled on the list, and waiting on AD action.

-- Peter Blatherwick




Andrew Newton <andy@hxr.us>
Sent by: geopriv-bounces@ietf.org
13.04.05 16:34
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG = <geopriv@ietf.org>
=A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] = Announcement of Joint GEOPRIV/ECRIT Interim Meeting




The GEOPRIV and ECRIT working groups will be holding = a joint interim
meeting.

=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT = meeting
=A0 =A0 =A0 When: 2005 May 16 08:30-17:30
=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 = 08:30-17:30
=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 = 08:30-17:30
=A0 =A0 =A0Where: Columbia University
=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer = Science
=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science = Bldg.
=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close = to 120th St.)
=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027
Directions: http://www.cs.columbia.edu/directions.html
=A0 =A0 =A0 Also: WiFi provided.
=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be = provided.
=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
=A0 =A0 =A0 =A0 =A0 =A0 Early bookings = recommended.

Proposed GEOPRIV Agenda:
=A0 2005 May 16 08:30-17:30, 2005 May 17 = 08:30-12:30
1) Role of HTTP as a transfer protocol for PIDF-LO = vs. the use of LI in
HTTP/HTML for web browsing.
2) Properties of network elements in transferring LI = from layer 2
upward to PIDF-LO.
3) Proposed enhancements to PIDF-LO to support = #2.

Proposed ECRIT Agenda:
=A0 2005 May 17 13:30-17:30, 2005 May 18 = 08:30-17:30
1) Emergency Call Routing Requirements
2) Security and Threats Analysis

_______________________________________________
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

------_=_NextPart_001_01C545F3.A9EA0886-- --===============1957218158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1957218158==-- From ecrit-bounces@ietf.org Wed Apr 20 18:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONQM-0003SX-6T; Wed, 20 Apr 2005 18:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONQJ-0003RW-JJ; Wed, 20 Apr 2005 18:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27979; Wed, 20 Apr 2005 18:11:53 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DONbb-00024a-Bl; Wed, 20 Apr 2005 18:23:36 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3KM6UN13451; Wed, 20 Apr 2005 17:06:30 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 08:05:40 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Michael Hammer (mhammer)'" , peter_blatherwick@mitel.com Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Thu, 21 Apr 2005 08:05:39 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 97901e96c4dacf0263335ebc3a004b57 Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0309320674==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0309320674== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C545F5.16A12210" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C545F5.16A12210 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zrc2s0jx.nortelnetworks.com id j3KM6UN13451 Content-Transfer-Encoding: quoted-printable Hmmmm!!! I am not sure that I agree your statement that the key passed to external would be the IP address of the client. It could be, but I would most certainly not advocate that.=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 2:13 AM To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting The basic picture is: LIS ---> endpoint ---> routing element ---> psap The LIS knows where the endpoint is. The endpoint gets location from the LIS The endpoint includes location on the emergency call The routing element uses location to route the call to the right PSAP The PSAP gets the call, and the location. The discussion is, how does the endpoint get location from the LIS? DHCP = is one answer. LLDP-MED is another. A proposed L7 mechanism is another. To be sure, there are folks who want to make the picture: LIS --> endpoint --> routing element ---> psap ^ | | | | | +------------------------+ | | | +------------------------------------------+ The LIS gives the endpoint a "key" The endpoint includes the key in the emergency call The routing element gets the key and exchanges it for location at the LIS The psap gets the key and exchanges it for location at the LIS The key could be an IP address. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 12:00 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > InterimMeeting >=20 > I still get the feeling that "delivery" is being used in two different > contexts: >=20 > (1) (2) > Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) >=20 > How can "delivery" be L2 dependent, when it must reach a PSAP many=20 > hops away? Color me confused. >=20 > Mike >=20 >=20 > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint=20 > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL=20 > >provider. The domain is then that of the DSL vendor. Your phone asks=20 > >for its location from the server in the DSL domain. It would be=20 > >given the location corresponding to the IP address of the request. =20 > >Note that this would be pretty good for the requested case, even in=20 > >the presence of a NATed local area network in your home. The phone=20 > >would do this on boot, before any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. I'm=20 > >skeptical we can do that because of the security issues. When you=20 > >make the delivery mechanism L2 dependent, you can control the=20 > >possible attacks to a finer grain than the L7 local domain. > > > >Please keep in mind that some of the folks wishing to use the L7=20 > >mechanism don't really want to just return location to the endpoint;=20 > >they want to retain the location and give it out to authorized=20 > >entities upon presentation of the IP address of the endpoint. That=20 > >is a business decision. They can charge for such a service. I think=20 > >the privacy implications of that are dicey, but the reality is that's=20 > >the model that will probably be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would=20 > >> seem that location delivery would need to be cross-domain. The=20 > >> E911 PSAP will not always be the same domain as the roaming=20 > >> endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the=20 > >> fact that L2 is supposed to be a single physical hop at most=20 > >> between the end- user terminal and an adjacent location-determining=20 > >> network node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to=20 > >> rely on location information, a general purpose delivery mechanism=20 > >> will provide consistency and generality that is so often sought in=20 > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer=20 > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local,=20 > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem,=20 > >> >which I fear is leading to Balkanization. There are two really=20 > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement=20 > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are=20 > >> >L2 specific. They claim as long as you have an L2 specific=20 > >> >mechanism, you need one or more for each L2. To get out of that,=20 > >> >they propose that we use an L7 mechanism (think some version of=20 > >> >HTTP, although that might not fly). They would say, lets do that=20 > >> >once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the=20 > >> >security issues of an L7 mechanism, and in particular, you have to=20 > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take=20 > >> >anti-spoofing steps. They note that the mechanism would need at=20 > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security,=20 > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via=20 > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from=20 > >> >that, how do we construct a signature from the entity that=20 > >> >actually determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]=20 > >> >On Behalf Of peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> >=A0 " > >> >=A0 2) Properties of network elements in transferring LI from layer= =20 > >> >2 > >> >=A0upward to PIDF-LO. > >> >=A03) Proposed enhancements to PIDF-LO to support #2. > >> >=A0" > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from=20 > >> >the L2 LAN infrastructure they are connected to. =A0The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20 > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. =A0In LLDP-MED, among several other things, we hav= e=20 > >> >specified ways to pass equivalent data to the DHCP=20 > >> >coordinate-based LCI (RFC 3825) and civic location LCI=20 > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS=20 > >> >system (the endpoint receives the exact same data), which has some=20 > >> >advantages particularly in enterprise deployment scenarios. =A0(The= =20 > >> >DHCP-based method has advantages in different scenarios.) =A0 I am=20 > >> >Editor of thi s document, and it is now in ballot process in TIA=20 > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only=20 > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? =A0Is it now past Las= t=20 > >> >Call and in the RFC Editor's queue? =A0It seemed to have been=20 > >> >settled on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0GEOPRIV WG > >> >=A0 =A0 =A0 =A0 cc: > >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Geopriv] Announcement of J= oint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> >=A0 =A0 =A0 What: Interim GEOPRIV/ECRIT meeting > >> >=A0 =A0 =A0 When: 2005 May 16 08:30-17:30 > >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 17 08:30-17:30 > >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May 18 08:30-17:30 > >> >=A0 =A0 =A0Where: Columbia University > >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of Computer Science > >> >=A0 =A0 =A0 =A0 =A0 =A0 450 Computer Science Bldg. > >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 Amsterdam Avenue (close to 120th St.) > >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> >=A0 =A0 =A0 Also: WiFi provided. > >> >=A0 =A0 =A0 =A0 =A0 =A0 Teleconference to be provided. > >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> >=A0 =A0 =A0 =A0 =A0 =A0 Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> >=A0 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2=20 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> >=A0 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C545F5.16A12210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT = InterimMeeting

Hmmmm!!!

I am not sure that I agree your statement that the = key passed to external would be the IP address of the client. It could = be, but I would most certainly not advocate that.

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Thursday, 21 April 2005 2:13 AM
To: 'Michael Hammer (mhammer)'; = peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; ecrit@ietf.org
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of = Joint GEOPRIV/ECRIT InterimMeeting


The basic picture is:

LIS ---> endpoint ---> routing element ---> = psap

The LIS knows where the endpoint is.
The endpoint gets location from the LIS
The endpoint includes location on the emergency = call
The routing element uses location to route the call = to the right PSAP The PSAP gets the call, and the location.

The discussion is, how does the endpoint get location = from the LIS? DHCP is one answer.  LLDP-MED is another.  A = proposed L7 mechanism is another.


To be sure, there are folks who want to make the = picture:

LIS --> endpoint --> routing element ---> = psap
 ^         &n= bsp;           &n= bsp;  = |            = ;     |
 |         &n= bsp;           &n= bsp;  = |            = ;     |
 +------------------------+     &= nbsp;           = |
 |         &n= bsp;           &n= bsp;           &n= bsp;        |
 +------------------------------------------+

The LIS gives the endpoint a "key"
The endpoint includes the key in the emergency = call
The routing element gets the key and exchanges it = for location at the LIS The psap gets the key and exchanges it for = location at the LIS

The key could be an IP address.

Brian


> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Wednesday, April 20, 2005 12:00 PM
> To: Brian Rosen; = peter_blatherwick@mitel.com
> Cc: GEOPRIV WG; ecrit@ietf.org
> Subject: RE: [Ecrit] RE: [Geopriv] Announcement = of Joint GEOPRIV/ECRIT
> InterimMeeting
>
> I still get the feeling that = "delivery" is being used in two different
> contexts:
>
>          = ;   = (1)           &nb= sp;         (2)
> Local node---?---->endpoint-----/many = hops/----->PSAP
>          = ; ---------------------/many hops/----->
>          = ;            = ;      (2)
>
> How can "delivery" be L2 dependent, = when it must reach a PSAP many
> hops away? Color me confused.
>
> Mike
>
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: Wednesday, April 20, 2005 10:47 = AM
> >To: Michael Hammer (mhammer); = peter_blatherwick@mitel.com
> >Cc: 'GEOPRIV WG'; ecrit@ietf.org
> >Subject: RE: [Ecrit] RE: [Geopriv] = Announcement of Joint
> >GEOPRIV/ECRIT InterimMeeting
> >
> >The idea is that, say, you are in your = home, served by a DSL
> >provider. The domain is then that of the = DSL vendor.  Your phone asks
> >for its location from the server in the DSL = domain.  It would be
> >given the location corresponding to the IP = address of the request. 
> >Note that this would be pretty good for the = requested case, even in
> >the presence of a NATed local area network = in your home.  The phone
> >would do this on boot, before any VPN = tunnels were established.
> >
> >I get the idea that a single delivery = mechanism is desirable. I'm
> >skeptical we can do that because of the = security issues. When you
> >make the delivery mechanism L2 dependent, = you can control the
> >possible attacks to a finer grain than the = L7 local domain.
> >
> >Please keep in mind that some of the folks = wishing to use the L7
> >mechanism don't really want to just return = location to the endpoint;
> >they want to retain the location and give = it out to authorized
> >entities upon presentation of the IP = address of the endpoint.  That
> >is a business decision.  They can = charge for such a service.  I think
> >the privacy implications of that are dicey, = but the reality is that's
> >the model that will probably be implemented = if we do this.
> >
> >Brian
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> >> Sent: Wednesday, April 20, 2005 10:14 = AM
> >> To: Brian Rosen; = peter_blatherwick@mitel.com
> >> Cc: GEOPRIV WG; ecrit@ietf.org
> >> Subject: RE: [Ecrit] RE: [Geopriv] = Announcement of Joint
> >GEOPRIV/ECRIT
> >> InterimMeeting
> >>
> >> Brian,
> >>
> >> Could you clarify the domain = statement.  Given nomadicity, it would
> >> seem that location delivery would need = to be cross-domain.  The
> >> E911 PSAP will not always be the same = domain as the roaming
> >> endpoint.
> >>
> >> My impression is that Location = discovery is a L2 issue, tied to the
> >> fact that L2 is supposed to be a = single physical hop at most
> >> between the end- user terminal and an = adjacent location-determining
> >> network node.  (Of course those = trying to make L2 protocols a
> >replacement for
> >> IP sort of screw this assumption = up.)
> >>
> >> The location delivery mechanism is an = application-layer or
> >L7 service.
> >> The argument there is that since = multiple applications will need to
> >> rely on location information, a = general purpose delivery mechanism
> >> will provide consistency and = generality that is so often sought in
> >> IETF work.  Security can be = built-in to the chosen delivery
> >mechanism.
> >> Note, that delivery could be a choice = of an existing transfer
> >> mechanism.  This does not = preclude other L7 protocols from
> >defining a
> >> place in their messages that could = also carry location information.
> >>
> >> So, I believe:
> >> Location discovery is local, with = associated security being local,
> >> Location delivery is global, with = associated security being global.
> >>
> >> The real issues are making those = happen.
> >>
> >> Mike
> >>
> >> >-----Original Message-----
> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On
> >> >Behalf Of Brian Rosen
> >> >Sent: Wednesday, April 20, 2005 = 9:54 AM
> >> >To: = peter_blatherwick@mitel.com
> >> >Cc: 'GEOPRIV WG'; = ecrit@ietf.org
> >> >Subject: [Ecrit] RE: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT
> >> >InterimMeeting
> >> >
> >> >There turns out to be a large set = of issues around this problem,
> >> >which I fear is leading to = Balkanization.  There are two really
> >> >important problems we need to = solve.
> >> >
> >> >One fundamental problem is that = every client needs to
> >implement every
> >> >possible LI transfer mechanism = that its environment could provide.
> >> >
> >> >We have DHCP.  You guys are = working on LLDP-MED.   The DSL
> >> >guys reject both
> >> >of these and want a something = else.  Every phone has to implement
> >> >every protocol.
> >> >
> >> >There are some who have observed = that the mechanisms at hand are
> >> >L2 specific.  They claim as = long as you have an L2 specific
> >> >mechanism, you need one or more = for each L2.  To get out of that,
> >> >they propose that we use an L7 = mechanism (think some version of
> >> >HTTP, although that might not = fly).  They would say, lets do that
> >> >once,
> >and every L2
> >> >can use it.  The problem is = that you then have to deal with the
> >> >security issues of an L7 = mechanism, and in particular, you have to
> >> >use IP address as the = "key" for what location to return.
> >If you can
> >> >spoof IP address, you can get = someone else's location.
> >> >
> >> >Those advocating L7 mechanisms = claim that the mechanism
> >would only be
> >> >implemented within a domain, and = the domain would have to take
> >> >anti-spoofing steps.  They = note that the mechanism would need at
> >> >least a complete round trip, and = probably more than one, so
> >spoofing
> >> >requires the ability to
> >> >intercept packets not addressed to = the attacker.   The
> >> >returned data could
> >> >be precisely a PIDF-LO.
> >> >
> >> >Then on top of that, we turn out = to need some more security,
> >> >especially for emergency = calls.  We need to prevent forged
> >locations.
> >> >That means we need to sign the = PIDF-LO.  If you get location via
> >> >DHCP, or LLDP-MED, and the = endpoint constructs a PIDF-LO from
> >> >that, how do we construct a = signature from the entity that
> >> >actually determined = location?
> >> >
> >> >Brian
> >> >
> >> >
> >> = >________________________________________
> >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ]
> >> >On Behalf Of = peter_blatherwick@mitel.com
> >> >Sent: Wednesday, April 20, 2005 = 9:30 AM
> >> >To: Andrew Newton
> >> >Cc: GEOPRIV WG; = ecrit@ietf.org
> >> >Subject: Re: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT Interim
> >> >Meeting
> >> >
> >> >
> >> >Hi Andrew, lists,
> >> >
> >> >I'd like to better understand the = meaning of the following agenda
> >> >items:
> >> >=A0 "
> >> >=A0 2) Properties of network = elements in transferring LI from layer
> >> >2
> >> >=A0upward to PIDF-LO.
> >> >=A03) Proposed enhancements to = PIDF-LO to support #2.
> >> >=A0"
> >> >
> >> >Is there a summary of what these = really mean, or examples
> >of what the
> >> >outcome could be in terms of = protocol or layer interactions?
> >> >
> >> >Reason I'm asking is I am deeply = involved in a layer 2
> >approach which
> >> >would be able to deliver location = information to endpoints from
> >> >the L2 LAN infrastructure they are = connected to. =A0The work is
> >going on in
> >> >TIA and is called Link Layer = Discovery Protocol - Media Endpoint
> >> >Discovery (LLDP-MED), which is an = extension of IEEE
> >802.1AB, specific
> >> >to VoIP systems. =A0In LLDP-MED, = among several other things, we have
> >> >specified ways to pass equivalent = data to the DHCP
> >> >coordinate-based LCI (RFC 3825) = and civic location LCI
> >> >(draft-ietf-geopriv-dhcp-civil-05, = in Last Call process I
> >believe).
> >> >We see this method of delivery as = a non-competing
> >alternative to the
> >> >DHCP-based approach, with the same = end result to the overall ECS
> >> >system (the endpoint receives the = exact same data), which has some
> >> >advantages particularly in = enterprise deployment scenarios. =A0(The
> >> >DHCP-based method has advantages = in different scenarios.) =A0 I am
> >> >Editor of thi s document, and it = is now in ballot process in TIA
> >> >(more or less equivalent to Last = Call in IETF).
> >> >
> >> >Sorry, I expect I am suffering = lack of context here, since I only
> >> >joined the list relatively = recently.
> >> >
> >> >BTW, what is the state of = geopriv-dhcp-civil? =A0Is it now past Last
> >> >Call and in the RFC Editor's = queue? =A0It seemed to have been
> >> >settled on the list, and waiting = on AD action.
> >> >
> >> >-- Peter Blatherwick
> >> >
> >> >
> >> >
> >> >
> >> >Andrew Newton = <andy@hxr.us>
> >> >Sent by: = geopriv-bounces@ietf.org
> >> >13.04.05 16:34
> >> >
> >> >=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 = =A0GEOPRIV WG <geopriv@ietf.org>
> >> >=A0 =A0 =A0 =A0 cc:
> >> >=A0 =A0 =A0 =A0 Subject: =A0 =A0 = =A0 =A0[Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT
> >> >Interim Meeting
> >> >
> >> >
> >> >
> >> >
> >> >The GEOPRIV and ECRIT working = groups will be holding a
> >joint interim
> >> >meeting.
> >> >
> >> >=A0 =A0 =A0 What: Interim = GEOPRIV/ECRIT meeting
> >> >=A0 =A0 =A0 When: 2005 May 16 = 08:30-17:30
> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May = 17 08:30-17:30
> >> >=A0 =A0 =A0 =A0 =A0 =A0 2005 May = 18 08:30-17:30
> >> >=A0 =A0 =A0Where: Columbia = University
> >> >=A0 =A0 =A0 =A0 =A0 =A0 Dept. of = Computer Science
> >> >=A0 =A0 =A0 =A0 =A0 =A0 450 = Computer Science Bldg.
> >> >=A0 =A0 =A0 =A0 =A0 =A0 1214 = Amsterdam Avenue (close to 120th St.)
> >> >=A0 =A0 =A0 =A0 =A0 =A0 New York, = NY 10027
> >> >Directions: http://www.cs.columbia.edu/directions.html
> >> >=A0 =A0 =A0 Also: WiFi = provided.
> >> >=A0 =A0 =A0 =A0 =A0 =A0 = Teleconference to be provided.
> >> >=A0 =A0 =A0Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
> >> >=A0 =A0 =A0 =A0 =A0 =A0 Early = bookings recommended.
> >> >
> >> >Proposed GEOPRIV Agenda:
> >> >=A0 2005 May 16 08:30-17:30, 2005 = May 17 08:30-12:30
> >> >1) Role of HTTP as a transfer = protocol for PIDF-LO vs. the
> >use of LI
> >> >in HTTP/HTML for web = browsing.
> >> >2) Properties of network elements = in transferring LI from layer 2
> >> >upward to PIDF-LO.
> >> >3) Proposed enhancements to = PIDF-LO to support #2.
> >> >
> >> >Proposed ECRIT Agenda:
> >> >=A0 2005 May 17 13:30-17:30, 2005 = May 18 08:30-17:30
> >> >1) Emergency Call Routing = Requirements
> >> >2) Security and Threats = Analysis
> >> >
> >> = >_______________________________________________
> >> >Geopriv mailing list
> >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
> >> >
> >> >
> >> >
> >> >
> >> = >_______________________________________________
> >> >Ecrit mailing list
> >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
> >> >
> >>
> >
> >
>




_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C545F5.16A12210-- --===============0309320674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0309320674==-- From ecrit-bounces@ietf.org Wed Apr 20 19:13:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOONh-0002Zo-JE; Wed, 20 Apr 2005 19:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOONg-0002Zg-HT; Wed, 20 Apr 2005 19:13:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04203; Wed, 20 Apr 2005 19:13:13 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOOYx-0003hw-Ti; Wed, 20 Apr 2005 19:24:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2005 19:24:12 -0400 X-IronPort-AV: i="3.92,118,1112587200"; d="scan'208"; a="45461474:sNHT29840648" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3KND2dr009581; Wed, 20 Apr 2005 19:13:02 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 19:13:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 19:13:00 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3113BD0@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Thread-Index: AcVF47FTZ5vdqlAKRYOS7WA4dGCh1QAGErGA From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 20 Apr 2005 23:13:01.0888 (UTC) FILETIME=[7FD93C00:01C545FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, Thanks. This is the sort of detail that I was hoping to stir up. =20 So, the first hop network needs to be the source of location information. In my house that is my home network/router, which would seem to imply that it needs to acquire location into it somehow. The router in turn pretends to be a PC and talks through the cable/DSL modem to an upstream server to get IP addresses and such. Will my home router store and relay location information in the access SP? This assumes that the location is provisioned into the cable/DSL system. If I also remember some security mechanisms correctly, DHCP-spoofing is prevented by not allowing such traffic to go very far. I wouldn't think that DHCP gets put into VPN tunnels, but I could be wrong. Seems like there are several interfaces X protocol choices to work out here. Thanks, Mike >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Wednesday, April 20, 2005 3:59 PM >To: Michael Hammer (mhammer) >Cc: Brian Rosen; peter_blatherwick@mitel.com; GEOPRIV WG;=20 >ecrit@ietf.org >Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint=20 >GEOPRIV/ECRIT InterimMeeting > >The basic problem for the end system is > >"Get the physically closest box that knows to tell me where I am" > >The core requirement is zero client configuration. > >L2 and DHCP mechanisms have the advantage that they usually=20 >are as close as you're going to get. You can make this=20 >indirect, i.e., have DHCP, PPP or L2 tell the client where to=20 >get its address. Or where to go to get location information via a L7 protocol? > >L2 (LLDP-MED) has the advantage that the physical structure=20 >ensures that I get the correct answer, without doing mappings.=20 >Mappings are always subject to being out-of-date or ambiguous=20 >or not have the right lookup-key information (e.g., real MAC=20 >address, lost on its way through a router or MAC-spoofing=20 >bridge). (This is even true for DHCP, where the DHCP server=20 >may have to derive from switch port tracing where a device is,=20 >which is subject to a variety of failure modes.) > > >Michael Hammer (mhammer) wrote: >> Brian, >>=20 >> You describe the NENA phase i2 options, ESQK etc. Your=20 >routing element, I assume is doing session routing. >>=20 >> The elements you detail are all (or would appear to be)=20 >application-layer entities and the signaling hops are likewise=20 >application-layer hops, not L2 hops (except for maybe the LIS-->EP).=20 >>=20 >> So, where is the L2 "dependency" coming from? >>=20 >> I understand that a network node that is immediately=20 >adjacent to the endpoint is most likely to know where the=20 >other end of the link terminates, but does that force the=20 >delivery protocol aspects of this to be a L2 issue? >>=20 >> Each of the myriad link types carry IP packets, no? And IP=20 >packets can carry an application packet, no? So, wouldn't the=20 >application-layer solution be the more general one? I thought=20 >that was in line with IETF principles. >>=20 >> You are probably just laying out the options, not promoting a=20 >> particular one. I would be interested in seeing what the=20 >champions of=20 >> one approach or another have to say. (I did a search on=20 >LLDP-MED and=20 >> drew a blank.) >>=20 >> Mike >>=20 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 19:17:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOORL-0003Gk-8G; Wed, 20 Apr 2005 19:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOORJ-0003GR-DN; Wed, 20 Apr 2005 19:17:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04681; Wed, 20 Apr 2005 19:16:58 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOOcb-0003sO-UI; Wed, 20 Apr 2005 19:28:43 -0400 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/nLZJtMPeDA6+NyX3gBoTMrvOmtvPBUtI@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3KNGsh3021738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 19:16:55 -0400 (EDT) Message-ID: <4266E2F5.90103@cs.columbia.edu> Date: Wed, 20 Apr 2005 19:17:09 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Winterbottom Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James Winterbottom wrote: > I think that there is one other argument that also lends itself to the > returning of the PIDF-LO rather than a layer 2 alternative, and that is > that the contents of PIDF-LO are very likely to change, largely with > things being added to them. To support these changes in PIDF-LO is > relatively easy, because XML is by its very nature extensible. It would > be difficult, and I would argue completely undesirable to have to change > myriad of layer 2 protocols to support a new attribute that has been This is bogus. We have essentially two layer-2 mechanisms that inherit the same name space. Registering and defining a new XML tag is no easier (or no more difficult) than registering a new DHCP numeric tag. Just because it's XML doesn't mean that magically all applications understand it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 19:31:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOOex-0000Ii-0B; Wed, 20 Apr 2005 19:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOOet-0000Ia-TP; Wed, 20 Apr 2005 19:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08021; Wed, 20 Apr 2005 19:31:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOOqC-0004ns-JI; Wed, 20 Apr 2005 19:42:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2005 16:30:53 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3KNUe2w026285; Wed, 20 Apr 2005 16:30:40 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA15780; Wed, 20 Apr 2005 16:30:38 -0700 (PDT) Message-Id: <200504202330.QAA15780@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" Date: Wed, 20 Apr 2005 19:30:29 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVF9F1ToH70Gp49QgyiGqson2KwngABX+Ew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.7 (+) X-Scan-Signature: d1330b60dd48fa5cb1958a0aa669d18b Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1549996348==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1549996348== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E7C_01C545DF.6C222DD0" This is a multi-part message in MIME format. ------=_NextPart_000_0E7C_01C545DF.6C222DD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ------note the subject change - it's an attempt to more accurately reflect the topic------ James, 1) Are not complex shape definitions associated with TOA technology which is associated with wireless? I don't remember anyone advocating the use of RFC3825 nor LLDP-MED for a complete wireless solution. If fact, I know that RFC3825 recommends using a yet-to-be-determined more exotic method for passing location information to a wireless client. 2) In the case of signing the pidf-lo, who is going to sign it when the data is user derived (either user keyed or on-board gps)? 3) There seems to be consensus that L1/L2 will, in all but user derived mechanisms, be involved in location determination at some level. Is it the case that you are advocating that the L1/L2 infrastructure build and sign a pidf-lo and forward to either the client or a L7 service somewhere in the network? Just attempting to understand... -Marc- _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, April 20, 2005 5:55 PM To: Brian Rosen; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I think that there is one other argument that also lends itself to the returning of the PIDF-LO rather than a layer 2 alternative, and that is that the contents of PIDF-LO are very likely to change, largely with things being added to them. To support these changes in PIDF-LO is relatively easy, because XML is by its very nature extensible. It would be difficult, and I would argue completely undesirable to have to change myriad of layer 2 protocols to support a new attribute that has been added to PIDF-LO. Case in point is the provided-by parameter that is already there, another example would be complex shape definitions, and also the signatures that Brian describes below. The problems that I see with the current layer 2 implementation are also that they are essentially clones of one another with regards to what information is conveyed, so if it is insufficient in one, or plain simply wrong (and I am not saying that it is wrong), then the task to fix it is large. -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 20 April 2005 11:54 PM To: peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Andrew Newton' Subject: RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting There turns out to be a large set of issues around this problem, which I fear is leading to Balkanization. There are two really important problems we need to solve. One fundamental problem is that every client needs to implement every possible LI transfer mechanism that its environment could provide. We have DHCP. You guys are working on LLDP-MED. The DSL guys reject both of these and want a something else. Every phone has to implement every protocol. There are some who have observed that the mechanisms at hand are L2 specific. They claim as long as you have an L2 specific mechanism, you need one or more for each L2. To get out of that, they propose that we use an L7 mechanism (think some version of HTTP, although that might not fly). They would say, lets do that once, and every L2 can use it. The problem is that you then have to deal with the security issues of an L7 mechanism, and in particular, you have to use IP address as the "key" for what location to return. If you can spoof IP address, you can get someone else's location. Those advocating L7 mechanisms claim that the mechanism would only be implemented within a domain, and the domain would have to take anti-spoofing steps. They note that the mechanism would need at least a complete round trip, and probably more than one, so spoofing requires the ability to intercept packets not addressed to the attacker. The returned data could be precisely a PIDF-LO. Then on top of that, we turn out to need some more security, especially for emergency calls. We need to prevent forged locations. That means we need to sign the PIDF-LO. If you get location via DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that, how do we construct a signature from the entity that actually determined location? Brian ________________________________________ From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of peter_blatherwick@mitel.com Sent: Wednesday, April 20, 2005 9:30 AM To: Andrew Newton Cc: GEOPRIV WG; ecrit@ietf.org Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting Hi Andrew, lists, I'd like to better understand the meaning of the following agenda items: " 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. " Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions? Reason I'm asking is I am deeply involved in a layer 2 approach which would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to. The work is going on in TIA and is called Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems. In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). We see this method of delivery as a non-competing alternative to the DHCP-based approach, with the same end result to the overall ECS system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios. (The DHCP-based method has advantages in different scenarios.) I am Editor of thi s document, and it is now in ballot process in TIA (more or less equivalent to Last Call in IETF). Sorry, I expect I am suffering lack of context here, since I only joined the list relatively recently. BTW, what is the state of geopriv-dhcp-civil? Is it now past Last Call and in the RFC Editor's queue? It seemed to have been settled on the list, and waiting on AD action. -- Peter Blatherwick Andrew Newton Sent by: geopriv-bounces@ietf.org 13.04.05 16:34 To: GEOPRIV WG cc: Subject: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting The GEOPRIV and ECRIT working groups will be holding a joint interim meeting. What: Interim GEOPRIV/ECRIT meeting When: 2005 May 16 08:30-17:30 2005 May 17 08:30-17:30 2005 May 18 08:30-17:30 Where: Columbia University Dept. of Computer Science 450 Computer Science Bldg. 1214 Amsterdam Avenue (close to 120th St.) New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html Also: WiFi provided. Teleconference to be provided. Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html Early bookings recommended. Proposed GEOPRIV Agenda: 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ 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 ------=_NextPart_000_0E7C_01C545DF.6C222DD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim = Meeting

------note the subject change = – it’s an attempt to more accurately reflect the = topic------

 

James,

 

1) Are not complex shape = definitions associated with TOA technology which is associated with wireless? =  I don’t remember anyone advocating the use of RFC3825 nor LLDP-MED = for a complete wireless solution.  If fact, I know that RFC3825 = recommends using a yet-to-be-determined more exotic method for passing location = information to a wireless client.

 

2) In the case of signing the = pidf-lo, who is going to sign it when the data is user derived (either user keyed or on-board gps)?

 

3) There seems to be consensus that = L1/L2 will, in all but user derived mechanisms, be involved in location = determination at some level.  Is it the case that you are advocating that the = L1/L2 infrastructure build and sign a pidf-lo and forward to either the client = or a L7 service somewhere in the network?

 

Just attempting to understand…….

 

-Marc-

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom
Sent: Wednesday, April = 20, 2005 5:55 PM
To: Brian Rosen; = peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; = ecrit@ietf.org
Subject: [Ecrit] RE: = [Geopriv] Announcement of Joint GEOPRIV/ECRIT = InterimMeeting

 

I think that there is one other argument that also lends itself to the returning = of the PIDF-LO rather than a layer 2 alternative, and that is that the contents = of PIDF-LO are very likely to change, largely with things being added to = them. To support these changes in PIDF-LO is relatively easy, because XML is by = its very nature extensible. It would be difficult, and I would argue completely undesirable to have to change myriad of layer 2 protocols to support a = new attribute that has been added to PIDF-LO. Case in point is the = provided-by parameter that is already there, another example would be complex shape = definitions, and also the signatures that Brian describes = below.

The problems that I see with the current layer 2 implementation are also = that they are essentially clones of one another with regards to what information = is conveyed, so if it is insufficient in one, or plain simply wrong (and I = am not saying that it is wrong), then the task to fix it is = large.

-----Original Message-----
From: = geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org<= /a>] On Behalf Of Brian Rosen
Sent: Wednesday, 20 = April 2005 11:54 PM
To: = peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; = ecrit@ietf.org; 'Andrew Newton'
Subject: RE: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT Interim Meeting

 

There turns out to be a large set of issues around this problem, which I fear = is leading to Balkanization.  There are two really important problems = we need to solve.

One fundamental problem is that every client needs to implement every = possible LI transfer mechanism that its environment could = provide.

We have DHCP.  You guys are working on LLDP-MED.   The DSL guys = reject both
of these and want a = something else.  Every phone has to implement every protocol. =

There are some who have observed that the mechanisms at hand are L2 = specific.  They claim as long as you have an L2 specific mechanism, you need one or more for = each L2.  To get out of that, they propose that we use an L7 mechanism = (think some version of HTTP, although that might not fly).  They would = say, lets do that once, and every L2 can use it.  The problem is that you = then have to deal with the security issues of an L7 mechanism, and in particular, = you have to use IP address as the "key" for what location to return.  If you can spoof IP address, you can get someone else's location. 

Those advocating L7 mechanisms claim that the mechanism would only be = implemented within a domain, and the domain would have to take anti-spoofing = steps.  They note that the mechanism would need at least a complete round trip, = and probably more than one, so spoofing requires the ability = to

intercept packets not addressed to the attacker.   The returned data = could
be precisely a = PIDF-LO.

Then on top of that, we turn out to need some more security, especially for = emergency calls.  We need to prevent forged locations.  That means we = need to sign the PIDF-LO.  If you get location via DHCP, or LLDP-MED, and = the endpoint constructs a PIDF-LO from that, how do we construct a signature = from the entity that actually determined = location?

Brian

 

________________________________________
From: = geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org<= /a>] On Behalf Of peter_blatherwick@mitel.com
Sent: Wednesday, April = 20, 2005 9:30 AM
To: Andrew = Newton
Cc: GEOPRIV WG; = ecrit@ietf.org
Subject: Re: [Geopriv] = Announcement of Joint GEOPRIV/ECRIT Interim Meeting

 

Hi Andrew, lists,  

I'd like to better understand the meaning of the following agenda items: =
  " =
  2) Properties of = network elements in transferring LI from layer 2
 upward to = PIDF-LO.
 3) Proposed = enhancements to PIDF-LO to support #2.
 " =

Is there a summary of what these really mean, or examples of what the outcome = could be in terms of protocol or layer interactions?   =

Reason I'm asking is I am deeply involved in a layer 2 approach which would be able = to deliver location information to endpoints from the L2 LAN infrastructure = they are connected to.  The work is going on in TIA and is called Link = Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which is an = extension of IEEE 802.1AB, specific to VoIP systems.  In LLDP-MED, among = several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI = (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe).  We see this method of delivery as = a non-competing alternative to the DHCP-based approach, with the same end = result to the overall ECS system (the endpoint receives the exact same data), = which has some advantages particularly in enterprise deployment scenarios. =  (The DHCP-based method has advantages in different scenarios.)   I am = Editor of thi s document, and it is now in ballot process in TIA (more or less = equivalent to Last Call in IETF).  

Sorry, I expect I am suffering lack of context here, since I only joined the list relatively recently.  

BTW, what is the state of geopriv-dhcp-civil?  Is it now past Last Call and = in the RFC Editor's queue?  It seemed to have been settled on the list, = and waiting on AD action.

-- Peter Blatherwick

 

Andrew Newton <andy@hxr.us>
Sent by: = geopriv-bounces@ietf.org
13.04.05 16:34 =
      =  
      =   To:        GEOPRIV WG <geopriv@ietf.org> =
      =   cc:        
      =   Subject:        [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting

 

The GEOPRIV and ECRIT working groups will be holding a joint interim =
meeting. =

      What: Interim GEOPRIV/ECRIT meeting
      = When: 2005 May 16 08:30-17:30
      =       2005 May 17 08:30-17:30
      =       2005 May 18 08:30-17:30
    =  Where: Columbia University
      =       Dept. of Computer Science
      =       450 Computer Science Bldg.
      =       1214 Amsterdam = Avenue (close to 120th = St.)
      =       New York, = NY 10027
Directions: http://www.cs.columbia.edu/directions.html
      = Also: WiFi provided.
      =       Teleconference to be provided.
    =  Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
      =       Early bookings recommended.

Proposed GEOPRIV Agenda:
  2005 May 16 = 08:30-17:30, 2005 May 17 08:30-12:30
1) Role of HTTP as a = transfer protocol for PIDF-LO vs. the use of LI in
HTTP/HTML for web = browsing.
2) Properties of network = elements in transferring LI from layer 2
upward to = PIDF-LO.
3) Proposed enhancements = to PIDF-LO to support #2.

Proposed ECRIT Agenda:
  2005 May 17 = 13:30-17:30, 2005 May 18 08:30-17:30
1) Emergency Call = Routing Requirements
2) Security and Threats = Analysis

______________________________________________= _
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

------=_NextPart_000_0E7C_01C545DF.6C222DD0-- --===============1549996348== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1549996348==-- From ecrit-bounces@ietf.org Wed Apr 20 20:38:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOPht-00012J-Dw; Wed, 20 Apr 2005 20:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOOei-0000Ag-KH; Wed, 20 Apr 2005 19:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07960; Wed, 20 Apr 2005 19:30:49 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOOpz-0004nD-SJ; Wed, 20 Apr 2005 19:42:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2005 16:30:40 -0700 X-IronPort-AV: i="3.92,118,1112598000"; d="scan'208,217"; a="630905947:sNHT93828472" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3KNUchu009894; Wed, 20 Apr 2005 16:30:38 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA15712; Wed, 20 Apr 2005 16:30:34 -0700 (PDT) Message-Id: <200504202330.QAA15712@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" Date: Wed, 20 Apr 2005 19:30:29 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVF9nIwWeHRWf5VR7y1tdsZHo+PsgACOBXg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.4 (+) X-Scan-Signature: 2c51cf2036fd789291a33c1e40f6afea X-Mailman-Approved-At: Wed, 20 Apr 2005 20:38:11 -0400 Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864781054==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1864781054== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E75_01C545DF.6A7F7A50" This is a multi-part message in MIME format. ------=_NextPart_000_0E75_01C545DF.6A7F7A50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ...subject changed to more accurately reflect topic... James, Since an argument for L7 location discovery architecture is no changes needed to the myriad of L2 mechanisms, what are you proposing to use for a key? -Marc- Hmmmm!!! I am not sure that I agree your statement that the key passed to external would be the IP address of the client. It could be, but I would most certainly not advocate that. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 2:13 AM To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting The basic picture is: LIS ---> endpoint ---> routing element ---> psap The LIS knows where the endpoint is. The endpoint gets location from the LIS The endpoint includes location on the emergency call The routing element uses location to route the call to the right PSAP The PSAP gets the call, and the location. The discussion is, how does the endpoint get location from the LIS? DHCP is one answer. LLDP-MED is another. A proposed L7 mechanism is another. To be sure, there are folks who want to make the picture: LIS --> endpoint --> routing element ---> psap ^ | | | | | +------------------------+ | | | +------------------------------------------+ The LIS gives the endpoint a "key" The endpoint includes the key in the emergency call The routing element gets the key and exchanges it for location at the LIS The psap gets the key and exchanges it for location at the LIS The key could be an IP address. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 12:00 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > I still get the feeling that "delivery" is being used in two different > contexts: > > (1) (2) > Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) > > How can "delivery" be L2 dependent, when it must reach a PSAP many > hops away? Color me confused. > > Mike > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL > >provider. The domain is then that of the DSL vendor. Your phone asks > >for its location from the server in the DSL domain. It would be > >given the location corresponding to the IP address of the request. > >Note that this would be pretty good for the requested case, even in > >the presence of a NATed local area network in your home. The phone > >would do this on boot, before any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. I'm > >skeptical we can do that because of the security issues. When you > >make the delivery mechanism L2 dependent, you can control the > >possible attacks to a finer grain than the L7 local domain. > > > >Please keep in mind that some of the folks wishing to use the L7 > >mechanism don't really want to just return location to the endpoint; > >they want to retain the location and give it out to authorized > >entities upon presentation of the IP address of the endpoint. That > >is a business decision. They can charge for such a service. I think > >the privacy implications of that are dicey, but the reality is that's > >the model that will probably be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would > >> seem that location delivery would need to be cross-domain. The > >> E911 PSAP will not always be the same domain as the roaming > >> endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the > >> fact that L2 is supposed to be a single physical hop at most > >> between the end- user terminal and an adjacent location-determining > >> network node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to > >> rely on location information, a general purpose delivery mechanism > >> will provide consistency and generality that is so often sought in > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local, > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem, > >> >which I fear is leading to Balkanization. There are two really > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are > >> >L2 specific. They claim as long as you have an L2 specific > >> >mechanism, you need one or more for each L2. To get out of that, > >> >they propose that we use an L7 mechanism (think some version of > >> >HTTP, although that might not fly). They would say, lets do that > >> >once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the > >> >security issues of an L7 mechanism, and in particular, you have to > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take > >> >anti-spoofing steps. They note that the mechanism would need at > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security, > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from > >> >that, how do we construct a signature from the entity that > >> >actually determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] > >> >On Behalf Of peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> > " > >> > 2) Properties of network elements in transferring LI from layer > >> >2 > >> > upward to PIDF-LO. > >> > 3) Proposed enhancements to PIDF-LO to support #2. > >> > " > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from > >> >the L2 LAN infrastructure they are connected to. The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. In LLDP-MED, among several other things, we have > >> >specified ways to pass equivalent data to the DHCP > >> >coordinate-based LCI (RFC 3825) and civic location LCI > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS > >> >system (the endpoint receives the exact same data), which has some > >> >advantages particularly in enterprise deployment scenarios. (The > >> >DHCP-based method has advantages in different scenarios.) I am > >> >Editor of thi s document, and it is now in ballot process in TIA > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last > >> >Call and in the RFC Editor's queue? It seemed to have been > >> >settled on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> > To: GEOPRIV WG > >> > cc: > >> > Subject: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> > What: Interim GEOPRIV/ECRIT meeting > >> > When: 2005 May 16 08:30-17:30 > >> > 2005 May 17 08:30-17:30 > >> > 2005 May 18 08:30-17:30 > >> > Where: Columbia University > >> > Dept. of Computer Science > >> > 450 Computer Science Bldg. > >> > 1214 Amsterdam Avenue (close to 120th St.) > >> > New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> > Also: WiFi provided. > >> > Teleconference to be provided. > >> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> > Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0E75_01C545DF.6A7F7A50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting

…..subject changed to more accurately reflect topic…….

 

James,

 

Since an argument for L7 location discovery architecture is no changes needed to the myriad of L2 = mechanisms, what are you proposing to use for a key?

 

-Marc-

 

 

 

 

Hmmmm!!!

I am not sure that I agree your statement that the key passed to external would = be the IP address of the client. It could be, but I would most certainly not = advocate that.

&nb= sp;

&nb= sp;

-----Original Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Brian Rosen
Sent: Thursday, 21 April = 2005 2:13 AM
To: 'Michael Hammer = (mhammer)'; peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; = ecrit@ietf.org
Subject: RE: [Ecrit] RE: = [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting =

 

The basic picture is:

LIS ---> endpoint ---> routing element ---> psap =

The LIS knows where the endpoint is.
The endpoint gets = location from the LIS
The endpoint includes = location on the emergency call
The routing element uses = location to route the call to the right PSAP The PSAP gets the call, and the = location.

The discussion is, how does the endpoint get location from the LIS? DHCP is = one answer.  LLDP-MED is another.  A proposed L7 mechanism is = another.

 

To be sure, there are folks who want to make the picture: =

LIS --> endpoint --> routing element ---> psap
 ^      &nb= sp;           &nbs= p;     |            =      |
 |      &nb= sp;           &nbs= p;     |            =      |
 +------------------------+  &n= bsp;           &nb= sp;  |
 |      &nb= sp;           &nbs= p;            = ;           |
 +---------------------------------------= ---+

The LIS gives the endpoint a "key"
The endpoint includes = the key in the emergency call
The routing element gets = the key and exchanges it for location at the LIS The psap gets the key and = exchanges it for location at the LIS

The key could be an IP address.

Brian

 

> -----Original Message-----
> From: Michael = Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Wednesday, = April 20, 2005 12:00 PM
> To: Brian Rosen; peter_blatherwick@mitel.com
> Cc: GEOPRIV WG; = ecrit@ietf.org
> Subject: RE: = [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> = InterimMeeting
>
> I still get the = feeling that "delivery" is being used in two different
> = contexts:
>
>       =       (1)           &nbs= p;         (2)
> Local node---?---->endpoint-----/many hops/----->PSAP
>       =     ---------------------/many hops/----->
>       =             &= nbsp;        (2)
>
> How can = "delivery" be L2 dependent, when it must reach a PSAP many
> hops away? Color me = confused.
>
> Mike =
>
>
> >-----Original = Message-----
> >From: Brian = Rosen [mailto:br@brianrosen.net]
> >Sent: = Wednesday, April 20, 2005 10:47 AM
> >To: Michael = Hammer (mhammer); peter_blatherwick@mitel.com
> >Cc: 'GEOPRIV = WG'; ecrit@ietf.org
> >Subject: RE: = [Ecrit] RE: [Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT InterimMeeting
> > =
> >The idea is = that, say, you are in your home, served by a DSL
> >provider. The = domain is then that of the DSL vendor.  Your phone asks
> >for its = location from the server in the DSL domain.  It would be
> >given the = location corresponding to the IP address of the request. 
> >Note that this = would be pretty good for the requested case, even in
> >the presence of = a NATed local area network in your home.  The phone
> >would do this = on boot, before any VPN tunnels were established.
> > =
> >I get the idea = that a single delivery mechanism is desirable. I'm
> >skeptical we = can do that because of the security issues. When you
> >make the = delivery mechanism L2 dependent, you can control the
> >possible = attacks to a finer grain than the L7 local domain.
> > =
> >Please keep in = mind that some of the folks wishing to use the L7
> >mechanism don't = really want to just return location to the endpoint;
> >they want to = retain the location and give it out to authorized
> >entities upon = presentation of the IP address of the endpoint.  That
> >is a business decision.  They can charge for such a service.  I think =
> >the privacy = implications of that are dicey, but the reality is that's
> >the model that = will probably be implemented if we do this.
> > =
> = >Brian
> > =
> > =
> > =
> > =
> > =
> >> = -----Original Message-----
> >> From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> >> Sent: = Wednesday, April 20, 2005 10:14 AM
> >> To: Brian = Rosen; peter_blatherwick@mitel.com
> >> Cc: = GEOPRIV WG; ecrit@ietf.org
> >> Subject: = RE: [Ecrit] RE: [Geopriv] Announcement of Joint
> = >GEOPRIV/ECRIT
> >> = InterimMeeting
> = >>
> >> = Brian,
> = >>
> >> Could you = clarify the domain statement.  Given nomadicity, it would
> >> seem that = location delivery would need to be cross-domain.  The
> >> E911 PSAP = will not always be the same domain as the roaming
> >> = endpoint.
> = >>
> >> My = impression is that Location discovery is a L2 issue, tied to the
> >> fact that = L2 is supposed to be a single physical hop at most
> >> between = the end- user terminal and an adjacent location-determining
> >> network = node.  (Of course those trying to make L2 protocols a
> >replacement = for
> >> IP sort of = screw this assumption up.)
> = >>
> >> The = location delivery mechanism is an application-layer or
> >L7 = service.
> >> The = argument there is that since multiple applications will need to
> >> rely on = location information, a general purpose delivery mechanism
> >> will = provide consistency and generality that is so often sought in
> >> IETF = work.  Security can be built-in to the chosen delivery
> = >mechanism.
> >> Note, that = delivery could be a choice of an existing transfer
> >> = mechanism.  This does not preclude other L7 protocols from
> >defining = a
> >> place in = their messages that could also carry location information.
> = >>
> >> So, I = believe:
> >> Location = discovery is local, with associated security being local,
> >> Location = delivery is global, with associated security being global.
> = >>
> >> The real = issues are making those happen.
> = >>
> >> = Mike
> = >>
> >> = >-----Original Message-----
> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On
> >> >Behalf = Of Brian Rosen
> >> >Sent: = Wednesday, April 20, 2005 9:54 AM
> >> >To: peter_blatherwick@mitel.com
> >> >Cc: = 'GEOPRIV WG'; ecrit@ietf.org
> >> = >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> >> = >InterimMeeting
> >> = >
> >> >There = turns out to be a large set of issues around this problem,
> >> >which = I fear is leading to Balkanization.  There are two really
> >> = >important problems we need to solve.
> >> = >
> >> >One = fundamental problem is that every client needs to
> >implement = every
> >> = >possible LI transfer mechanism that its environment could provide. =
> >> = >
> >> >We = have DHCP.  You guys are working on LLDP-MED.   The = DSL
> >> >guys = reject both
> >> >of = these and want a something else.  Every phone has to implement
> >> >every = protocol.
> >> = >
> >> >There = are some who have observed that the mechanisms at hand are
> >> >L2 specific.  They claim as long as you have an L2 specific =
> >> = >mechanism, you need one or more for each L2.  To get out of that,
> >> >they = propose that we use an L7 mechanism (think some version of
> >> >HTTP, = although that might not fly).  They would say, lets do that =
> >> = >once,
> >and every = L2
> >> >can = use it.  The problem is that you then have to deal with the
> >> = >security issues of an L7 mechanism, and in particular, you have to
> >> >use IP = address as the "key" for what location to return.
> >If you = can
> >> >spoof = IP address, you can get someone else's location.
> >> = >
> >> >Those = advocating L7 mechanisms claim that the mechanism
> >would only = be
> >> = >implemented within a domain, and the domain would have to take
> >> = >anti-spoofing steps.  They note that the mechanism would need at =
> >> >least = a complete round trip, and probably more than one, so
> = >spoofing
> >> = >requires the ability to
> >> = >intercept packets not addressed to the attacker.   The
> >> = >returned data could
> >> >be = precisely a PIDF-LO.
> >> = >
> >> >Then = on top of that, we turn out to need some more security,
> >> = >especially for emergency calls.  We need to prevent forged
> = >locations.
> >> >That = means we need to sign the PIDF-LO.  If you get location via =
> >> >DHCP, = or LLDP-MED, and the endpoint constructs a PIDF-LO from
> >> >that, = how do we construct a signature from the entity that
> >> = >actually determined location?
> >> = >
> >> = >Brian
> >> = >
> >> = >
> >> >________________________________________
> >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org<= /a>]
> >> >On = Behalf Of peter_blatherwick@mitel.com
> >> >Sent: = Wednesday, April 20, 2005 9:30 AM
> >> >To: = Andrew Newton
> >> >Cc: = GEOPRIV WG; ecrit@ietf.org
> >> = >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim
> >> = >Meeting
> >> = >
> >> = >
> >> >Hi = Andrew, lists,
> >> = >
> >> >I'd = like to better understand the meaning of the following agenda
> >> = >items:
> >> >  = "
> >> >  = 2) Properties of network elements in transferring LI from layer =
> >> = >2
> >> = > upward to PIDF-LO.
> >> = > 3) Proposed enhancements to PIDF-LO to support #2.
> >> = > "
> >> = >
> >> >Is = there a summary of what these really mean, or examples
> >of what = the
> >> = >outcome could be in terms of protocol or layer interactions?
> >> = >
> >> >Reason = I'm asking is I am deeply involved in a layer 2
> >approach = which
> >> >would = be able to deliver location information to endpoints from
> >> >the L2 = LAN infrastructure they are connected to.  The work is =
> >going on = in
> >> >TIA = and is called Link Layer Discovery Protocol - Media Endpoint
> >> = >Discovery (LLDP-MED), which is an extension of IEEE
> >802.1AB, = specific
> >> >to = VoIP systems.  In LLDP-MED, among several other things, we have =
> >> = >specified ways to pass equivalent data to the DHCP
> >> = >coordinate-based LCI (RFC 3825) and civic location LCI
> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process = I
> = >believe).
> >> >We see = this method of delivery as a non-competing
> >alternative to = the
> >> = >DHCP-based approach, with the same end result to the overall ECS
> >> >system = (the endpoint receives the exact same data), which has some =
> >> = >advantages particularly in enterprise deployment scenarios.  (The =
> >> = >DHCP-based method has advantages in different scenarios.)   I am
> >> >Editor = of thi s document, and it is now in ballot process in TIA
> >> >(more = or less equivalent to Last Call in IETF).
> >> = >
> >> >Sorry, = I expect I am suffering lack of context here, since I only
> >> >joined = the list relatively recently.
> >> = >
> >> >BTW, = what is the state of geopriv-dhcp-civil?  Is it now past Last =
> >> >Call = and in the RFC Editor's queue?  It seemed to have been
> >> = >settled on the list, and waiting on AD action.
> >> = >
> >> >-- = Peter Blatherwick
> >> = >
> >> = >
> >> = >
> >> = >
> >> >Andrew = Newton <andy@hxr.us>
> >> >Sent = by: geopriv-bounces@ietf.org
> >> = >13.04.05 16:34
> >> = >
> >> >  =       To:        GEOPRIV WG <geopriv@ietf.org>
> >> >  =       cc:
> >> >  =       Subject:        [Geopriv] Announcement = of Joint
> = >GEOPRIV/ECRIT
> >> = >Interim Meeting
> >> = >
> >> = >
> >> = >
> >> = >
> >> >The = GEOPRIV and ECRIT working groups will be holding a
> >joint = interim
> >> = >meeting.
> >> = >
> >> >  =     What: Interim GEOPRIV/ECRIT meeting
> >> >  =     When: 2005 May 16 08:30-17:30
> >> >  =           2005 May 17 08:30-17:30
> >> >  =           2005 May 18 08:30-17:30
> >> >  =    Where: Columbia University
> >> >  =           Dept. of Computer Science
> >> >  =           450 Computer Science Bldg. =
> >> >  =           1214 Amsterdam Avenue (close to 120th = St.)
> >> >  =           New York, NY 10027
> >> = >Directions: http://www.cs.columbia.edu/directions.html
> >> >  =     Also: WiFi provided.
> >> >  =           Teleconference to be provided. =
> >> >  =    Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
> >> >  =           Early bookings recommended. =
> >> = >
> >> = >Proposed GEOPRIV Agenda:
> >> >  = 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30
> >> >1) = Role of HTTP as a transfer protocol for PIDF-LO vs. the
> >use of = LI
> >> >in = HTTP/HTML for web browsing.
> >> >2) = Properties of network elements in transferring LI from layer 2
> >> >upward = to PIDF-LO.
> >> >3) = Proposed enhancements to PIDF-LO to support #2.
> >> = >
> >> = >Proposed ECRIT Agenda:
> >> >  = 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30
> >> >1) = Emergency Call Routing Requirements
> >> >2) = Security and Threats Analysis
> >> = >
> >> >_______________________________________________
> >> = >Geopriv mailing list
> >> = >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
> >> = >
> >> = >
> >> = >
> >> = >
> >> >_______________________________________________
> >> >Ecrit = mailing list
> >> = >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit=
> >> = >
> = >>
> > =
> > =
> =

 

______________________________________________= _
Ecrit mailing = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=

------=_NextPart_000_0E75_01C545DF.6A7F7A50-- --===============1864781054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1864781054==-- From ecrit-bounces@ietf.org Wed Apr 20 21:13:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQG4-0005et-0z; Wed, 20 Apr 2005 21:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQG2-0005ei-Cv; Wed, 20 Apr 2005 21:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16666; Wed, 20 Apr 2005 21:13:28 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQRM-0007Cu-3T; Wed, 20 Apr 2005 21:25:12 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3L1Cte01152; Wed, 20 Apr 2005 20:12:56 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 11:11:05 +1000 Message-ID: From: "James Winterbottom" To: Henning Schulzrinne Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erim Meeting Date: Thu, 21 Apr 2005 11:11:06 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128908433==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2128908433== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5460E.FE55D894" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5460E.FE55D894 Content-Type: text/plain But Henning, not all applications do need to understand it, and it can be included easily in XML. This is simply not the case with DHCP. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, 21 April 2005 9:17 AM To: Winterbottom, James [WOLL:5500:EXCH] Cc: Brian Rosen; peter_blatherwick@mitel.com; 'GEOPRIV WG'; ecrit@ietf.org Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting James Winterbottom wrote: > I think that there is one other argument that also lends itself to the > returning of the PIDF-LO rather than a layer 2 alternative, and that is > that the contents of PIDF-LO are very likely to change, largely with > things being added to them. To support these changes in PIDF-LO is > relatively easy, because XML is by its very nature extensible. It would > be difficult, and I would argue completely undesirable to have to change > myriad of layer 2 protocols to support a new attribute that has been This is bogus. We have essentially two layer-2 mechanisms that inherit the same name space. Registering and defining a new XML tag is no easier (or no more difficult) than registering a new DHCP numeric tag. Just because it's XML doesn't mean that magically all applications understand it. ------_=_NextPart_001_01C5460E.FE55D894 Content-Type: text/html RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting

But Henning, not all applications do need to understand it, and it can be included easily in XML.
This is simply not the case with DHCP.


-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Thursday, 21 April 2005 9:17 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: Brian Rosen; peter_blatherwick@mitel.com; 'GEOPRIV WG'; ecrit@ietf.org
Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting


James Winterbottom wrote:
> I think that there is one other argument that also lends itself to the
> returning of the PIDF-LO rather than a layer 2 alternative, and that is
> that the contents of PIDF-LO are very likely to change, largely with
> things being added to them. To support these changes in PIDF-LO is
> relatively easy, because XML is by its very nature extensible. It would
> be difficult, and I would argue completely undesirable to have to change
> myriad of layer 2 protocols to support a new attribute that has been

This is bogus. We have essentially two layer-2 mechanisms that inherit
the same name space. Registering and defining a new XML tag is no easier
(or no more difficult) than registering a new DHCP numeric tag. Just
because it's XML doesn't mean that magically all applications understand it.

------_=_NextPart_001_01C5460E.FE55D894-- --===============2128908433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2128908433==-- From ecrit-bounces@ietf.org Wed Apr 20 21:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQGy-0005jB-Ll; Wed, 20 Apr 2005 21:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQGx-0005j2-HB; Wed, 20 Apr 2005 21:14:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16723; Wed, 20 Apr 2005 21:14:26 -0400 (EDT) Message-Id: <200504210114.VAA16723@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQSG-0007Dr-Mw; Wed, 20 Apr 2005 21:26:10 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOQGk-0004n7-OY; Wed, 20 Apr 2005 20:14:15 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 21:14:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3113BD0@xmb-rtp-20b.amer.cisco.com> Thread-Index: AcVF47FTZ5vdqlAKRYOS7WA4dGCh1QAGErGAAASGbsA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yeah, you have the basic picture. The issues are somewhat different for cable and DSL, but it's true that the home router supplies DHCP, and would have to determine location from the upstream network and relay it to downstream clients like a VoIP phone. With cable, they really use DHCP, so the router, when it gets it's IP address from the cablemodem can get location at the same time. With cable, it's likely to map the cablemodem MAC address to the service location. The cable modem and home router would have to be updated to relay location. DSL doesn't use DHCP between the router/DSL modem and the DSL network to get IP address, and they don't want to use DHCP for location. They could use any mechanism they would like to between the DSL modem/router and the DSL network, if they would then use DHCP (which is how the clients get IP address from the router) for location. This requires an update to installed DSL modem/routers. They have a small, and decreasing number of cases where the DSL modem is directly tied (via Ethernet) to PC. In that case, they have to supply special code for the PC to get an IP address. They would have to update this code with location reporting code. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 20, 2005 7:13 PM > To: Henning Schulzrinne > Cc: Brian Rosen; peter_blatherwick@mitel.com; GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > Henning, > > Thanks. This is the sort of detail that I was hoping to stir up. > > So, the first hop network needs to be the source of location > information. In my house that is my home network/router, which would > seem to imply that it needs to acquire location into it somehow. The > router in turn pretends to be a PC and talks through the cable/DSL modem > to an upstream server to get IP addresses and such. Will my home router > store and relay location information in the access SP? This assumes > that the location is provisioned into the cable/DSL system. > > If I also remember some security mechanisms correctly, DHCP-spoofing is > prevented by not allowing such traffic to go very far. I wouldn't think > that DHCP gets put into VPN tunnels, but I could be wrong. > > Seems like there are several interfaces X protocol choices to work out > here. > > Thanks, > Mike > > >-----Original Message----- > >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >Sent: Wednesday, April 20, 2005 3:59 PM > >To: Michael Hammer (mhammer) > >Cc: Brian Rosen; peter_blatherwick@mitel.com; GEOPRIV WG; > >ecrit@ietf.org > >Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The basic problem for the end system is > > > >"Get the physically closest box that knows to tell me where I am" > > > >The core requirement is zero client configuration. > > > >L2 and DHCP mechanisms have the advantage that they usually > >are as close as you're going to get. You can make this > >indirect, i.e., have DHCP, PPP or L2 tell the client where to > >get its address. > > Or where to go to get location information via a L7 protocol? > > > > >L2 (LLDP-MED) has the advantage that the physical structure > >ensures that I get the correct answer, without doing mappings. > >Mappings are always subject to being out-of-date or ambiguous > >or not have the right lookup-key information (e.g., real MAC > >address, lost on its way through a router or MAC-spoofing > >bridge). (This is even true for DHCP, where the DHCP server > >may have to derive from switch port tracing where a device is, > >which is subject to a variety of failure modes.) > > > > > >Michael Hammer (mhammer) wrote: > >> Brian, > >> > >> You describe the NENA phase i2 options, ESQK etc. Your > >routing element, I assume is doing session routing. > >> > >> The elements you detail are all (or would appear to be) > >application-layer entities and the signaling hops are likewise > >application-layer hops, not L2 hops (except for maybe the LIS-->EP). > >> > >> So, where is the L2 "dependency" coming from? > >> > >> I understand that a network node that is immediately > >adjacent to the endpoint is most likely to know where the > >other end of the link terminates, but does that force the > >delivery protocol aspects of this to be a L2 issue? > >> > >> Each of the myriad link types carry IP packets, no? And IP > >packets can carry an application packet, no? So, wouldn't the > >application-layer solution be the more general one? I thought > >that was in line with IETF principles. > >> > >> You are probably just laying out the options, not promoting a > >> particular one. I would be interested in seeing what the > >champions of > >> one approach or another have to say. (I did a search on > >LLDP-MED and > >> drew a blank.) > >> > >> Mike > >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 21:22:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQOn-0006mS-SO; Wed, 20 Apr 2005 21:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQOl-0006mH-72; Wed, 20 Apr 2005 21:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17568; Wed, 20 Apr 2005 21:22:29 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQa4-0007R5-Vd; Wed, 20 Apr 2005 21:34:14 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3L1MHe02028; Wed, 20 Apr 2005 20:22:18 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 11:22:01 +1000 Message-ID: From: "James Winterbottom" To: Marc Linsner Date: Thu, 21 Apr 2005 11:22:02 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.7 (/) X-Scan-Signature: ecc3a678f36d06d556925e6a5174d2ac Cc: geopriv@ietf.org, ecrit@ietf.org Subject: [Ecrit] RE: L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283124613==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1283124613== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54610.8565CEB0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54610.8565CEB0 Content-Type: text/plain Hi Marc, Please see comments in line. -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, 21 April 2005 9:30 AM To: Winterbottom, James [WOLL:5500:EXCH] Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: L2 vs. L7 Location Discover ------note the subject change - it's an attempt to more accurately reflect the topic------ James, 1) Are not complex shape definitions associated with TOA technology which is associated with wireless? I don't remember anyone advocating the use of RFC3825 nor LLDP-MED for a complete wireless solution. If fact, I know that RFC3825 recommends using a yet-to-be-determined more exotic method for passing location information to a wireless client. [ajw] Would you not agree that a single approach to location delivery is more desirable than one per access technology? 2) In the case of signing the pidf-lo, who is going to sign it when the data is user derived (either user keyed or on-board gps)? [ajw] Please read the HELD draft, it goes into a great deal of explanation on how this is possible. While there maybe other problems in HELD, this one is quite well addressed I believe. 3) There seems to be consensus that L1/L2 will, in all but user derived mechanisms, be involved in location determination at some level. Is it the case that you are advocating that the L1/L2 infrastructure build and sign a pidf-lo and forward to either the client or a L7 service somewhere in the network? [ajw] ABSOLUTELY, this has always been my advocation. Location determination is clearly layer 1 and layer 2, location delivery is not. I believe that it is better to provide to the client the object that it plans to use, not something that it needs to munge in order to be able to use. Just attempting to understand....... -Marc- _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, April 20, 2005 5:55 PM To: Brian Rosen; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I think that there is one other argument that also lends itself to the returning of the PIDF-LO rather than a layer 2 alternative, and that is that the contents of PIDF-LO are very likely to change, largely with things being added to them. To support these changes in PIDF-LO is relatively easy, because XML is by its very nature extensible. It would be difficult, and I would argue completely undesirable to have to change myriad of layer 2 protocols to support a new attribute that has been added to PIDF-LO. Case in point is the provided-by parameter that is already there, another example would be complex shape definitions, and also the signatures that Brian describes below. The problems that I see with the current layer 2 implementation are also that they are essentially clones of one another with regards to what information is conveyed, so if it is insufficient in one, or plain simply wrong (and I am not saying that it is wrong), then the task to fix it is large. -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org ] On Behalf Of Brian Rosen Sent: Wednesday, 20 April 2005 11:54 PM To: peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Andrew Newton' Subject: RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting There turns out to be a large set of issues around this problem, which I fear is leading to Balkanization. There are two really important problems we need to solve. One fundamental problem is that every client needs to implement every possible LI transfer mechanism that its environment could provide. We have DHCP. You guys are working on LLDP-MED. The DSL guys reject both of these and want a something else. Every phone has to implement every protocol. There are some who have observed that the mechanisms at hand are L2 specific. They claim as long as you have an L2 specific mechanism, you need one or more for each L2. To get out of that, they propose that we use an L7 mechanism (think some version of HTTP, although that might not fly). They would say, lets do that once, and every L2 can use it. The problem is that you then have to deal with the security issues of an L7 mechanism, and in particular, you have to use IP address as the "key" for what location to return. If you can spoof IP address, you can get someone else's location. Those advocating L7 mechanisms claim that the mechanism would only be implemented within a domain, and the domain would have to take anti-spoofing steps. They note that the mechanism would need at least a complete round trip, and probably more than one, so spoofing requires the ability to intercept packets not addressed to the attacker. The returned data could be precisely a PIDF-LO. Then on top of that, we turn out to need some more security, especially for emergency calls. We need to prevent forged locations. That means we need to sign the PIDF-LO. If you get location via DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that, how do we construct a signature from the entity that actually determined location? Brian ________________________________________ From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org ] On Behalf Of peter_blatherwick@mitel.com Sent: Wednesday, April 20, 2005 9:30 AM To: Andrew Newton Cc: GEOPRIV WG; ecrit@ietf.org Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting Hi Andrew, lists, I'd like to better understand the meaning of the following agenda items: " 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. " Is there a summary of what these really mean, or examples of what the outcome could be in terms of protocol or layer interactions? Reason I'm asking is I am deeply involved in a layer 2 approach which would be able to deliver location information to endpoints from the L2 LAN infrastructure they are connected to. The work is going on in TIA and is called Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which is an extension of IEEE 802.1AB, specific to VoIP systems. In LLDP-MED, among several other things, we have specified ways to pass equivalent data to the DHCP coordinate-based LCI (RFC 3825) and civic location LCI (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). We see this method of delivery as a non-competing alternative to the DHCP-based approach, with the same end result to the overall ECS system (the endpoint receives the exact same data), which has some advantages particularly in enterprise deployment scenarios. (The DHCP-based method has advantages in different scenarios.) I am Editor of thi s document, and it is now in ballot process in TIA (more or less equivalent to Last Call in IETF). Sorry, I expect I am suffering lack of context here, since I only joined the list relatively recently. BTW, what is the state of geopriv-dhcp-civil? Is it now past Last Call and in the RFC Editor's queue? It seemed to have been settled on the list, and waiting on AD action. -- Peter Blatherwick Andrew Newton Sent by: geopriv-bounces@ietf.org 13.04.05 16:34 To: GEOPRIV WG cc: Subject: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting The GEOPRIV and ECRIT working groups will be holding a joint interim meeting. What: Interim GEOPRIV/ECRIT meeting When: 2005 May 16 08:30-17:30 2005 May 17 08:30-17:30 2005 May 18 08:30-17:30 Where: Columbia University Dept. of Computer Science 450 Computer Science Bldg. 1214 Amsterdam Avenue (close to 120th St.) New York, NY 10027 Directions: http://www.cs.columbia.edu/directions.html Also: WiFi provided. Teleconference to be provided. Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html Early bookings recommended. Proposed GEOPRIV Agenda: 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 1) Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in HTTP/HTML for web browsing. 2) Properties of network elements in transferring LI from layer 2 upward to PIDF-LO. 3) Proposed enhancements to PIDF-LO to support #2. Proposed ECRIT Agenda: 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 1) Emergency Call Routing Requirements 2) Security and Threats Analysis _______________________________________________ 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 ------_=_NextPart_001_01C54610.8565CEB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 Marc,
 
Please=20 see comments in line.
-----Original Message-----
From: = Marc Linsner=20 [mailto:mlinsner@cisco.com]
Sent: Thursday, 21 April 2005 = 9:30=20 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: = 'GEOPRIV=20 WG'; ecrit@ietf.org
Subject: L2 vs. L7 Location=20 Discover

------note = the=20 subject change - it's an attempt to more accurately reflect the=20 topic------

 =

James,

 

1) Are not = complex=20 shape definitions associated with TOA technology which is associated = with=20 wireless?  I don't remember anyone advocating the use of RFC3825 = nor=20 LLDP-MED for a complete wireless solution.  If fact, I know that = RFC3825=20 recommends using a yet-to-be-determined more exotic method for = passing=20 location information to a wireless client. 

[ajw] Would you not = agree that a=20 single approach to location delivery is more desirable than one per = access=20 technology? 

 

2) In the = case of=20 signing the pidf-lo, who is going to sign it when the data is user = derived=20 (either user keyed or on-board gps)? 

[ajw] Please read = the HELD draft,=20 it goes into a great deal of explanation on how this is=20 possible. While there maybe other problems in HELD, this one is = quite=20 well addressed I believe.

 

3) There = seems to be=20 consensus that L1/L2 will, in all but user derived mechanisms, be = involved in=20 location determination at some level.  Is it the case that you = are=20 advocating that the L1/L2 infrastructure build and sign a pidf-lo and = forward=20 to either the client or a L7 service somewhere in the network? 

[ajw] ABSOLUTELY, this has=20 always been my advocation. Location determination is clearly layer 1 = and layer=20 2, location delivery is not. I believe that it is better to provide = to the=20 client the object that it plans to use, not something that = it needs to=20 munge in order to be able to=20 use. 

 

Just = attempting to=20 understand.......

 

-Marc-

 

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James=20 Winterbottom
Sent: = Wednesday,=20 April 20, 2005 5:55 PM
To:=20 Brian Rosen; peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG';=20 ecrit@ietf.org
Subject:=20 [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 InterimMeeting

 

I think=20 that there is one other argument that also lends itself to the = returning of=20 the PIDF-LO rather than a layer 2 alternative, and that is that the = contents=20 of PIDF-LO are very likely to change, largely with things being added = to them.=20 To support these changes in PIDF-LO is relatively easy, because XML = is by its=20 very nature extensible. It would be difficult, and I would argue = completely=20 undesirable to have to change myriad of layer 2 protocols to support = a new=20 attribute that has been added to PIDF-LO. Case in point is the = provided-by=20 parameter that is already there, another example would be complex = shape=20 definitions, and also the signatures that Brian describes=20 below.

The=20 problems that I see with the current layer 2 implementation are also = that they=20 are essentially clones of one another with regards to what = information is=20 conveyed, so if it is insufficient in one, or plain simply wrong (and = I am not=20 saying that it is wrong), then the task to fix it is=20 large.

-----Original Message----- =
From: = geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ] On=20 Behalf Of Brian Rosen
Sent: Wednesday, 20 April 2005 11:54 = PM=20
To:=20 peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; ecrit@ietf.org; 'Andrew=20 Newton'
Subject:=20 RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim=20 Meeting

 

There=20 turns out to be a large set of issues around this problem, which I = fear is=20 leading to Balkanization.  There are two really important = problems we=20 need to solve.

One=20 fundamental problem is that every client needs to implement every = possible LI=20 transfer mechanism that its environment could=20 provide.

We have=20 DHCP.  You guys are working on LLDP-MED.   The DSL = guys reject=20 both
of these and=20 want a something else.  Every phone has to implement every=20 protocol.

There are=20 some who have observed that the mechanisms at hand are L2 = specific.  They=20 claim as long as you have an L2 specific mechanism, you need one or = more for=20 each L2.  To get out of that, they propose that we use an L7 = mechanism=20 (think some version of HTTP, although that might not fly).  They = would=20 say, lets do that once, and every L2 can use it.  The problem is = that you=20 then have to deal with the security issues of an L7 mechanism, and in = particular, you have to use IP address as the "key" for what location = to=20 return.  If you can spoof IP address, you can get someone else's = location. 

Those=20 advocating L7 mechanisms claim that the mechanism would only be = implemented=20 within a domain, and the domain would have to take anti-spoofing = steps. =20 They note that the mechanism would need at least a complete round = trip, and=20 probably more than one, so spoofing requires the ability=20 to

intercept=20 packets not addressed to the attacker.   The returned data=20 could
be=20 precisely a PIDF-LO.

Then on=20 top of that, we turn out to need some more security, especially for = emergency=20 calls.  We need to prevent forged locations.  That means we = need to=20 sign the PIDF-LO.  If you get location via DHCP, or LLDP-MED, = and the=20 endpoint constructs a PIDF-LO from that, how do we construct a = signature from=20 the entity that actually determined = location?

Brian

 

________________________________________=20
From: = geopriv-bounces@ietf.org=20 [mailto:geopriv-bounces@ietf.org= ] On=20 Behalf Of peter_blatherwick@mitel.com
Sent: Wednesday, April 20, 2005 9:30 = AM=20
To: Andrew = Newton=20
Cc: GEOPRIV WG;=20 ecrit@ietf.org
Subject: Re: [Geopriv] Announcement of = Joint=20 GEOPRIV/ECRIT Interim Meeting

 

Hi=20 Andrew, lists,  

I'd like=20 to better understand the meaning of the following agenda items:=20
  "=20
  2)=20 Properties of network elements in transferring LI from layer 2=20
 upward to=20 PIDF-LO.
 3)=20 Proposed enhancements to PIDF-LO to support #2. =
 " =

Is there=20 a summary of what these really mean, or examples of what the outcome = could be=20 in terms of protocol or layer interactions?  =20

Reason=20 I'm asking is I am deeply involved in a layer 2 approach which would = be able=20 to deliver location information to endpoints from the L2 LAN = infrastructure=20 they are connected to.  The work is going on in TIA and is = called Link=20 Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED), which = is an=20 extension of IEEE 802.1AB, specific to VoIP systems.  In = LLDP-MED, among=20 several other things, we have specified ways to pass equivalent data = to the=20 DHCP coordinate-based LCI (RFC 3825) and civic location LCI=20 (draft-ietf-geopriv-dhcp-civil-05, in Last Call process I believe). =  We=20 see this method of delivery as a non-competing alternative to the = DHCP-based=20 approach, with the same end result to the overall ECS system (the = endpoint=20 receives the exact same data), which has some advantages particularly = in=20 enterprise deployment scenarios.  (The DHCP-based method has = advantages=20 in different scenarios.)   I am Editor of thi s document, and it = is now=20 in ballot process in TIA (more or less equivalent to Last Call in = IETF).=20  

Sorry, I=20 expect I am suffering lack of context here, since I only joined the = list=20 relatively recently.  

BTW, what=20 is the state of geopriv-dhcp-civil?  Is it now past Last Call = and in the=20 RFC Editor's queue?  It seemed to have been settled on the list, = and=20 waiting on AD action.

-- Peter=20 Blatherwick

 

Andrew=20 Newton <andy@hxr.us>
Sent by: geopriv-bounces@ietf.org=20
13.04.05 16:34=20
   =20    
        To:   =    =20  GEOPRIV WG <geopriv@ietf.org>
        cc:   =    =20  
 =20       Subject:        [Geopriv]=20 Announcement of Joint GEOPRIV/ECRIT Interim Meeting=20

 

The=20 GEOPRIV and ECRIT working groups will be holding a joint interim=20
meeting.

 =20     What: Interim GEOPRIV/ECRIT meeting =
      When: = 2005 May 16=20 08:30-17:30
            = 2005 May 17=20 08:30-17:30
            = 2005 May 18=20 08:30-17:30
     Where: Columbia=20 University
 =20           Dept. of Computer = Science=20
    =    =20     450 Computer Science Bldg.
            = 1214 Amsterdam Avenue (close = to=20 120th St.) =
        =    =20 New York, = NY 10027 =
Directions: http://www.cs.columbia.edu/directions.html=20
    =   Also: WiFi=20 provided.
 =20           Teleconference to be=20 provided.
 =20    Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html=20
    =    =20     Early bookings recommended. =

Proposed=20 GEOPRIV Agenda:
  2005 May 16 08:30-17:30, 2005 May 17 = 08:30-12:30
1)=20 Role of HTTP as a transfer protocol for PIDF-LO vs. the use of LI in=20
HTTP/HTML for web=20 browsing.
2)=20 Properties of network elements in transferring LI from layer 2=20
upward to=20 PIDF-LO.
3)=20 Proposed enhancements to PIDF-LO to support #2. =

Proposed=20 ECRIT Agenda:
  2005 May 17 13:30-17:30, 2005 May 18 = 08:30-17:30
1)=20 Emergency Call Routing Requirements
2) Security and Threats = Analysis=20

_______________________________________________=20
Geopriv mailing=20 list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv=20

 

_______________________________________________=20
Geopriv mailing=20 list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv=20

------_=_NextPart_001_01C54610.8565CEB0-- --===============1283124613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1283124613==-- From ecrit-bounces@ietf.org Wed Apr 20 21:27:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQTt-0007Ov-0J; Wed, 20 Apr 2005 21:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQTq-0007On-UP; Wed, 20 Apr 2005 21:27:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17859; Wed, 20 Apr 2005 21:27:45 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQfA-0007Wt-Ko; Wed, 20 Apr 2005 21:39:29 -0400 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+kQEI+YceqPXLggeCPh1q/Zgzq33fKcuw@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3L1Rch3028242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 21:27:40 -0400 (EDT) Message-ID: <4267017B.2090809@cs.columbia.edu> Date: Wed, 20 Apr 2005 21:27:23 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <200504210114.j3L1ELqt004067@cs.columbia.edu> In-Reply-To: <200504210114.j3L1ELqt004067@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > > DSL doesn't use DHCP between the router/DSL modem and the DSL network to get > IP address, and they don't want to use DHCP for location. They could use Since they use PPPoE and assign addresses using PPP, couldn't they just add a location option to PPP, in the same format as for DHCP? It already conveys other information, such as the DNS server. (http://www.networksorcery.com/enp/protocol/IPCP.htm) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 21:35:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQbF-0008Dg-ET; Wed, 20 Apr 2005 21:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQbE-0008DY-2b; Wed, 20 Apr 2005 21:35:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18405; Wed, 20 Apr 2005 21:35:20 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQmV-0007hU-Vr; Wed, 20 Apr 2005 21:47:04 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3L1YZe03110; Wed, 20 Apr 2005 20:34:36 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 11:33:45 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Thu, 21 Apr 2005 11:33:45 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034785235==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0034785235== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54612.28B76370" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54612.28B76370 Content-Type: text/plain I think that you are missing something here. You are making the assumption that L7 is only used to retrieve location after the VPN tunnel has been established, I fail to see why this has to be the case. It could just as easily be retrieved from the local network prior to the tunnel being established and so this presents no more difficulty for VPNs and softclients than a layer 2 delivered solution. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 6:19 AM To: 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I'm having some off line discussions that lead me to the following: If you have a box that opens a VPN tunnel on the raw Internet connection that feeds a LAN that has endpoints, and passes ALL LAN traffic through the tunnel, you are hosed. The box has to be location aware in some way. This is because there is no way, L2 or L7, that you can get a packet to anything that knows about the location; the box is forcing everything through the tunnel. The box is physically between the uplink and the LAN, and you can't go around it. The box has to do something that lets you get at the right LIS. If the box supplies IP addresses (it's the DHCP server), then it only has to relay the location option. If the box doesn't supply addresses, it would have to run something that either the client could access, or something the DHCP server would access. We have no solutions. L7 doesn't help; the box has to do something that would allow you to get to the local LIS, with the boxe's public IP address. Softclients are much easier, because the system can get location before the tunnel is established. Tunnels downstream of the local infrastructure are problematic for L7, but not for L2. This is bad news. All the boxes have to change. If we have to change all the softclients for L7, is that a big enough reason to not use L7? Hmmm. I don't know enough about how the boxes work. To make DHCP work with the DHCP server in the corporate network, not in the box, the box has to pass the DHCP packets; they aren't IP packets. Does that mean it's always a DHCP relay? That would help. The boxes have to change, but if they are already doing DHCP relay, adding the location option would be the least amount of work. I keep hoping I've missed something here. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 20, 2005 3:48 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV > WG'; ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > There are at least two separate sets of issues that depend on the > architecture, and it seems dangerous to conflate the two: > > (First-person) I get my own location from a server. This makes address > spoofing more difficult, with return routability. Drawback: If I'm > behind a NAT, and the location server isn't, this works only if the IP > address in the IP packet is used, not something in the query. VPNs > should not be a big deal here. > > (Third-person) I ask for an address for an IP address. Address > spoofing and VPN issues matter, possibly NAT issues (since the IP > address I get may be a NAT address, given the typical circles of NAT > hell in various > networks.) > > I think first-person is much more palatable than third-person. > > Brian Rosen wrote: > > "Routing" in this context is session (SIP) routing, as you > > suspected. > > > > The first hop (LIS to endpoint) is what we are discussing. DHCP is > > not an L3+ protocol. Neither is LLDP-MED. > > > > The thread has discussed a number of problems with an L7 mechanism, > > but laying them out: > > > > 1. You are subject to IP address spoofing (albeit you need to be > > able to > get > > the packets sent from the LIS to the IP address you are spoofing) > > > > 2. VPN or other tunnels may have been created before you run this > protocol. > > That will cause a failure; you need the location corresponding to > > the original "outermost" IP address. > > > > 3. It is difficult to control the security (beyond IP spoofing) > > because > you > > don't have a generally good authentication mechanism. This is a > > bare > phone, > > or equivalent, during its boot phase. > > > > There are probably others as well. 2) is the real problem. > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C54612.28B76370 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT = InterimMeeting

I think that you are missing something here.
You are making the assumption that L7 is only used = to retrieve location after the VPN tunnel has been established, I fail = to see why this has to be the case. It could just as easily be = retrieved from the local network prior to the tunnel being established = and so this presents no more difficulty for VPNs and softclients than a = layer 2 delivered solution.



-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Thursday, 21 April 2005 6:19 AM
To: 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; ecrit@ietf.org
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of = Joint GEOPRIV/ECRIT InterimMeeting


I'm having some off line discussions that lead me to = the following:

If you have a box that opens a VPN tunnel on the raw = Internet connection that feeds a LAN that has endpoints, and passes ALL = LAN traffic through the tunnel, you are hosed.  The box has to be = location aware in some way.  This is because there is no way, L2 = or L7, that you can get a packet to anything that knows about the = location; the box is forcing everything through the tunnel.  The = box is physically between the uplink and the LAN, and you can't go = around it.  The box has to do something that lets you get at the = right LIS.

If the box supplies IP addresses (it's the DHCP = server), then it only has to relay the location option.

If the box doesn't supply addresses, it would have to = run something that either the client could access, or something the = DHCP server would access. We have no solutions.

L7 doesn't help; the box has to do something that = would allow you to get to the local LIS, with the boxe's public IP = address.

Softclients are much easier, because the system can = get location before the tunnel is established.  Tunnels downstream = of the local infrastructure are problematic for L7, but not for = L2.

This is bad news.  All the boxes have to = change.  If we have to change all the softclients for L7, is that = a big enough reason to not use L7?

Hmmm.  I don't know enough about how the boxes = work.  To make DHCP work with the DHCP server in the corporate = network, not in the box, the box has to pass the DHCP packets; they = aren't IP packets.  Does that mean it's always a DHCP relay?  = That would help.  The boxes have to change, but if they are = already doing DHCP relay, adding the location option would be the least = amount of work.

I keep hoping I've missed something here.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, April 20, 2005 3:48 PM
> To: Brian Rosen
> Cc: 'Michael Hammer (mhammer)'; = peter_blatherwick@mitel.com; 'GEOPRIV
> WG'; ecrit@ietf.org
> Subject: Re: [Ecrit] RE: [Geopriv] Announcement = of Joint GEOPRIV/ECRIT
> InterimMeeting
>
> There are at least two separate sets of issues = that depend on the
> architecture, and it seems dangerous to = conflate the two:
>
> (First-person) I get my own location from a = server. This makes address
> spoofing more difficult, with return = routability. Drawback: If I'm
> behind a NAT, and the location server isn't, = this works only if the IP
> address in the IP packet is used, not something = in the query. VPNs
> should not be a big deal here.
>
> (Third-person) I ask for an address for an IP = address. Address
> spoofing and VPN issues matter, possibly NAT = issues (since the IP
> address I get may be a NAT address, given the = typical circles of NAT
> hell in various
> networks.)
>
> I think first-person is much more palatable = than third-person.
>
> Brian Rosen wrote:
> > "Routing" in this context is = session (SIP) routing, as you
> > suspected.
> >
> > The first hop (LIS to endpoint) is what we = are discussing. DHCP is
> > not an L3+ protocol.  Neither is = LLDP-MED.
> >
> > The thread has discussed a number of = problems with an L7 mechanism,
> > but laying them out:
> >
> > 1. You are subject to IP address spoofing = (albeit you need to be
> > able to
> get
> > the packets sent from the LIS to the IP = address you are spoofing)
> >
> > 2. VPN or other tunnels may have been = created before you run this
> protocol.
> > That will cause a failure; you need the = location corresponding to
> > the original "outermost" IP = address.
> >
> > 3. It is difficult to control the security = (beyond IP spoofing)
> > because
> you
> > don't have a generally good authentication = mechanism.  This is a
> > bare
> phone,
> > or equivalent, during its boot = phase.
> >
> > There are probably others as well.  = 2) is the real problem.
> >
> > Brian
>




_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C54612.28B76370-- --===============0034785235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0034785235==-- From ecrit-bounces@ietf.org Wed Apr 20 21:35:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQbT-0008Ef-Ta; Wed, 20 Apr 2005 21:35:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQbT-0008EX-BL; Wed, 20 Apr 2005 21:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18423; Wed, 20 Apr 2005 21:35:37 -0400 (EDT) Message-Id: <200504210135.VAA18423@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQmo-0007ho-4U; Wed, 20 Apr 2005 21:47:22 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOQbJ-0006Ww-45; Wed, 20 Apr 2005 20:35:29 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 21:35:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4267017B.2090809@cs.columbia.edu> Thread-Index: AcVGEVCRkaxKRVdEQcyMmL9zHu3W4AAAJF2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, there are quite a few ways that DSL systems work, and they don't always use PPP. It would work for many deployments, but not all. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 20, 2005 9:27 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV WG'; > ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > Brian Rosen wrote: > > > > DSL doesn't use DHCP between the router/DSL modem and the DSL network to > get > > IP address, and they don't want to use DHCP for location. They could > use > > Since they use PPPoE and assign addresses using PPP, couldn't they just > add a location option to PPP, in the same format as for DHCP? > > It already conveys other information, such as the DNS server. > > (http://www.networksorcery.com/enp/protocol/IPCP.htm) > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 21:40:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQfj-00009z-7K; Wed, 20 Apr 2005 21:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQfh-00009l-Fu; Wed, 20 Apr 2005 21:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18791; Wed, 20 Apr 2005 21:39:59 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQr2-0007oa-9t; Wed, 20 Apr 2005 21:51:44 -0400 Received: from [127.0.0.1] (IDENT:U2FsdGVkX186UNhdsUwkcsgYz0bQqqSHu3jBlFRT5/A@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3L1dth3028775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 21:39:56 -0400 (EDT) Message-ID: <42670459.9010905@cs.columbia.edu> Date: Wed, 20 Apr 2005 21:39:37 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <200504210135.j3L1ZZqt007209@cs.columbia.edu> In-Reply-To: <200504210135.j3L1ZZqt007209@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Actually, there are quite a few ways that DSL systems work, and they don't > always use PPP. It would work for many deployments, but not all. I've only seen DHCP or PPP (for PPPoE) systems for IP address assignment in DSL. What else is there? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 20 21:46:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQlb-0001F2-GR; Wed, 20 Apr 2005 21:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQlZ-0001Eu-SQ; Wed, 20 Apr 2005 21:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19282; Wed, 20 Apr 2005 21:46:04 -0400 (EDT) Message-Id: <200504210146.VAA19282@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQwu-0007yf-51; Wed, 20 Apr 2005 21:57:48 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOQlM-0007Va-BK; Wed, 20 Apr 2005 20:45:53 -0500 From: "Brian Rosen" To: "'James Winterbottom'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Wed, 20 Apr 2005 21:45:45 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVGEkkeKe7oHjr7Sh2wfEgfYBwkYgAAHsMw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.6 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053526964==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1053526964== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01C545F2.4F74BD20" This is a multi-part message in MIME format. ------=_NextPart_000_0116_01C545F2.4F74BD20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The box can run the protocol, be it layer 2 or 7 any time; it has access to the uplink. A downstream endpoint can't do that. It can't get location before the tunnel is created because the box doesn't pass traffic until the tunnel is created. The problem we're discussing is something like an IPsec appliance; a box physically between the uplink and the local LAN that creates the tunnel when it initializes and doesn't allow any traffic other than that which goes through the tunnel. There are variations on such boxes; you can configure some of them to allow access outside the tunnel for some things. Most of them, I'm told, are DHCP relays at least. Brian _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Wednesday, April 20, 2005 9:34 PM To: Brian Rosen; 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I think that you are missing something here. You are making the assumption that L7 is only used to retrieve location after the VPN tunnel has been established, I fail to see why this has to be the case. It could just as easily be retrieved from the local network prior to the tunnel being established and so this presents no more difficulty for VPNs and softclients than a layer 2 delivered solution. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 6:19 AM To: 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I'm having some off line discussions that lead me to the following: If you have a box that opens a VPN tunnel on the raw Internet connection that feeds a LAN that has endpoints, and passes ALL LAN traffic through the tunnel, you are hosed. The box has to be location aware in some way. This is because there is no way, L2 or L7, that you can get a packet to anything that knows about the location; the box is forcing everything through the tunnel. The box is physically between the uplink and the LAN, and you can't go around it. The box has to do something that lets you get at the right LIS. If the box supplies IP addresses (it's the DHCP server), then it only has to relay the location option. If the box doesn't supply addresses, it would have to run something that either the client could access, or something the DHCP server would access. We have no solutions. L7 doesn't help; the box has to do something that would allow you to get to the local LIS, with the boxe's public IP address. Softclients are much easier, because the system can get location before the tunnel is established. Tunnels downstream of the local infrastructure are problematic for L7, but not for L2. This is bad news. All the boxes have to change. If we have to change all the softclients for L7, is that a big enough reason to not use L7? Hmmm. I don't know enough about how the boxes work. To make DHCP work with the DHCP server in the corporate network, not in the box, the box has to pass the DHCP packets; they aren't IP packets. Does that mean it's always a DHCP relay? That would help. The boxes have to change, but if they are already doing DHCP relay, adding the location option would be the least amount of work. I keep hoping I've missed something here. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 20, 2005 3:48 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV > WG'; ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > There are at least two separate sets of issues that depend on the > architecture, and it seems dangerous to conflate the two: > > (First-person) I get my own location from a server. This makes address > spoofing more difficult, with return routability. Drawback: If I'm > behind a NAT, and the location server isn't, this works only if the IP > address in the IP packet is used, not something in the query. VPNs > should not be a big deal here. > > (Third-person) I ask for an address for an IP address. Address > spoofing and VPN issues matter, possibly NAT issues (since the IP > address I get may be a NAT address, given the typical circles of NAT > hell in various > networks.) > > I think first-person is much more palatable than third-person. > > Brian Rosen wrote: > > "Routing" in this context is session (SIP) routing, as you > > suspected. > > > > The first hop (LIS to endpoint) is what we are discussing. DHCP is > > not an L3+ protocol. Neither is LLDP-MED. > > > > The thread has discussed a number of problems with an L7 mechanism, > > but laying them out: > > > > 1. You are subject to IP address spoofing (albeit you need to be > > able to > get > > the packets sent from the LIS to the IP address you are spoofing) > > > > 2. VPN or other tunnels may have been created before you run this > protocol. > > That will cause a failure; you need the location corresponding to > > the original "outermost" IP address. > > > > 3. It is difficult to control the security (beyond IP spoofing) > > because > you > > don't have a generally good authentication mechanism. This is a > > bare > phone, > > or equivalent, during its boot phase. > > > > There are probably others as well. 2) is the real problem. > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0116_01C545F2.4F74BD20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting

The box can run the protocol, be it = layer 2 or 7 any time; it has access to the = uplink.

A downstream endpoint can’t = do that.  It can’t get location before the tunnel is created = because the box doesn’t pass traffic until the tunnel is = created.

The problem we’re discussing = is something like an IPsec appliance; a box physically between the uplink = and the local LAN that creates the tunnel when it initializes and doesn’t = allow any traffic other than that which goes through the tunnel.  There = are variations on such boxes; you can configure some of them to allow access outside the tunnel for some things.  Most of them, I’m told, = are DHCP relays at least.

 

Brian

 

From: = James Winterbottom = [mailto:winterb@nortel.com]
Sent: Wednesday, April = 20, 2005 9:34 PM
To: Brian Rosen; 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; = ecrit@ietf.org
Subject: RE: [Ecrit] RE: = [Geopriv] Announcement of Joint GEOPRIV/ECRIT = InterimMeeting

 

I think that you are missing something here.
You are making the = assumption that L7 is only used to retrieve location after the VPN tunnel has been = established, I fail to see why this has to be the case. It could just as easily be = retrieved from the local network prior to the tunnel being established and so this presents no more difficulty for VPNs and softclients than a layer 2 = delivered solution.

 

-----Original Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Brian Rosen
Sent: Thursday, 21 April = 2005 6:19 AM
To: 'Henning = Schulzrinne'
Cc: 'GEOPRIV WG'; = ecrit@ietf.org
Subject: RE: [Ecrit] RE: = [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting =

 

I'm having some off line discussions that lead me to the = following:

If you have a box that opens a VPN tunnel on the raw Internet connection that = feeds a LAN that has endpoints, and passes ALL LAN traffic through the tunnel, = you are hosed.  The box has to be location aware in some way.  This is because there is no way, L2 or L7, that you can get a packet to anything = that knows about the location; the box is forcing everything through the = tunnel.  The box is physically between the uplink and the LAN, and you can't go = around it.  The box has to do something that lets you get at the right = LIS.

If the box supplies IP addresses (it's the DHCP server), then it only has to = relay the location option.

If the box doesn't supply addresses, it would have to run something that either = the client could access, or something the DHCP server would access. We have = no solutions.

L7 doesn't help; the box has to do something that would allow you to get to = the local LIS, with the boxe's public IP = address.

Softclients are much easier, because the system can get location before the tunnel = is established.  Tunnels downstream of the local infrastructure are problematic for L7, but not for L2.

This is bad news.  All the boxes have to change.  If we have to change = all the softclients for L7, is that a big enough reason to not use = L7?

Hmmm.  I don't know enough about how the boxes work.  To make DHCP work = with the DHCP server in the corporate network, not in the box, the box has to = pass the DHCP packets; they aren't IP packets.  Does that mean it's always a = DHCP relay?  That would help.  The boxes have to change, but if = they are already doing DHCP relay, adding the location option would be the least = amount of work.

I keep hoping I've missed something here.

Brian

> -----Original Message-----
> From: Henning = Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, = April 20, 2005 3:48 PM
> To: Brian = Rosen
> Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV
> WG'; = ecrit@ietf.org
> Subject: Re: = [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> = InterimMeeting
>
> There are at least = two separate sets of issues that depend on the
> architecture, and = it seems dangerous to conflate the two:
>
> (First-person) I = get my own location from a server. This makes address
> spoofing more = difficult, with return routability. Drawback: If I'm
> behind a NAT, and = the location server isn't, this works only if the IP
> address in the IP = packet is used, not something in the query. VPNs
> should not be a big = deal here.
>
> (Third-person) I = ask for an address for an IP address. Address
> spoofing and VPN = issues matter, possibly NAT issues (since the IP
> address I get may = be a NAT address, given the typical circles of NAT
> hell in = various
> = networks.)
>
> I think = first-person is much more palatable than third-person.
>
> Brian Rosen = wrote:
> > = "Routing" in this context is session (SIP) routing, as you
> > = suspected.
> > =
> > The first hop = (LIS to endpoint) is what we are discussing. DHCP is
> > not an L3+ protocol.  Neither is LLDP-MED.
> > =
> > The thread has = discussed a number of problems with an L7 mechanism,
> > but laying = them out:
> > =
> > 1. You are = subject to IP address spoofing (albeit you need to be
> > able = to
> get =
> > the packets = sent from the LIS to the IP address you are spoofing)
> > =
> > 2. VPN or = other tunnels may have been created before you run this
> = protocol.
> > That will = cause a failure; you need the location corresponding to
> > the original "outermost" IP address.
> > =
> > 3. It is = difficult to control the security (beyond IP spoofing)
> > = because
> you =
> > don't have a = generally good authentication mechanism.  This is a
> > = bare
> = phone,
> > or equivalent, = during its boot phase.
> > =
> > There are = probably others as well.  2) is the real problem.
> > =
> > = Brian
> =



______________________________________________= _
Ecrit mailing = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=

------=_NextPart_000_0116_01C545F2.4F74BD20-- --===============1053526964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1053526964==-- From ecrit-bounces@ietf.org Wed Apr 20 21:50:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQpO-0001eS-W7; Wed, 20 Apr 2005 21:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQpN-0001eG-Ia; Wed, 20 Apr 2005 21:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19505; Wed, 20 Apr 2005 21:49:59 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOR0h-00082u-Lw; Wed, 20 Apr 2005 22:01:44 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3L1nLe04506; Wed, 20 Apr 2005 20:49:22 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 11:48:31 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Int erimMeeting Date: Thu, 21 Apr 2005 11:48:31 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.7 (/) X-Scan-Signature: 5f85cf2baaf973610992c2604e7b6057 Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1827227150==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1827227150== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54614.38AA1CD0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54614.38AA1CD0 Content-Type: text/plain Thanks for the clarification, allow me to stew on this one a bit. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, 21 April 2005 11:46 AM To: Winterbottom, James [WOLL:5500:EXCH]; 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting The box can run the protocol, be it layer 2 or 7 any time; it has access to the uplink. A downstream endpoint can't do that. It can't get location before the tunnel is created because the box doesn't pass traffic until the tunnel is created. The problem we're discussing is something like an IPsec appliance; a box physically between the uplink and the local LAN that creates the tunnel when it initializes and doesn't allow any traffic other than that which goes through the tunnel. There are variations on such boxes; you can configure some of them to allow access outside the tunnel for some things. Most of them, I'm told, are DHCP relays at least. Brian _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Wednesday, April 20, 2005 9:34 PM To: Brian Rosen; 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I think that you are missing something here. You are making the assumption that L7 is only used to retrieve location after the VPN tunnel has been established, I fail to see why this has to be the case. It could just as easily be retrieved from the local network prior to the tunnel being established and so this presents no more difficulty for VPNs and softclients than a layer 2 delivered solution. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org ] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 6:19 AM To: 'Henning Schulzrinne' Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting I'm having some off line discussions that lead me to the following: If you have a box that opens a VPN tunnel on the raw Internet connection that feeds a LAN that has endpoints, and passes ALL LAN traffic through the tunnel, you are hosed. The box has to be location aware in some way. This is because there is no way, L2 or L7, that you can get a packet to anything that knows about the location; the box is forcing everything through the tunnel. The box is physically between the uplink and the LAN, and you can't go around it. The box has to do something that lets you get at the right LIS. If the box supplies IP addresses (it's the DHCP server), then it only has to relay the location option. If the box doesn't supply addresses, it would have to run something that either the client could access, or something the DHCP server would access. We have no solutions. L7 doesn't help; the box has to do something that would allow you to get to the local LIS, with the boxe's public IP address. Softclients are much easier, because the system can get location before the tunnel is established. Tunnels downstream of the local infrastructure are problematic for L7, but not for L2. This is bad news. All the boxes have to change. If we have to change all the softclients for L7, is that a big enough reason to not use L7? Hmmm. I don't know enough about how the boxes work. To make DHCP work with the DHCP server in the corporate network, not in the box, the box has to pass the DHCP packets; they aren't IP packets. Does that mean it's always a DHCP relay? That would help. The boxes have to change, but if they are already doing DHCP relay, adding the location option would be the least amount of work. I keep hoping I've missed something here. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu ] > Sent: Wednesday, April 20, 2005 3:48 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV > WG'; ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > There are at least two separate sets of issues that depend on the > architecture, and it seems dangerous to conflate the two: > > (First-person) I get my own location from a server. This makes address > spoofing more difficult, with return routability. Drawback: If I'm > behind a NAT, and the location server isn't, this works only if the IP > address in the IP packet is used, not something in the query. VPNs > should not be a big deal here. > > (Third-person) I ask for an address for an IP address. Address > spoofing and VPN issues matter, possibly NAT issues (since the IP > address I get may be a NAT address, given the typical circles of NAT > hell in various > networks.) > > I think first-person is much more palatable than third-person. > > Brian Rosen wrote: > > "Routing" in this context is session (SIP) routing, as you > > suspected. > > > > The first hop (LIS to endpoint) is what we are discussing. DHCP is > > not an L3+ protocol. Neither is LLDP-MED. > > > > The thread has discussed a number of problems with an L7 mechanism, > > but laying them out: > > > > 1. You are subject to IP address spoofing (albeit you need to be > > able to > get > > the packets sent from the LIS to the IP address you are spoofing) > > > > 2. VPN or other tunnels may have been created before you run this > protocol. > > That will cause a failure; you need the location corresponding to > > the original "outermost" IP address. > > > > 3. It is difficult to control the security (beyond IP spoofing) > > because > you > > don't have a generally good authentication mechanism. This is a > > bare > phone, > > or equivalent, during its boot phase. > > > > There are probably others as well. 2) is the real problem. > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C54614.38AA1CD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Thanks=20 for the clarification, allow me to stew on this one a = bit.
 
Cheers
James
-----Original Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Thursday, 21 April 2005 = 11:46=20 AM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Henning=20 Schulzrinne'
Cc: 'GEOPRIV WG'; = ecrit@ietf.org
Subject: RE:=20 [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT=20 InterimMeeting

The box = can run the=20 protocol, be it layer 2 or 7 any time; it has access to the=20 uplink.

A = downstream endpoint=20 can't do that.  It can't get location before the tunnel is = created=20 because the box doesn't pass traffic until the tunnel is=20 created.

The = problem we're=20 discussing is something like an IPsec appliance; a box physically = between the=20 uplink and the local LAN that creates the tunnel when it initializes = and=20 doesn't allow any traffic other than that which goes through the = tunnel. =20 There are variations on such boxes; you can configure some of them to = allow=20 access outside the tunnel for some things.  Most of them, I'm = told, are=20 DHCP relays at least.

 

Brian

 

From:=20 James Winterbottom = [mailto:winterb@nortel.com]=20
Sent: Wednesday, = April 20,=20 2005 9:34 PM
To: = Brian Rosen;=20 'Henning Schulzrinne'
Cc:=20 'GEOPRIV WG'; ecrit@ietf.org
Subject: RE: [Ecrit] RE: = [Geopriv]=20 Announcement of Joint GEOPRIV/ECRIT=20 InterimMeeting

 

I think=20 that you are missing something here.
You are making the assumption that L7 is = only used to=20 retrieve location after the VPN tunnel has been established, I fail = to see why=20 this has to be the case. It could just as easily be retrieved from = the local=20 network prior to the tunnel being established and so this presents no = more=20 difficulty for VPNs and softclients than a layer 2 delivered=20 solution.

 

-----Original Message----- =
From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org= ] On=20 Behalf Of Brian Rosen
Sent: Thursday, 21 April 2005 6:19 = AM=20
To: 'Henning=20 Schulzrinne'
Cc:=20 'GEOPRIV WG'; ecrit@ietf.org
Subject: RE: [Ecrit] RE: [Geopriv] = Announcement of=20 Joint GEOPRIV/ECRIT InterimMeeting

 

I'm=20 having some off line discussions that lead me to the = following:=20

If you=20 have a box that opens a VPN tunnel on the raw Internet connection = that feeds a=20 LAN that has endpoints, and passes ALL LAN traffic through the = tunnel, you are=20 hosed.  The box has to be location aware in some way.  This = is=20 because there is no way, L2 or L7, that you can get a packet to = anything that=20 knows about the location; the box is forcing everything through the=20 tunnel.  The box is physically between the uplink and the LAN, = and you=20 can't go around it.  The box has to do something that lets you = get at the=20 right LIS.

If the=20 box supplies IP addresses (it's the DHCP server), then it only has to = relay=20 the location option.

If the=20 box doesn't supply addresses, it would have to run something that = either the=20 client could access, or something the DHCP server would access. We = have no=20 solutions.

L7=20 doesn't help; the box has to do something that would allow you to get = to the=20 local LIS, with the boxe's public IP = address.

Softclients are much easier, because the = system can=20 get location before the tunnel is established.  Tunnels = downstream of the=20 local infrastructure are problematic for L7, but not for=20 L2.

This is=20 bad news.  All the boxes have to change.  If we have to = change all=20 the softclients for L7, is that a big enough reason to not use=20 L7?

Hmmm.  I don't know enough about how = the boxes=20 work.  To make DHCP work with the DHCP server in the corporate = network,=20 not in the box, the box has to pass the DHCP packets; they aren't IP=20 packets.  Does that mean it's always a DHCP relay?  That = would=20 help.  The boxes have to change, but if they are already doing = DHCP=20 relay, adding the location option would be the least amount of=20 work.

I keep=20 hoping I've missed something here.

Brian

>=20 -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
> Sent: = Wednesday, April 20,=20 2005 3:48 PM
>=20 To: Brian Rosen
> Cc: 'Michael Hammer (mhammer)';=20 peter_blatherwick@mitel.com; 'GEOPRIV
> WG'; ecrit@ietf.org =
> Subject: Re: [Ecrit] = RE: [Geopriv]=20 Announcement of Joint GEOPRIV/ECRIT
> InterimMeeting
>
> There are at least two separate sets = of issues=20 that depend on the
> architecture, and it seems dangerous = to conflate=20 the two:
>=20
> = (First-person) I get my own location from a server. This makes = address=20
> = spoofing=20 more difficult, with return routability. Drawback: If I'm=20
> = behind a=20 NAT, and the location server isn't, this works only if the IP=20
> = address in=20 the IP packet is used, not something in the query. VPNs=20
> = should not=20 be a big deal here.
>
> (Third-person) I ask for an address = for an IP=20 address. Address
> spoofing and VPN issues matter, = possibly NAT=20 issues (since the IP
> address I get may be a NAT address, = given the=20 typical circles of NAT
> hell in various =
> = networks.)
>
> I think first-person is much more = palatable than=20 third-person.
>
> Brian Rosen wrote: =
> > "Routing" in this = context is=20 session (SIP) routing, as you
> > suspected. =
> > =
> > The first hop (LIS = to endpoint)=20 is what we are discussing. DHCP is
> > not an L3+ protocol.  = Neither is=20 LLDP-MED.
>=20 >
> >=20 The thread has discussed a number of problems with an L7 mechanism,=20
> = > but=20 laying them out:
> >
> > 1. You are subject to IP address = spoofing=20 (albeit you need to be
> > able to
> get
> > the packets sent from the LIS to = the IP=20 address you are spoofing)
> >
> > 2. VPN or other tunnels may have = been=20 created before you run this
> protocol.
> > That will cause a failure; you = need the=20 location corresponding to
> > the original "outermost" IP=20 address.
>=20 >
> > 3.=20 It is difficult to control the security (beyond IP spoofing)=20
> = >=20 because
>=20 you
> >=20 don't have a generally good authentication mechanism.  This is a =
> = >=20 bare
>=20 phone,
> >=20 or equivalent, during its boot phase.
> >
> > There are probably others as = well.  2)=20 is the real problem.
> >
> > Brian
>



_______________________________________________=20
Ecrit mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit<= /FONT>=20

------_=_NextPart_001_01C54614.38AA1CD0-- --===============1827227150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1827227150==-- From ecrit-bounces@ietf.org Wed Apr 20 23:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOSbz-00044b-4k; Wed, 20 Apr 2005 23:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOSbx-00044H-9T; Wed, 20 Apr 2005 23:44:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26827; Wed, 20 Apr 2005 23:44:14 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOSnH-0001oc-Qu; Wed, 20 Apr 2005 23:56:01 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 21 Apr 2005 09:22:53 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,118,1112553000"; d="scan'208"; a="30639291:sNHT25057180" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3L9Cqlx019249; Thu, 21 Apr 2005 09:12:53 GMT Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA23738; Wed, 20 Apr 2005 20:43:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20050420223753.02997d48@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Apr 2005 22:44:00 -0500 To: GEOPRIV WG , ecrit@ietf.org From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: Subject: [Ecrit] Terms on this thread X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Suggesting term changes: "Location Delivery" is to the endpoint (the first time or a refresh) "Location Conveyance" is from the endpoint (to the LIS, the Proxy or to the PSAP) "Location Conveyance" is already the term/phrase used in SIP(PING) for a UA to convey its location to another UA or Proxy, per: http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-02.txt so the term/phrase seems to be appropriate here Delivery IN Conveyance OUT both from the endpoint's point of view agreed? we can worry about non-proxy server to server lateral movement when that issue comes up At 01:03 PM 4/20/2005 -0400, Abbott, Nadine B. wrote: >Mike, >You are right--it is being used in two different contexts. >Delivery of location to the endpoint and delivery of location to the PSAP. >We need different terms or we need to qualify the term when we use it (as >above). >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Michael Hammer (mhammer) >Sent: Wednesday, April 20, 2005 12:00 PM >To: Brian Rosen; peter_blatherwick@mitel.com >Cc: GEOPRIV WG; ecrit@ietf.org >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT >InterimMeeting > > >I still get the feeling that "delivery" is being used in two different >contexts: > > (1) (2) >Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) > >How can "delivery" be L2 dependent, when it must reach a PSAP many hops >away? Color me confused. > >Mike > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL provider. > >The domain is then that of the DSL vendor. Your phone asks for its > >location from the server in the DSL domain. It would be given the > >location corresponding to the IP address of the request. Note that > >this would be pretty good for the requested case, even in the presence > >of a NATed local area network in your home. The phone would do this on > >boot, before any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. > >I'm skeptical we can do that because of the security issues. > >When you make the delivery mechanism L2 dependent, you can > >control the possible attacks to a finer grain than the L7 local domain. > > > >Please keep in mind that some of the folks wishing to use the > >L7 mechanism don't really want to just return location to the > >endpoint; they want to retain the location and give it out to > >authorized entities upon presentation of the IP address of the > >endpoint. That is a business decision. They can charge for > >such a service. I think the privacy implications of that are > >dicey, but the reality is that's the model that will probably > >be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would > >> seem that location delivery would need to be cross-domain. The E911 > >> PSAP will not always be the same domain as the roaming endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the > >> fact that L2 is supposed to be a single physical hop at most between > >> the end- user terminal and an adjacent location-determining network > >> node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to > >> rely on location information, a general purpose delivery mechanism > >> will provide consistency and generality that is so often sought in > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local, > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem, > >> >which I fear is leading to Balkanization. There are two really > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are L2 > >> >specific. They claim as long as you have an L2 specific mechanism, > >> >you need one or more for each L2. To get out of that, they propose > >> >that we use an L7 mechanism (think some version of HTTP, although > >> >that might not fly). They would say, lets do that once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the > >> >security issues of an L7 mechanism, and in particular, you have to > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take > >> >anti-spoofing steps. They note that the mechanism would need at > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security, > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that, > >> >how do we construct a signature from the entity that actually > >> >determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > >> >Behalf Of peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> > " > >> > 2) Properties of network elements in transferring LI from layer 2 > >> > upward to PIDF-LO. > >> > 3) Proposed enhancements to PIDF-LO to support #2. > >> > " > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from the > >> >L2 LAN infrastructure they are connected to. The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. In LLDP-MED, among several other things, we have > >> >specified ways to pass equivalent data to the DHCP coordinate-based > >> >LCI (RFC 3825) and civic location LCI > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS > >> >system (the endpoint receives the exact same data), which has some > >> >advantages particularly in enterprise deployment scenarios. (The > >> >DHCP-based method has advantages in different scenarios.) I am > >> >Editor of thi s document, and it is now in ballot process in TIA > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last > >> >Call and in the RFC Editor's queue? It seemed to have been settled > >> >on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> > To: GEOPRIV WG > >> > cc: > >> > Subject: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> > What: Interim GEOPRIV/ECRIT meeting > >> > When: 2005 May 16 08:30-17:30 > >> > 2005 May 17 08:30-17:30 > >> > 2005 May 18 08:30-17:30 > >> > Where: Columbia University > >> > Dept. of Computer Science > >> > 450 Computer Science Bldg. > >> > 1214 Amsterdam Avenue (close to 120th St.) > >> > New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> > Also: WiFi provided. > >> > Teleconference to be provided. > >> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> > Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 21 07:46:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOa88-0003BJ-UT; Thu, 21 Apr 2005 07:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQKX-0006M0-GA; Wed, 20 Apr 2005 21:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17302; Wed, 20 Apr 2005 21:18:07 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQVq-0007Lf-KP; Wed, 20 Apr 2005 21:29:52 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3L1Hse01604; Wed, 20 Apr 2005 20:17:55 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 11:16:49 +1000 Message-ID: From: "James Winterbottom" To: Marc Linsner Date: Thu, 21 Apr 2005 11:16:49 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.4 (/) X-Scan-Signature: e2a224a4445e6ba88c508264e796c05d X-Mailman-Approved-At: Thu, 21 Apr 2005 07:45:58 -0400 Cc: 'GEOPRIV WG' , ecrit@ietf.org Subject: [Ecrit] RE: L2 vs. L7 Location Discover X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0819552242==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0819552242== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5460F.C816767A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5460F.C816767A Content-Type: text/plain Hi Marc, I am recommending, I think, that we introduce one mechanism now, that tells us how to get a location. I can think of several things and ways to do this, include one time URLs. If this is done right, that is it is a pointer to a location object, then the location can change and evolve, without us needing to change the underlying layer 2 mechanism to transport it. I am not saying that changes to L2 protocols are not required to make the initial support possible, what I am saying is that an evolution of those changes to support new location types will not be required. Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, 21 April 2005 9:30 AM To: Winterbottom, James [WOLL:5500:EXCH] Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: L2 vs. L7 Location Discover .....subject changed to more accurately reflect topic....... James, Since an argument for L7 location discovery architecture is no changes needed to the myriad of L2 mechanisms, what are you proposing to use for a key? -Marc- Hmmmm!!! I am not sure that I agree your statement that the key passed to external would be the IP address of the client. It could be, but I would most certainly not advocate that. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org ] On Behalf Of Brian Rosen Sent: Thursday, 21 April 2005 2:13 AM To: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com Cc: 'GEOPRIV WG'; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting The basic picture is: LIS ---> endpoint ---> routing element ---> psap The LIS knows where the endpoint is. The endpoint gets location from the LIS The endpoint includes location on the emergency call The routing element uses location to route the call to the right PSAP The PSAP gets the call, and the location. The discussion is, how does the endpoint get location from the LIS? DHCP is one answer. LLDP-MED is another. A proposed L7 mechanism is another. To be sure, there are folks who want to make the picture: LIS --> endpoint --> routing element ---> psap ^ | | | | | +------------------------+ | | | +------------------------------------------+ The LIS gives the endpoint a "key" The endpoint includes the key in the emergency call The routing element gets the key and exchanges it for location at the LIS The psap gets the key and exchanges it for location at the LIS The key could be an IP address. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com ] > Sent: Wednesday, April 20, 2005 12:00 PM > To: Brian Rosen; peter_blatherwick@mitel.com > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > I still get the feeling that "delivery" is being used in two different > contexts: > > (1) (2) > Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) > > How can "delivery" be L2 dependent, when it must reach a PSAP many > hops away? Color me confused. > > Mike > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net ] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL > >provider. The domain is then that of the DSL vendor. Your phone asks > >for its location from the server in the DSL domain. It would be > >given the location corresponding to the IP address of the request. > >Note that this would be pretty good for the requested case, even in > >the presence of a NATed local area network in your home. The phone > >would do this on boot, before any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. I'm > >skeptical we can do that because of the security issues. When you > >make the delivery mechanism L2 dependent, you can control the > >possible attacks to a finer grain than the L7 local domain. > > > >Please keep in mind that some of the folks wishing to use the L7 > >mechanism don't really want to just return location to the endpoint; > >they want to retain the location and give it out to authorized > >entities upon presentation of the IP address of the endpoint. That > >is a business decision. They can charge for such a service. I think > >the privacy implications of that are dicey, but the reality is that's > >the model that will probably be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com ] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would > >> seem that location delivery would need to be cross-domain. The > >> E911 PSAP will not always be the same domain as the roaming > >> endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the > >> fact that L2 is supposed to be a single physical hop at most > >> between the end- user terminal and an adjacent location-determining > >> network node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to > >> rely on location information, a general purpose delivery mechanism > >> will provide consistency and generality that is so often sought in > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local, > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org ] On > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem, > >> >which I fear is leading to Balkanization. There are two really > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are > >> >L2 specific. They claim as long as you have an L2 specific > >> >mechanism, you need one or more for each L2. To get out of that, > >> >they propose that we use an L7 mechanism (think some version of > >> >HTTP, although that might not fly). They would say, lets do that > >> >once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the > >> >security issues of an L7 mechanism, and in particular, you have to > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take > >> >anti-spoofing steps. They note that the mechanism would need at > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security, > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from > >> >that, how do we construct a signature from the entity that > >> >actually determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org ] > >> >On Behalf Of peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> > " > >> > 2) Properties of network elements in transferring LI from layer > >> >2 > >> > upward to PIDF-LO. > >> > 3) Proposed enhancements to PIDF-LO to support #2. > >> > " > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from > >> >the L2 LAN infrastructure they are connected to. The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. In LLDP-MED, among several other things, we have > >> >specified ways to pass equivalent data to the DHCP > >> >coordinate-based LCI (RFC 3825) and civic location LCI > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS > >> >system (the endpoint receives the exact same data), which has some > >> >advantages particularly in enterprise deployment scenarios. (The > >> >DHCP-based method has advantages in different scenarios.) I am > >> >Editor of thi s document, and it is now in ballot process in TIA > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last > >> >Call and in the RFC Editor's queue? It seemed to have been > >> >settled on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> > To: GEOPRIV WG > >> > cc: > >> > Subject: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> > What: Interim GEOPRIV/ECRIT meeting > >> > When: 2005 May 16 08:30-17:30 > >> > 2005 May 17 08:30-17:30 > >> > 2005 May 18 08:30-17:30 > >> > Where: Columbia University > >> > Dept. of Computer Science > >> > 450 Computer Science Bldg. > >> > 1214 Amsterdam Avenue (close to 120th St.) > >> > New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> > Also: WiFi provided. > >> > Teleconference to be provided. > >> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> > Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C5460F.C816767A Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 Marc,
 
I am=20 recommending, I think, that we introduce one mechanism now, that tells = us how to=20 get a location.
I can=20 think of several things and ways to do this, include one time URLs. If = this is=20 done right, that is it is a pointer to a location object, then the = location can=20 change and evolve, without us needing to change the underlying layer 2 = mechanism=20 to transport it. I am not saying that changes to L2 protocols are not = required=20 to make the initial support possible, what I am saying is that an = evolution of=20 those changes to support new location types will not be=20 required.
 
Cheers
James
-----Original Message-----
From: = Marc Linsner=20 [mailto:mlinsner@cisco.com]
Sent: Thursday, 21 April 2005 = 9:30=20 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: = 'GEOPRIV=20 WG'; ecrit@ietf.org
Subject: L2 vs. L7 Location=20 Discover

.....subject changed to=20 more accurately reflect topic.......

 

James,

 

Since an = argument for=20 L7 location discovery architecture is no changes needed to the myriad = of L2=20 mechanisms, what are you proposing to use for a=20 key?

 

-Marc-

 

 

 

 

Hmmmm!!!

I am not=20 sure that I agree your statement that the key passed to external = would be the=20 IP address of the client. It could be, but I would most certainly not = advocate=20 that.

 

 

-----Original Message----- =
From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org= ] On=20 Behalf Of Brian Rosen
Sent: Thursday, 21 April 2005 2:13 = AM=20
To: 'Michael = Hammer (mhammer)';=20 peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; = ecrit@ietf.org=20
Subject: RE: = [Ecrit] RE:=20 [Geopriv] Announcement of Joint GEOPRIV/ECRIT = InterimMeeting=20

 

The basic=20 picture is:

LIS=20 ---> endpoint ---> routing element ---> psap=20

The LIS=20 knows where the endpoint is.
The endpoint gets location from the = LIS=20
The endpoint = includes location=20 on the emergency call
The routing element uses location to route = the call to=20 the right PSAP The PSAP gets the call, and the = location.=20

The=20 discussion is, how does the endpoint get location from the LIS? DHCP = is one=20 answer.  LLDP-MED is another.  A proposed L7 mechanism is=20 another.

 

To be=20 sure, there are folks who want to make the picture:=20

LIS=20 --> endpoint --> routing element ---> psap =
 ^          = ;            = ; =20 = |            = ;    =20 |
 |          = ;            = ; =20 = |            = ;    =20 |
 +------------------------+     &nbs= p;          =20 |
 |          = ;            = ;            = ;       =20 |
 +------------------------------------------+=20

The LIS=20 gives the endpoint a "key"
The endpoint includes the key in the = emergency=20 call
The routing=20 element gets the key and exchanges it for location at the LIS The = psap gets=20 the key and exchanges it for location at the = LIS

The key=20 could be an IP address.

Brian

 

>=20 -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20
> Sent: = Wednesday, April 20,=20 2005 12:00 PM
> To: Brian Rosen;=20 peter_blatherwick@mitel.com
> Cc: GEOPRIV WG; = ecrit@ietf.org=20
> Subject: RE: = [Ecrit] RE:=20 [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> = InterimMeeting=20
> =
> I still get the feeling = that=20 "delivery" is being used in two different
> contexts:
>
>          &n= bsp; =20 = (1)           &nb= sp;        =20 (2)
> Local=20 node---?---->endpoint-----/many hops/----->PSAP =
>          =20 ---------------------/many hops/----->
>          &n= bsp;           &n= bsp;    =20 (2)
>=20
> = How can=20 "delivery" be L2 dependent, when it must reach a PSAP many=20
> = hops away?=20 Color me confused.
>
> Mike
>
>
> >-----Original = Message-----=20
> >From: = Brian Rosen [mailto:br@brianrosen.net]=20
> >Sent: = Wednesday, April=20 20, 2005 10:47 AM
> >To: Michael Hammer (mhammer);=20 peter_blatherwick@mitel.com
> >Cc: 'GEOPRIV WG';=20 ecrit@ietf.org
> >Subject: RE: [Ecrit] RE: [Geopriv] = Announcement of Joint
> >GEOPRIV/ECRIT = InterimMeeting=20
> = >=20
> >The idea = is that, say,=20 you are in your home, served by a DSL
> >provider. The domain is then that = of the DSL=20 vendor.  Your phone asks
> >for its location from the server = in the DSL=20 domain.  It would be
> >given the location corresponding = to the IP=20 address of the request. 
> >Note that this would be pretty = good for the=20 requested case, even in
> >the presence of a NATed local area = network in=20 your home.  The phone
> >would do this on boot, before any = VPN tunnels=20 were established.
> >
> >I get the idea that a single = delivery=20 mechanism is desirable. I'm
> >skeptical we can do that because = of the=20 security issues. When you
> >make the delivery mechanism L2 = dependent, you=20 can control the
> >possible attacks to a finer grain = than the L7=20 local domain.
> >
> >Please keep in mind that some of = the folks=20 wishing to use the L7
> >mechanism don't really want to = just return=20 location to the endpoint;
> >they want to retain the location = and give it=20 out to authorized
> >entities upon presentation of the = IP address=20 of the endpoint.  That
> >is a business decision.  They = can charge=20 for such a service.  I think
> >the privacy implications of that = are dicey,=20 but the reality is that's
> >the model that will probably be = implemented=20 if we do this.
> >
> >Brian
> >
> >
> >
> >
> >
> >> -----Original = Message-----=20
> >> = From: Michael=20 Hammer (mhammer) [mailto:mhammer@cisco.com]=20
> >> = Sent: Wednesday,=20 April 20, 2005 10:14 AM
> >> To: Brian Rosen;=20 peter_blatherwick@mitel.com
> >> Cc: GEOPRIV WG;=20 ecrit@ietf.org
> >> Subject: RE: [Ecrit] RE: = [Geopriv]=20 Announcement of Joint
> >GEOPRIV/ECRIT =
> >>=20 InterimMeeting
> >>
> >> Brian, =
> >> =
> >> Could you = clarify the=20 domain statement.  Given nomadicity, it would =
> >> seem that = location delivery=20 would need to be cross-domain.  The
> >> E911 PSAP will not always be = the same=20 domain as the roaming
> >> endpoint. =
> >> =
> >> My impression = is that=20 Location discovery is a L2 issue, tied to the
> >> fact that L2 = is supposed to=20 be a single physical hop at most
> >> between the end- user = terminal and an=20 adjacent location-determining
> >> network node.  (Of = course those=20 trying to make L2 protocols a
> >replacement for =
> >> IP sort of = screw this=20 assumption up.)
> >>
> >> The location delivery = mechanism is an=20 application-layer or
> >L7 service. =
> >> The argument = there is that=20 since multiple applications will need to
> >> rely on location information, = a general=20 purpose delivery mechanism
> >> will provide consistency and = generality=20 that is so often sought in
> >> IETF work.  Security can = be=20 built-in to the chosen delivery
> >mechanism.
> >> Note, that = delivery could=20 be a choice of an existing transfer
> >> mechanism.  This does = not preclude=20 other L7 protocols from
> >defining a
> >> place in their = messages=20 that could also carry location information.
> >> =
> >> So, I=20 believe:
>=20 >> Location discovery is local, with associated security being = local,=20
> = >>=20 Location delivery is global, with associated security being=20 global.
>=20 >>
>=20 >> The real issues are making those happen. =
> >> =
> >> = Mike=20
> = >>=20
> >> = >-----Original=20 Message-----
>=20 >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On=20
> = >>=20 >Behalf Of Brian Rosen
> >> >Sent: Wednesday, April = 20, 2005 9:54=20 AM
> >>=20 >To: peter_blatherwick@mitel.com
> >> >Cc: 'GEOPRIV WG';=20 ecrit@ietf.org
> >> >Subject: [Ecrit] RE: = [Geopriv]=20 Announcement of Joint GEOPRIV/ECRIT
> >> = >InterimMeeting=20
> >>=20 >
>=20 >> >There turns out to be a large set of issues around this = problem,=20
> = >>=20 >which I fear is leading to Balkanization.  There are two = really=20
> = >>=20 >important problems we need to solve.
> >> >
> >> >One = fundamental problem=20 is that every client needs to
> >implement every =
> >> >possible = LI transfer=20 mechanism that its environment could provide.
> >> = >=20
> >> = >We have=20 DHCP.  You guys are working on LLDP-MED.   The=20 DSL
> >>=20 >guys reject both
> >> >of these and want a = something=20 else.  Every phone has to implement
> >> >every = protocol.=20
> >>=20 >
>=20 >> >There are some who have observed that the mechanisms at = hand are=20
> = >>=20 >L2 specific.  They claim as long as you have an L2 specific=20
> = >>=20 >mechanism, you need one or more for each L2.  To get out of = that,=20
> = >>=20 >they propose that we use an L7 mechanism (think some version of=20
> = >>=20 >HTTP, although that might not fly).  They would say, lets do = that=20
> = >>=20 >once,
>=20 >and every L2
> >> >can use it.  The = problem is=20 that you then have to deal with the
> >> >security issues of an L7 = mechanism,=20 and in particular, you have to
> >> >use IP address as the = "key" for what=20 location to return.
> >If you can
> >> >spoof IP = address, you=20 can get someone else's location.
> >> >
> >> >Those = advocating L7=20 mechanisms claim that the mechanism
> >would only be =
> >> = >implemented within a=20 domain, and the domain would have to take
> >> >anti-spoofing = steps.  They note=20 that the mechanism would need at
> >> >least a complete round = trip, and=20 probably more than one, so
> >spoofing
> >> >requires the ability=20 to
> >>=20 >intercept packets not addressed to the attacker.  =20 The
> >>=20 >returned data could
> >> >be precisely a=20 PIDF-LO.
>=20 >> >
> >> >Then on top of that, we = turn out to=20 need some more security,
> >> >especially for emergency=20 calls.  We need to prevent forged
> >locations.
> >> >That means = we need to=20 sign the PIDF-LO.  If you get location via =
> >> >DHCP, or = LLDP-MED, and=20 the endpoint constructs a PIDF-LO from
> >> >that, how do we construct = a=20 signature from the entity that
> >> >actually determined=20 location?
>=20 >> >
> >> >Brian =
> >> = >=20
> >>=20 >
>=20 >> >________________________________________ =
> >> >From:=20 geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ]=20
> = >>=20 >On Behalf Of peter_blatherwick@mitel.com
> >> >Sent: = Wednesday, April=20 20, 2005 9:30 AM
> >> >To: Andrew = Newton=20
> >> = >Cc: GEOPRIV=20 WG; ecrit@ietf.org
> >> >Subject: Re: [Geopriv] = Announcement=20 of Joint GEOPRIV/ECRIT Interim
> >> >Meeting =
> >> >=20
> >>=20 >
>=20 >> >Hi Andrew, lists,
> >> >
> >> >I'd like = to better=20 understand the meaning of the following agenda =
> >> = >items:=20
> >> = > =20 "
> >>=20 >  2) Properties of network elements in transferring LI from = layer=20
> = >>=20 >2
>=20 >> > upward to PIDF-LO.
> >> > 3) Proposed = enhancements to=20 PIDF-LO to support #2.
> >> > " =
> >> = >=20
> >> = >Is there a=20 summary of what these really mean, or examples =
> >of what = the=20
> >> = >outcome could=20 be in terms of protocol or layer interactions? =
> >> = >=20
> >> = >Reason I'm=20 asking is I am deeply involved in a layer 2
> >approach = which=20
> >> = >would be able=20 to deliver location information to endpoints from =
> >> >the L2 LAN = infrastructure they are connected to.  The work is =
> >going on=20 in
> >>=20 >TIA and is called Link Layer Discovery Protocol - Media Endpoint=20
> = >>=20 >Discovery (LLDP-MED), which is an extension of IEEE =
> >802.1AB,=20 specific
>=20 >> >to VoIP systems.  In LLDP-MED, among several other = things,=20 we have
>=20 >> >specified ways to pass equivalent data to the DHCP=20
> = >>=20 >coordinate-based LCI (RFC 3825) and civic location LCI=20
> = >>=20 >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process = I=20
>=20 >believe).
> >> >We see this method of = delivery as a=20 non-competing
> >alternative to the =
> >> >DHCP-based = approach,=20 with the same end result to the overall ECS
> >> >system = (the endpoint=20 receives the exact same data), which has some
> >> >advantages = particularly=20 in enterprise deployment scenarios.  (The =
> >> >DHCP-based = method has=20 advantages in different scenarios.)   I am =
> >> >Editor of = thi s=20 document, and it is now in ballot process in TIA =
> >> >(more or = less=20 equivalent to Last Call in IETF).
> >> >
> >> >Sorry, I = expect I am=20 suffering lack of context here, since I only
> >> >joined the = list=20 relatively recently.
> >> >
> >> >BTW, what = is the state=20 of geopriv-dhcp-civil?  Is it now past Last =
> >> >Call and = in the RFC=20 Editor's queue?  It seemed to have been
> >> >settled on = the list,=20 and waiting on AD action.
> >> >
> >> >-- Peter=20 Blatherwick
>=20 >> >
> >> >
> >> = >=20
> >>=20 >
>=20 >> >Andrew Newton <andy@hxr.us> =
> >> >Sent by:=20 geopriv-bounces@ietf.org
> >> >13.04.05 = 16:34=20
> >>=20 >
>=20 >> >        To:      =20  GEOPRIV WG <geopriv@ietf.org>
> >> >      =  =20 cc:
> >>=20 >        Subject:       =  [Geopriv]=20 Announcement of Joint
> >GEOPRIV/ECRIT =
> >> >Interim=20 Meeting
>=20 >> >
> >> >
> >> = >=20
> >>=20 >
>=20 >> >The GEOPRIV and ECRIT working groups will be holding=20 a
> >joint=20 interim
>=20 >> >meeting.
> >> >
> >> >  =    =20 What: Interim GEOPRIV/ECRIT meeting
> >> >      = When: 2005 May=20 16 08:30-17:30
> >> >      =    =20   2005 May 17 08:30-17:30
> >> >      =    =20   2005 May 18 08:30-17:30
> >> >    =  Where:=20 Columbia=20 University=20
> >> = >   =20         Dept. of Computer Science =
> >> >  =    =20       450 Computer Science Bldg. =
> >> >  =    =20       1214 Amsterdam = Avenue=20 (close to 120th St.) =
> >> >  =    =20       New = York, NY = 10027 =
> >> = >Directions: http://www.cs.columbia.edu/directions.html=20
> >> = >   =20   Also: WiFi provided.
> >> >      =    =20   Teleconference to be provided.
> >> >    =  Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html=20
> >> = >   =20         Early bookings recommended. =
> >>=20 >
>=20 >> >Proposed GEOPRIV Agenda:
> >> >  2005 May 16 = 08:30-17:30, 2005=20 May 17 08:30-12:30
> >> >1) Role of HTTP as a = transfer=20 protocol for PIDF-LO vs. the
> >use of LI
> >> >in = HTTP/HTML for web=20 browsing.
>=20 >> >2) Properties of network elements in transferring LI = from layer 2=20
> = >>=20 >upward to PIDF-LO.
> >> >3) Proposed enhancements = to PIDF-LO=20 to support #2.
> >> >
> >> >Proposed = ECRIT=20 Agenda:
>=20 >> >  2005 May 17 13:30-17:30, 2005 May 18=20 08:30-17:30
>=20 >> >1) Emergency Call Routing Requirements =
> >> >2) = Security and Threats=20 Analysis
>=20 >> >
> >>=20 >_______________________________________________ =
> >> >Geopriv = mailing=20 list
>=20 >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv=20
> >>=20 >
>=20 >> >
> >> >
> >> = >=20
> >>=20 >_______________________________________________ =
> >> >Ecrit = mailing=20 list
>=20 >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit<= /FONT>=20
> >>=20 >
>=20 >>
>=20 >
>=20 >
>=20

 

_______________________________________________=20
Ecrit mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit<= /FONT>=20

------_=_NextPart_001_01C5460F.C816767A-- --===============0819552242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0819552242==-- From ecrit-bounces@ietf.org Thu Apr 21 08:21:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOagQ-0007Fa-Oy; Thu, 21 Apr 2005 08:21:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOagP-0007FR-5f; Thu, 21 Apr 2005 08:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20225; Thu, 21 Apr 2005 08:21:24 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOarp-0004p1-4z; Thu, 21 Apr 2005 08:33:13 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j3LCL7F20895; Thu, 21 Apr 2005 08:21:07 -0400 (EDT) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005042108210509945 ; Thu, 21 Apr 2005 08:21:05 -0400 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Apr 2005 08:21:05 -0400 Message-ID: From: "Abbott, Nadine B." To: GEOPRIV WG , ecrit@ietf.org Date: Thu, 21 Apr 2005 08:21:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Subject: [Ecrit] RE: [Geopriv] Terms on this thread X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for the reminder, James, I think that will help. -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk Sent: Wednesday, April 20, 2005 11:44 PM To: GEOPRIV WG; ecrit@ietf.org Subject: [Geopriv] Terms on this thread Suggesting term changes: "Location Delivery" is to the endpoint (the first time or a refresh) "Location Conveyance" is from the endpoint (to the LIS, the Proxy or to the PSAP) "Location Conveyance" is already the term/phrase used in SIP(PING) for a UA to convey its location to another UA or Proxy, per: http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements -02.txt so the term/phrase seems to be appropriate here Delivery IN Conveyance OUT both from the endpoint's point of view agreed? we can worry about non-proxy server to server lateral movement when that issue comes up At 01:03 PM 4/20/2005 -0400, Abbott, Nadine B. wrote: >Mike, >You are right--it is being used in two different contexts. Delivery of >location to the endpoint and delivery of location to the PSAP. We need >different terms or we need to qualify the term when we use it (as >above). Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of Michael Hammer (mhammer) >Sent: Wednesday, April 20, 2005 12:00 PM >To: Brian Rosen; peter_blatherwick@mitel.com >Cc: GEOPRIV WG; ecrit@ietf.org >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT >InterimMeeting > > >I still get the feeling that "delivery" is being used in two different >contexts: > > (1) (2) >Local node---?---->endpoint-----/many hops/----->PSAP > ---------------------/many hops/-----> > (2) > >How can "delivery" be L2 dependent, when it must reach a PSAP many hops >away? Color me confused. > >Mike > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Wednesday, April 20, 2005 10:47 AM > >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com > >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT InterimMeeting > > > >The idea is that, say, you are in your home, served by a DSL > >provider. The domain is then that of the DSL vendor. Your phone asks > >for its location from the server in the DSL domain. It would be > >given the location corresponding to the IP address of the request. > >Note that this would be pretty good for the requested case, even in > >the presence of a NATed local area network in your home. The phone > >would do this on boot, before any VPN tunnels were established. > > > >I get the idea that a single delivery mechanism is desirable. I'm > >skeptical we can do that because of the security issues. When you > >make the delivery mechanism L2 dependent, you can control the > >possible attacks to a finer grain than the L7 local domain. > > > >Please keep in mind that some of the folks wishing to use the L7 > >mechanism don't really want to just return location to the endpoint; > >they want to retain the location and give it out to authorized > >entities upon presentation of the IP address of the endpoint. That > >is a business decision. They can charge for such a service. I think > >the privacy implications of that are dicey, but the reality is that's > >the model that will probably be implemented if we do this. > > > >Brian > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Wednesday, April 20, 2005 10:14 AM > >> To: Brian Rosen; peter_blatherwick@mitel.com > >> Cc: GEOPRIV WG; ecrit@ietf.org > >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> InterimMeeting > >> > >> Brian, > >> > >> Could you clarify the domain statement. Given nomadicity, it would > >> seem that location delivery would need to be cross-domain. The > >> E911 PSAP will not always be the same domain as the roaming > >> endpoint. > >> > >> My impression is that Location discovery is a L2 issue, tied to the > >> fact that L2 is supposed to be a single physical hop at most > >> between the end- user terminal and an adjacent location-determining > >> network node. (Of course those trying to make L2 protocols a > >replacement for > >> IP sort of screw this assumption up.) > >> > >> The location delivery mechanism is an application-layer or > >L7 service. > >> The argument there is that since multiple applications will need to > >> rely on location information, a general purpose delivery mechanism > >> will provide consistency and generality that is so often sought in > >> IETF work. Security can be built-in to the chosen delivery > >mechanism. > >> Note, that delivery could be a choice of an existing transfer > >> mechanism. This does not preclude other L7 protocols from > >defining a > >> place in their messages that could also carry location information. > >> > >> So, I believe: > >> Location discovery is local, with associated security being local, > >> Location delivery is global, with associated security being global. > >> > >> The real issues are making those happen. > >> > >> Mike > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of Brian Rosen > >> >Sent: Wednesday, April 20, 2005 9:54 AM > >> >To: peter_blatherwick@mitel.com > >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org > >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > >> >InterimMeeting > >> > > >> >There turns out to be a large set of issues around this problem, > >> >which I fear is leading to Balkanization. There are two really > >> >important problems we need to solve. > >> > > >> >One fundamental problem is that every client needs to > >implement every > >> >possible LI transfer mechanism that its environment could provide. > >> > > >> >We have DHCP. You guys are working on LLDP-MED. The DSL > >> >guys reject both > >> >of these and want a something else. Every phone has to implement > >> >every protocol. > >> > > >> >There are some who have observed that the mechanisms at hand are > >> >L2 specific. They claim as long as you have an L2 specific > >> >mechanism, you need one or more for each L2. To get out of that, > >> >they propose that we use an L7 mechanism (think some version of > >> >HTTP, although that might not fly). They would say, lets do that > >> >once, > >and every L2 > >> >can use it. The problem is that you then have to deal with the > >> >security issues of an L7 mechanism, and in particular, you have to > >> >use IP address as the "key" for what location to return. > >If you can > >> >spoof IP address, you can get someone else's location. > >> > > >> >Those advocating L7 mechanisms claim that the mechanism > >would only be > >> >implemented within a domain, and the domain would have to take > >> >anti-spoofing steps. They note that the mechanism would need at > >> >least a complete round trip, and probably more than one, so > >spoofing > >> >requires the ability to > >> >intercept packets not addressed to the attacker. The > >> >returned data could > >> >be precisely a PIDF-LO. > >> > > >> >Then on top of that, we turn out to need some more security, > >> >especially for emergency calls. We need to prevent forged > >locations. > >> >That means we need to sign the PIDF-LO. If you get location via > >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from > >> >that, how do we construct a signature from the entity that > >> >actually determined location? > >> > > >> >Brian > >> > > >> > > >> >________________________________________ > >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] > >> >On Behalf Of peter_blatherwick@mitel.com > >> >Sent: Wednesday, April 20, 2005 9:30 AM > >> >To: Andrew Newton > >> >Cc: GEOPRIV WG; ecrit@ietf.org > >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim > >> >Meeting > >> > > >> > > >> >Hi Andrew, lists, > >> > > >> >I'd like to better understand the meaning of the following agenda > >> >items: > >> > " > >> > 2) Properties of network elements in transferring LI from layer > >> >2 upward to PIDF-LO. > >> > 3) Proposed enhancements to PIDF-LO to support #2. > >> > " > >> > > >> >Is there a summary of what these really mean, or examples > >of what the > >> >outcome could be in terms of protocol or layer interactions? > >> > > >> >Reason I'm asking is I am deeply involved in a layer 2 > >approach which > >> >would be able to deliver location information to endpoints from > >> >the L2 LAN infrastructure they are connected to. The work is > >going on in > >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint > >> >Discovery (LLDP-MED), which is an extension of IEEE > >802.1AB, specific > >> >to VoIP systems. In LLDP-MED, among several other things, we have > >> >specified ways to pass equivalent data to the DHCP > >> >coordinate-based LCI (RFC 3825) and civic location LCI > >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I > >believe). > >> >We see this method of delivery as a non-competing > >alternative to the > >> >DHCP-based approach, with the same end result to the overall ECS > >> >system (the endpoint receives the exact same data), which has some > >> >advantages particularly in enterprise deployment scenarios. (The > >> >DHCP-based method has advantages in different scenarios.) I am > >> >Editor of thi s document, and it is now in ballot process in TIA > >> >(more or less equivalent to Last Call in IETF). > >> > > >> >Sorry, I expect I am suffering lack of context here, since I only > >> >joined the list relatively recently. > >> > > >> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last > >> >Call and in the RFC Editor's queue? It seemed to have been > >> >settled on the list, and waiting on AD action. > >> > > >> >-- Peter Blatherwick > >> > > >> > > >> > > >> > > >> >Andrew Newton > >> >Sent by: geopriv-bounces@ietf.org > >> >13.04.05 16:34 > >> > > >> > To: GEOPRIV WG > >> > cc: > >> > Subject: [Geopriv] Announcement of Joint > >GEOPRIV/ECRIT > >> >Interim Meeting > >> > > >> > > >> > > >> > > >> >The GEOPRIV and ECRIT working groups will be holding a > >joint interim > >> >meeting. > >> > > >> > What: Interim GEOPRIV/ECRIT meeting > >> > When: 2005 May 16 08:30-17:30 > >> > 2005 May 17 08:30-17:30 > >> > 2005 May 18 08:30-17:30 > >> > Where: Columbia University > >> > Dept. of Computer Science > >> > 450 Computer Science Bldg. > >> > 1214 Amsterdam Avenue (close to 120th St.) > >> > New York, NY 10027 > >> >Directions: http://www.cs.columbia.edu/directions.html > >> > Also: WiFi provided. > >> > Teleconference to be provided. > >> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html > >> > Early bookings recommended. > >> > > >> >Proposed GEOPRIV Agenda: > >> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30 > >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the > >use of LI > >> >in HTTP/HTML for web browsing. > >> >2) Properties of network elements in transferring LI from layer 2 > >> >upward to PIDF-LO. > >> >3) Proposed enhancements to PIDF-LO to support #2. > >> > > >> >Proposed ECRIT Agenda: > >> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30 > >> >1) Emergency Call Routing Requirements > >> >2) Security and Threats Analysis > >> > > >> >_______________________________________________ > >> >Geopriv mailing list > >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 21 08:48:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOb6d-0001MZ-Qe; Thu, 21 Apr 2005 08:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOb6Z-0001MR-CL; Thu, 21 Apr 2005 08:48:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21924; Thu, 21 Apr 2005 08:48:26 -0400 (EDT) Message-Id: <200504211248.IAA21924@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObHy-0005LW-NC; Thu, 21 Apr 2005 09:00:15 -0400 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DOb6N-0002tO-BU; Thu, 21 Apr 2005 07:48:15 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting Date: Thu, 21 Apr 2005 08:48:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42670459.9010905@cs.columbia.edu> Thread-Index: AcVGEwdBRrgOAoBlRK6/+BDGi/Ib2wAAaLVg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org L2TP and static assignments I am told. Having said that, does L2TP assign IP addresses within the tunnel with PPP? Always? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 20, 2005 9:40 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; peter_blatherwick@mitel.com; 'GEOPRIV WG'; > ecrit@ietf.org > Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT > InterimMeeting > > Brian Rosen wrote: > > Actually, there are quite a few ways that DSL systems work, and they > don't > > always use PPP. It would work for many deployments, but not all. > > I've only seen DHCP or PPP (for PPPoE) systems for IP address assignment > in DSL. What else is there? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 21 08:57:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObFK-0002A1-0y; Thu, 21 Apr 2005 08:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObFE-00029t-8Q; Thu, 21 Apr 2005 08:57:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22737; Thu, 21 Apr 2005 08:57:23 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObQe-0005Zw-0n; Thu, 21 Apr 2005 09:09:13 -0400 Received: from [127.0.0.1] (IDENT:U2FsdGVkX18qtjFWOfpZbnSRLDW83fxsLQyniAk5suk@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j3LCvBh3006762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2005 08:57:13 -0400 (EDT) Message-ID: <4267A323.4090602@cs.columbia.edu> Date: Thu, 21 Apr 2005 08:57:07 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting References: <200504211248.IAA21924@ietf.org> In-Reply-To: <200504211248.IAA21924@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > L2TP and static assignments I am told. > > Having said that, does L2TP assign IP addresses within the tunnel with PPP? As far as I know, L2TP itself has no address assignment capabilities, at least according to RFC 2661. Given that it is a 'layer-2 tunneling protocol', that also makes sense - layer 2 being something like PPP. As long as PPP is used, static assignment would not seem to rule out use of PPP for conveying location references or values. > Always? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 21 11:38:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdlB-0001zH-5S; Thu, 21 Apr 2005 11:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdl9-0001z0-KP for ecrit@megatron.ietf.org; Thu, 21 Apr 2005 11:38:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09969 for ; Thu, 21 Apr 2005 11:38:21 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdwS-0002Xm-2G for ecrit@ietf.org; Thu, 21 Apr 2005 11:50:13 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j3LFcE4n017199 for ; Thu, 21 Apr 2005 17:38:14 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3LFcEtT014169 for ; Thu, 21 Apr 2005 17:38:14 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ53AGJ>; Thu, 21 Apr 2005 17:38:13 +0200 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Thu, 21 Apr 2005 17:35:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] Reminder to draft authors and editors: new boilerplate X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Dear WG, Just as a reminder, there's new boilerplate available for the updated BCP 78 and 79 about IETF rights in contributions and IPR considerations Please make sure that you're familiar with the new versions, and start to use the new boilerplate. The new format will be mandatory next month sometime, so please start preparing for the changes now, as you get ready to submit new drafts of documents. If you're using xml2rfc, there's a new version of the tool which provides this now (1.29). http://xml.resource.org/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 24 17:45:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPoux-0007oW-SD; Sun, 24 Apr 2005 17:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPouv-0007oR-Rb for ecrit@megatron.ietf.org; Sun, 24 Apr 2005 17:45:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25374 for ; Sun, 24 Apr 2005 17:45:26 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPp71-0000h5-5b for ecrit@ietf.org; Sun, 24 Apr 2005 17:58:00 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j3OLjN8I002219 for ; Sun, 24 Apr 2005 23:45:24 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3OLjN40022652 for ; Sun, 24 Apr 2005 23:45:23 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ537W5>; Sun, 24 Apr 2005 23:45:23 +0200 Message-ID: From: Tschofenig Hannes To: ecrit@ietf.org Date: Sun, 24 Apr 2005 23:42:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] Note on Interim meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, just a note to document authors: all drafts must be announced at least 1 week in advance of the interim meeting date, so folks have time to read the drafts. please consider this aspect and plan accordingly. hannes/marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit