From br@brianrosen.net Sun Nov 1 05:36:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82063A6892 for ; Sun, 1 Nov 2009 05:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL6KeoOZ1ijM for ; Sun, 1 Nov 2009 05:36:39 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 30A1F3A6889 for ; Sun, 1 Nov 2009 05:36:39 -0800 (PST) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N4abq-0001vA-GA; Sun, 01 Nov 2009 07:36:43 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 01 Nov 2009 08:36:40 -0400 From: Brian Rosen To: James Winterbottom , "Dawson, Martin" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EADhIEsAAa3yqpAA9rF8YAIf7zRg== In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8E6DA71@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 13:36:42 -0000 An open WiFi hotspot does not have any idea who the devices (or people) connecting to the service are. A great example is my local airport, but it also works in the entire downtown central area. The identity one gets from the access provider is nil. There is no reason to believe such networks are going away. Any form of device information such networks may provide is not going to help eliminate abuse. In fact, the only thing that kind of data (MAC address equivalent) could provide is forensic information if the police found a suspect, and even then, it's unlikely to be definitive. Open WiFi and similar networks are effectively anonymous. Trying to hold the operator of such networks liable would effectively kill them. Is that your plan: eliminate free and open access networks? The direction these days is personal devices, be they mobile or not. Shared devices, like shared phones in a residence is on its way out. Of course, some shared devices will remain, and we have to assume calls will come from them. However, increasingly device=person. That's nice, because we can often make the assumption that it is. I agree that it isn't always. However, at least now, and for the foreseeable future, access network <> person, because it is shared. This is not true of the mobile phone device, or something like a laptop with a HSDPA modem, but most access networks are shared, and any kind of access network subscriber identity just isn't as good as a calling network subscriber identity. Of course, we'd like both. I said it was an advantage that the access provider was local. Somehow, you didn't believe I was agreeing with you :) Saying all traffic comes from the access network is true in that the packets come from the access network, sent through all manner of intermediate devices and networks of course. Such intermediaries are increasingly getting in the way of using the fact that the packets are coming from one access network. Carrier NAT for example is going to make this kind of assumption harder to take any advantage of. However, CALLS come from calling networks, not access networks. The things we deal with are calls, not packets. Farther up the stack. That's kind of the point of protocol layering, right? To be pedantic, the packets from a call come from the calling network, not from the callers access network. All of the packets come that way, usually. And yes, the calling network has its own access network, but that network isn't interesting to your cause. There are many reasons why we say that IP addresses are not good identifiers. Read up on it. For this discussion, it is mostly because the address that the far end gets is often not what the near end sent. Carrier NAT will drive you crazy (with respect to IP address as identifier), but so will VPNs. You will recall all the problems of IP address as identifier with HELD, requiring bypass of tunnels that sometimes can't be bypassed, and total inability to deal with some situations that, while rare, actually occur. I see no text in this draft on that. If I wanted to abuse, for example, using any of the many available anonymizers would be trivial to arrange, and you would be powerless to stop it. As above, the open WiFi and similar networks make a mockery of your argument that the IP address is something reasonably traceable to an abuser. I think that the protocol argument is still pretty important. You are slicing and dicing here. The device has to speak SIP and the ESInet has to be willing to accept direct calls. The question is whether the number of cases where it works is worth the implementation. Brian On 10/31/09 5:44 PM, "James Winterbottom" wrote: > I have puzzled over a number of the comments below and I think you just don't > get what we mean by an access provider Brian. > Specific comments inline. > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Brian Rosen > [br@brianrosen.net] > Sent: Saturday, October 31, 2009 9:01 AM > To: Dawson, Martin; Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > There is no doubt that the PSAPs care about the access provider, because the > access provider is responsible for location. They want a good identity from > that location provider, and they want the data that it provides to have some > kind of integrity protection. > > [AJW] The access provider is actually THE BEST SOURCE of the identity > information to the equivalent of what they get today for landline. The access > provider knows in whose name the access service is provided. This is exactly > the same as what happens with a landline today, or a mobile for that matter, > or a public telephone. Making the assumption that the person that rents the > line is the person that makes the call is a fundamentally flawed assumption, > the best you can ever get is the identity of the person that rents the > service. > > It is an advantage that the access provider is local. > > [AJW] The access provider is ALWAYS LOCAL. i don't understand you comments > here at all. > > However, calls don't come from access providers, they come from service > providers who provide some sort of real time two way media session service > (recognizing that often the access network and the SP that provides the > calling service are the same entity). That's the SP we're talking about. > > [AJW] Fundamentally wrong. ALL TRAFFIC comes via the access provider, that is > why they are the access provider. Are you suggesting that calls somehow use a > different path to enter the Internet than through the access provider's > network, if so, isn't that second path also provided by an access provider? > > > Unlike the calling network, where there is at least a rudimentary > authentication system in place always, there are many access networks that > have no authentication at all, which gives rise to the abuse problem that > makes this idea not tenable. There is no reason to believe that is going to > change. > > [AJW] Are you saying that the person that ultimately provides the access > service doesn't have to do any kind of authentication, contractually or > cryptographically, in order to get their fibre connected into the Internet? I > simply don't believe you, and if that is the case I want to move where this is > possible. Ultimatley, if you provide an open Internet connection, and the > users you allow to connect to it start making nuisance calls then you as the > access provider will be held responsible. This is reasonable. And yes they > will know where you are, and yes you will get hit with a big stick. I also > think that there are enough logs in the system that if it is the same user > doing it all the time you could take pretty reasonable steps to stop them from > connecting to the network at all. > > I also point out, once again, that using the access network as the source of > authentication means that we are using an IP address as an identifier. IP > addresses make lousy identifiers. They are addresses, not identifiers. > > [AJW] I have a few comments on this. An address identifies where to send > traffic, so it is an identifier, it identifies a device at a point in time. > For the purpose of this discussion I am trying to get help to the person on > the end of the device. I have absolutely no way of ever knowing precisely who > they are, so this whole "person identity" discussion is entirely moot, the > best I can EVER know, as I stated before, is who is paying for the service, > access or phone. On my access provider, I can assure you that modem does need > to authenticate, so my access provider absolutely knows that the modem on the > end of this service is paid for by me. My wife and children live in this house > too, and anyone of them can also use a computer connected to the network in my > house, sometimes I let visitors use it too. This is no different to a > conventional phone service, and the PSAP operator cannot assume that it is me > that is calling, the only thing that they can be sure of is that it is a phone > in my house. Using the access provider to authenticate and provide information > in this manner is a very good idea, and guess what, this is EXACTLY what ECRIT > Direct is saying. Keep everything local! > > > Oh, one more thing about this idea: > > It means that devices have to have a SIP stack, regardless of what they > actually use to place calls. That's okay for some devices, but of course > there are many, many more devices and services that don't use SIP from the > device to the service provider. It's one thing to say that the SP has to > gateway to SIP if its devices don't already speak SIP. It's quite another > to say that every device has to be able to speak SIP for emergency calls > regardless of what it uses for everything else. There would be similar > daunting problems for codecs. > > [AJW] This is ONLY true is the device wants to be compliant with this > specification. This specification builds on phone BCP and provides an end-game > solution, it does not mean that things in Phone BCP cannot be used. > > Cheers > James > > > > > > > On 10/30/09 9:18 PM, "Dawson, Martin" wrote: > >> Hey Brian, >> >> Maybe if you keep saying "service provider" we'll all start believing it >> means >> "VSP" and it really does have some quintessential significance to emergency >> calling... >> >> However, to quote Watto (Phantom Menace): >> >> "What? You think you're some kind of Jedi, waving your >> hand around like that?" >> >> :) >> >> Sure PSAP providers like to have a "service provider" they can point their >> finger at. They like someone who might be a source of forensic information >> related to the source of nuisance calls. In particular, it's really useful if >> that provider is in the same jurisdiction that they are. That would be the >> 'I' >> SP rather than the 'V' SP that you keep trying to steer the focus back to. >> >> Cheers, >> Martin >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Brian Rosen >> Sent: Saturday, 31 October 2009 5:29 AM >> To: Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered >> >> I'm the messenger here. PSAPs prefer service providers to be on the path of >> a call, and they have bad experiences when they aren't. >> >> Given their experiences, I can't fault them. >> >> The reason the text is in phonebcp is as you said it is: because "normal" is >> likely to work. The fact that "normal" means SP path in 99.999% of cases >> gets the PSAPs what they want. They don't care about why we did it, they >> care they get the right result. >> >> I don't believe we are going to see vanity domains used on calls, and even >> if they were in "From", they won't be the domain in P-Asserted-Identity, or >> the SubjectAltName of the Identity signature. If some service that used >> email addresses as identities sent us calls, the email address (with its >> domain) is the "userpart" of the identity, not the whole thing. There are >> some interesting problems when you have URI to something like the MS IM >> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >> built systems that handle that. >> >> The Firewall/Session Border controls will have several criteria when PSAPs >> are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest >> other than the repeat offender rule, which is the first line of defense. >> They do filter based on criteria that equate to IP Address or Domain of the >> SP, which we can deal with. We'll use what works for the other users of >> these systems, we're unlikely to be able to have emergency services special >> firewalls or SBCs. >> >> In most cases we're going to have hard connections, or more likely VPNs from >> service providers to the ESInet routers. That will probably handle 90+ >> percent of calls, but we'll still have substantial numbers coming from the >> big I Internet. We do want to know where they are coming from, and we will >> have SOME form of identity that we trust to separate those we know about >> from those we don't. >> >> This is a percentages game. Most of the time, calls will be accepted no >> matter how they get to the ESInet. If you want your calls to get through >> when things are bad, send them the way you send all your other calls; that >> will work okay. If you break that (by encouraging people to send them >> direct), then we'll have more problems. >> >> I'm back to the basic tenet: if you can use the service to create media >> sessions to others, you can use it to send emergency calls, and we want the >> calls sent the same path (because it will work). If you can't use the >> service (like, you can't register for one reason or another), we don't want >> you to be able to make emergency calls. >> >> To be fair, there is at least one country I know of that doesn't agree. >> They have documented a small number of good calls in with the tens of >> thousands of bad ones, and think its worth it to handle the bad ones in >> order to get to the good ones. Most PSAPs I know of don't. >> >> And furthermore, there are some regulations around this that are nation >> specific, and I think we don't need the IETF to wade into trying to figure >> out how to meet those regulations. In most cases, we don't really know how >> the regulator intends the regulations to cover devices on the Internet. >> >> Brian >> >> On 10/30/09 1:46 PM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> "Normal Call Path" was NOT added to phonebcp for the purpose of the >>> perceived security you describe. The advantage (and the reason it's in >>> phonebcp) to using the normal call path is due to it being the most likely >>> mechanism to work. Unused/untested mechanisms are more likely to fail when >>> tried for the first time verses mechanisms that are used/tested daily. >>> Emergency time is not the time to test a new mechanism, hence use the normal >>> call path, the same one you just used to call grandma, to summons emergency >>> assistance. (This is a negative against this proposed mechanism.) >>> >>> If you are evangelizing within the PS community that 'sip:johnny@att.com' is >>> less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the >>> wrong message to be spreading. Please stop now. This will only lead to the >>> thousands of personal injury lawyers making big $$ at the expense of the PS >>> community. >>> >>> As you are intimately aware, there are millions of 'vanity' domains in use >>> and it's growing. Its growing not just in the individual market, but in the >>> small/medium business market. You also know there are thousands of hosting >>> companies providing services to the owners of vanity domains (email, web, >>> ftp, etc.). I expect in the near future that hosting providers will add sip >>> proxy services to their list of wares. >>> >>> My guess would be that PS officials would like to treat their customer known >>> as -'sip:johnny@vanitydomain.com' the same as their customer known as >>> -'sip:johnny@att.com'. The domain name does not dictate the level of >>> urgency in the request for emergency assistance, nor the veracity of the >>> caller. >>> >>> When an overload of the ESInet exists, I would suggest to look for other >>> parameters to use in decision process of how to populate the various queues. >>> >>> - Are the calls from all the same location? >>> - Is it reasonable that the IP address/network can be at the reported >>> location? >>> - How many calls have we received over a period of time from this AOR? IP >>> address/network? Location? >>> >>> Simply using the domain/AOR as the black and white rule, as you suggest, >>> will lead to big problems. >>> >>> Just my opinion, >>> >>> -Marc- >>> >>> On 10/30/09 9:47 AM, "Brian Rosen" wrote: >>> >>>> I want it to say MUST NOT use that mechanism :) >>>> >>>> I don't want alternative ways to make emergency calls. I want what >>>> phonebcp >>>> already says: send the call on the normal path and a normal identity and >>>> callback (which implies using a normal registration). >>>> >>>> I understand that the local authority can disable the ESRP registration >>>> mechanism. If this draft goes forward against my advice, then I will ask >>>> that there be text that says if the registration cannot be completed, the >>>> device MUST NOT send emergency calls direct to that ESRP, and must use its >>>> normal call path for emergency calls. >>>> >>>> We can't stop calls from entering the emergency services IP network without >>>> passing through a service provider. I have no wish to add any mechanism >>>> which would attempt to do so. If it would help, I would be happy to beef >>>> up language in framework that discusses this problem and what "normal call >>>> path" means. I would even be very happy to add a item to phonebcp that >>>> says >>>> "if you can't make normal calls, you can't make emergency calls", although >>>> we might get hung up on defining "normal", because if at some time when you >>>> need help the only number that could actually answer your call, sent down >>>> the same call path as you would normally send any call, is the emergency >>>> service, then we want that call. >>>> >>>> We frequently use you as an example. If you have a SIP Registrar and proxy >>>> server in your home (or boat) and you have a phone that registers with it, >>>> and you normally make calls to your family and friends with that setup, >>>> then >>>> I suspect that there is some service provider helping your proxy server >>>> connect to your family and friends. We would prefer your emergency calls >>>> go >>>> through that service provider. However, if for some reason, your proxy >>>> server forwarded an emergency call direct to the ESInet, it will normally >>>> go >>>> through. >>>> >>>> Unfortunately for you, if someone decides to attack the emergency call >>>> system, and it gets overloaded for some period of time until we can >>>> mitigate >>>> the attack, we may have to make choices on which calls we answer and which >>>> ones we don't. Your call sent through your proxy server to the ESInet >>>> direct may get lower priority than the same call sent through the service >>>> provider, if we notice that most of the attack calls are coming direct from >>>> the Internet, rather than going through a service provider we know about. >>>> We're building in explicit attack mitigation strategies like that. It's >>>> not >>>> unreasonable: if you have 5 sources entering your network, and one of them >>>> is the place where all (or most) of the attack is coming from, you shut off >>>> that source until you have a better filter. >>>> >>>> If a whole lot of devices assume the direct path is the preferred path, >>>> that >>>> would be bad for them. >>>> >>>> Furthermore, there is additional data sent to the emergency system (in the >>>> U.S.) with the call from the service provider. That information may be >>>> useful in helping you. The device can actually send the information, but >>>> while while we are pretty sure we can get most service providers to give it >>>> to us, we are pessimistic most devices will. Devices that have sensors, >>>> where the sensor data is useful for emergency calls may very well do it. >>>> Medical monitoring devices for example. NENA will be asking the IETF to >>>> standardize this soon, so that all service providers anywhere could provide >>>> it to all emergency services. It has things like subscriber (as opposed to >>>> caller) contact data, class of service information, SP contact data, etc. >>>> When things go wrong, the PSAP will often contact the SP and get help. The >>>> SP often has tools and mechanisms that CAN help. >>>> >>>> Brian >>>> >>>> >>>> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >>>> >>>>> Brian, >>>>> >>>>> I didn't read anything in the draft that stated devices 'should' use this >>>>> mechanism (if it's there, it needs removed). I read it more as a device >>>>> 'could' use this mechanism (as in an alternative to other mechanisms). >>>>> >>>>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>>>> PSAP policy decision whether to support this mechanism. As without the >>>>> ESRP >>>>> support of unknown UA registrations, the mechanism doesn't work. >>>>> >>>>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>>>> stretching the 'normal call path' to include registration with >>>>> something(?). >>>>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>>>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>>>> using the Contact header I sent in the invite and my AOR leads back to my >>>>> UA, I've satisfied phonebcp. >>>>> >>>>> What am I missing? >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>>>> >>>>>> The IETF writing standards that describe how devices should bypass their >>>>>> service provider and place emergency calls direct is not a PSAP policy >>>>>> issue. >>>>>> >>>>>> I'm satisfied with the current -phonebcp dictum to send calls on the >>>>>> normal >>>>>> call path. For an "unregistered" device, that will not allow any "calls" >>>>>> including emergency calls. >>>>>> >>>>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>>>> generate some list discussion from some PSAP people who are subscribed. >>>>>> I >>>>>> would also like to hear from more PSAP folks on this subject. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>>>> >>>>>>> These are all PSAP policy decisions. Just as it's a PSAP policy >>>>>>> decision >>>>>>> to >>>>>>> support the suggested mechanism in the draft. Existence of the document >>>>>>> describing the mechanism doesn't force PSAP policy. >>>>>>> >>>>>>> I personally would like to see some PSAPs and/or PS jurisdictions line >>>>>>> up >>>>>>> behind the draft before it proceeds, but I don't see any harm in it >>>>>>> going >>>>>>> forward. >>>>>>> >>>>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>>>> wants >>>>>>> to enable communication with all their customers and not force them to >>>>>>> be >>>>>>> a >>>>>>> member of a special club. >>>>>>> >>>>>>> [non-chair hat on] >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> Thank you. That is what I meant, and you said it better than I was >>>>>>>> going >>>>>>>> to. >>>>>>>> >>>>>>>> We may also have some transitive relationships: that is, if there is a >>>>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>>>> that >>>>>>>> they have done so. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>>>> provider >>>>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>>>> >>>>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>>>> calls >>>>>>>>> to; >>>>>>>>> >>>>>>>>> 2) they authenticate the calls requests to a level of security >>>>>>>>> that >>>>>>>>> meets >>>>>>>>> the PSAPs (and any legal) requirements; >>>>>>>>> >>>>>>>>> 3) the PSAP trusts that they have done so. >>>>>>>>> >>>>>>>>> While this would normally be what we would understand as public >>>>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>>>> On Behalf Of Marc Linsner >>>>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>>>> To: Brian Rosen >>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>> considered >>>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> Please define what you consider to be a service provider. >>>>>>>>>> >>>>>>>>>> Is Skype a service? >>>>>>>>>> Is Jabber a service? >>>>>>>>>> Is Google Voice a service? >>>>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>>>> >>>>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>>>> >>>>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>>>> >>>>>>>>>> -Marc- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>>>> >>>>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>>>> phones (or >>>>>>>>>>> other >>>>>>>>>>> devices) built to call directly. >>>>>>>>>>> >>>>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>>>> direct, bypass your service provider. >>>>>>>>>>> >>>>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>>>> >>>>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>>>> be able to >>>>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>>>> calls, they >>>>>>>>>>> should not be able to make emergency calls). >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>>>> short sighted? >>>>>>>>>>>> >>>>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>>>> >>>>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>>>> >>>>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>>>> Where does it end? >>>>>>>>>>>> >>>>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>>> >>>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>>>> device to >>>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>>>> emergency calls. >>>>>>>>>>>> >>>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>>>> simless phone has "fun" >>>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>>>> opposed to >>>>>>>>>>>> placing real calls. >>>>>>>>>>>> >>>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>>>> That means >>>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>>> >>>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@nsn.com Sun Nov 1 17:32:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0463C3A6809 for ; Sun, 1 Nov 2009 17:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jAB1Hcgtu6u for ; Sun, 1 Nov 2009 17:32:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B69803A6940 for ; Sun, 1 Nov 2009 17:32:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA21X1dn000411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2009 02:33:01 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA21X1Bj003665 for ; Mon, 2 Nov 2009 02:33:01 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 02:33:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 03:33:00 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE1@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-schulzrinne-ecrit-psap-callback-01 Thread-Index: AcpbUEVjLlYbx2LVSRq34DcCu/C/5Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Nov 2009 01:33:01.0268 (UTC) FILETIME=[6A56E940:01CA5B5C] Subject: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:32:46 -0000 Hi all,=20 please take a look at the updated PSAP callback marking document. With this version Milan helped us to incorporate more text about the solution approaches.=20 When Marc and I had a discussion with Cullen and Robert about the milestone updates Cullen indicated that he would like to see an agreement from the group on the solution approach before the document can be added to the milestone list. Furthermore, in the recent 3GPP-IETF conference call we learned that there is interest from the 3GPP in a solution about PSAP callback marking. Milan and Keith are keeping an eye on the requirements from the 3GPP side. =20 Milan has also written another document that could be interesting to consider in this specific context, namely draft-patel-dispatch-cpc-oli-parameter. It provides a solution for an environment that relies on a chain of trust.=20 That's certainly a starting point. But when considering an Internet context then this security model might not be appropriate and we may need an additional solutions. This is similar to the PAI vs. SIP Identity story.=20 It would be great to hear your thoughts about this issue and have a look at the updated document: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 Ciao Hannes From hannes.tschofenig@nsn.com Sun Nov 1 17:32:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF1C3A6975 for ; Sun, 1 Nov 2009 17:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqXhkeDQp2ux for ; Sun, 1 Nov 2009 17:32:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C137D3A696B for ; Sun, 1 Nov 2009 17:32:49 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA21X60F000553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2009 02:33:06 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA21X6U1024907 for ; Mon, 2 Nov 2009 02:33:06 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 02:33:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 03:33:05 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE3@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Agenda Thread-Index: AcpbVPTdjT6ii5v3RnK8zPArqKrXbQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Nov 2009 01:33:06.0647 (UTC) FILETIME=[6D8BAE70:01CA5B5C] Subject: [Ecrit] Updated Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:32:51 -0000 Hi all,=20 I have updated the agenda:=20 http://www.ietf.org/proceedings/09nov/agenda/ecrit.txt I have proposed a few presenters. Please let me know if this works for you. Ciao Hannes --------------- * WG Status Update (Hannes) * LoST Sync (Hannes) http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync Goal: Presentation of the revealed deployment options Make the group aware of the issue and solicit feedback.=20 * SOS Parameter (Milan, remote) http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-07.txt Goal: Draft was updated and generalized. Confirm approach by the group. * Service URN Update (Henning, remote) http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 Goal: Conclude the IANA registration policy proposal.=20 * PSAP Callback (Keith) http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01.txt Goal: Make a decision about the solution approach =20 * ECRIT Direct (Martin) http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-01.txt Goal: Start architecture discussion=20 * Unauthenticated Emergency Services (Dirk) http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces s-06.txt Goal: Decide whether the described approach is viable or whether an approach=20 like ECRIT direct should be taken. * Transformations URN Using LoST (James, remote) http://tools.ietf.org/html/draft-polk-ecrit-lost-transformations-urn-00. txt Goal: This document is a follow-up of draft-polk-ecrit-lost-geocoding-00.txt based on the feedback received by the group at the Stockholm IETF meeting.=20 * Data-Only Emergency Message (Brian, remote) http://tools.ietf.org/html/draft-rosen-ecrit-data-only-ea-00.txt Goal: This is a new document. Solicit feedback from the group.=20 From hannes.tschofenig@nsn.com Sun Nov 1 17:37:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DF13A6873 for ; Sun, 1 Nov 2009 17:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyvj11kX1Evh for ; Sun, 1 Nov 2009 17:37:06 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9816E3A687F for ; Sun, 1 Nov 2009 17:37:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA21bLKe009301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2009 02:37:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA21bJcQ031059 for ; Mon, 2 Nov 2009 02:37:21 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 02:37:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 03:37:18 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE5@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-ecrit-rough-loc-00.txt Thread-Index: AcpbVu9popGT21HVQaW19sEs2B6mkA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Nov 2009 01:37:19.0622 (UTC) FILETIME=[04549A60:01CA5B5D] Subject: [Ecrit] WGLC for draft-ietf-ecrit-rough-loc-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:37:06 -0000 Hi all,=20 this is an ECRIT Working Group Last Call for comments on "Using Imprecise Location for Emergency Context Resolution" http://www.ietf.org/id/draft-ietf-ecrit-rough-loc-00.txt Please send your comments no later than Sunday, November 22, 2009. (extended WGLC because of the IETF meeting in between) Ciao Hannes From mlinsner@cisco.com Mon Nov 2 06:13:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBE73A6A07 for ; Mon, 2 Nov 2009 06:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLkY5iptCcTC for ; Mon, 2 Nov 2009 06:13:38 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4DDAF3A686D for ; Mon, 2 Nov 2009 06:13:38 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAAJ47kpAZnwN/2dsb2JhbACCIzCXUqsIiWQyjEaCNQaBfgSMBA X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="scan'208,217";a="66010164" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2009 14:13:57 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA2EDvNQ022326; Mon, 2 Nov 2009 14:13:57 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 09:13:57 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 09:13:55 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 09:13:54 -0500 From: Marc Linsner To: Brian Rosen , Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2Q== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339998035_321754" X-OriginalArrivalTime: 02 Nov 2009 14:13:55.0941 (UTC) FILETIME=[B6A52950:01CA5BC6] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:13:46 -0000 > 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. --B_3339998035_321754 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I have no problem with indications that advise the PSAP call-taker: 1. =B3This caller is using a SP we don=B9t know, please query the caller as to their identity and location.=B2 2. =B3There is no validation that the IP address of this caller exists at the reported location, please query further about location.=B2 I have a problem with: 1. Queuing the call (as in prior to a human answering) or responding to a call based on the SP (or lack thereof) the caller utilized. I have no problem with: 1. Requiring that calls to the ESInet meet a set of open global Industry standard protocol specifications. This thread started when you described what happens in a PSAP call overload situation. Determining the validity/urgency of an emergency call cannot happen based on the SP utilized, the failure scenario of the algorithm is disastrous. -Marc- On 10/31/09 8:43 AM, "Brian Rosen" wrote: > You are looking for trouble when there isn't any. >=20 > First of all, the latest example is that of a service provider, and not > entirely p2p. That's what we expect, and we don't expect the scenario yo= u > are trying to paint. >=20 > Then, ANY provider, regardless of size, should arrange to get whatever > credential we end up deploying. That means: > A) The devices on their network and/or their own network elements yield > phonebcp compliant emergency calls > B) They correctly forward such calls to the ESInet > C) They include the additional information we ask for, which includes > appropriate contact info >=20 > It doesn't mean much more than that. It does give us some basis for maki= ng > choices, when we have to make choices, about calls. And please remember, > we're nearly always taking calls wherever they come from: the scenario we > are spilling all these bits in the last several messages is something we > hope roughly never happens, but we plan for it anyway. >=20 > I think PSAPs and their contractors will be trying to be proactive about > looking for calls from unknown providers, but as always, the ones with th= e > most calls are going to get more attention than the ones who have fewer > calls. That's all I meant. Actually, it occurs to me that they probably > will go after providers who send calls that don't follow the rules before > they go after well behaving, but unknown providers. >=20 > Brian >=20 >=20 > On 10/31/09 8:54 AM, "Marc Linsner" wrote: >=20 >> > >> > >> > >> > On 10/30/09 6:41 PM, "Brian Rosen" wrote: >> > >>> >> I don't see that as a big problem. There aren't going to be thousan= ds of >>> >> such successful service providers. It usually quickly settles Darwi= nian >>> >> style to one or two. When the PSAPs see a bunch of calls from some = new >>> >> source, they will call them up, and get them on the "we know you" li= st. No >>> >> big deal.=20 >>> >> >>> >> You are still speculating about something that hasn't happened, and = you >>> >> can't find a good predecessor. The latest "thing" is the social >>> newtworks, >>> >> there were maybe 50 of them, and now there are maybe 5 or 6 that mat= ter. >> > >> > Exactly my point. In the scenario you've painted, the PSAP is going t= o >> > evaluate the validity/urgency of the request for emergency assistance >> > differently for their customers (as in the PSAP's customer) that chose= to >> > use social network 7-50 verses 1-6. Please explain how my emergency i= s >> > lesser of a priority because I buy services from social network provid= er >> > #29. This is not the right tool for the PSAP to use for this purpose. >> > Simply stating these are the only tools available is not good enough. >> > >> > -Marc- >> > >>> >> >>> >> Brian >>> >> >>> >> >>> >> On 10/30/09 6:12 PM, "Marc Linsner" wrote: >>> >> >>>> >>> It's not that I necessarily believe there will be a lack of SPs. = I >>>> believe >>>> >>> the mix of SPs and the products they offer will change dramaticall= y at a >>>> >>> pace that PSAPs won't be able to keep up. This week Google, next = week >>>> >>> Noggle, the next week Boogle, etc. If in fact the PSAP requires >>>> >>> relationships with every SP that may send an emergency call their = way, it >>>> >>> will only stifle innovation. >>>> >>> >>>> >>> -Marc- >>>> >>> >>>> >>> >>>> >>> On 10/30/09 4:55 PM, "Brian Rosen" wrote: >>>> >>> >>>>> >>>> There is way too much speculation here. >>>>> >>>> >>>>> >>>> You are speculating that there will be interesting services with= out >>>>> service >>>>> >>>> providers that have two way interactive media, where the identit= y of the >>>>> >>>> callers is a simple domain name, emergency calls from those devi= ces is >>>>> >>>> interesting, they can't provide a suitable callback without a >>>>> registration >>>>> >>>> from the ESRP, and such calls wont be the preferred abuse call >>>>> source. >>>>> >>>> >>>>> >>>> When we have that problem, if we ever have that problem, we'll s= olve it. >>>>> >>>> >>>>> >>>> Right now, the simpler case of a direct call from an unknown sou= rce >>>>> because >>>>> >>>> you have a proxy server in your boat will get through just fine >>>>> nearly all >>>>> >>>> the time. When it doesn't, it will be because that path is bein= g >>>>> used by >>>>> >>>> someone attacking, and the lack of a service provider will proba= bly >>>>> be to >>>>> >>>> the disadvantage of the direct caller. I'm not going to lose sl= eep over >>>>> >>>> that problem. I'd rather beef up the system so we don't have to= drop >>>>> calls >>>>> >>>> when we're attacked. OTOH, I don't want to promote the proxy se= rver >>>>> in the >>>>> >>>> boat idea. If it happens occasionally, we'll cope. >>>>> >>>> >>>>> >>>> Brian >>>>> >>>> >>>>> >>>> >>>>> >>>> On 10/30/09 4:14 PM, "Marc Linsner" wrote: >>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On 10/30/09 2:29 PM, "Brian Rosen" wrote: >>>>>> >>>>> >>>>>>> >>>>>> I'm the messenger here. PSAPs prefer service providers to b= e on >>>>>>> the path >>>>>>> >>>>>> of >>>>>>> >>>>>> a call, and they have bad experiences when they aren't. >>>>>>> >>>>>> >>>>>>> >>>>>> Given their experiences, I can't fault them. >>>>>>> >>>>>> >>>>>>> >>>>>> The reason the text is in phonebcp is as you said it is: bec= ause >>>>>>> "normal" >>>>>>> >>>>>> is >>>>>>> >>>>>> likely to work. The fact that "normal" means SP path in 99.= 999% >>>>>>> of cases >>>>>>> >>>>>> gets the PSAPs what they want. They don't care about why we= did >>>>>>> it, they >>>>>>> >>>>>> care they get the right result. >>>>>> >>>>> >>>>>> >>>>> I, like others, believe the role/definition of the 'SP', as >>>>>> currently >>>>>> >>>>> defined by the PSAPs, will change significantly going forward. >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> I don't believe we are going to see vanity domains used on c= alls, and >>>>>>> >>>>>> even >>>>>>> >>>>>> if they were in "From", they won't be the domain in >>>>>>> P-Asserted-Identity, >>>>>>> >>>>>> or >>>>>>> >>>>>> the SubjectAltName of the Identity signature. If some servi= ce >>>>>>> that used >>>>>>> >>>>>> email addresses as identities sent us calls, the email addre= ss >>>>>>> (with its >>>>>>> >>>>>> domain) is the "userpart" of the identity, not the whole thi= ng. There >>>>>>> >>>>>> are >>>>>>> >>>>>> some interesting problems when you have URI to something lik= e the MS IM >>>>>>> >>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets esc= aped. We've >>>>>>> >>>>>> built systems that handle that. >>>>>> >>>>> >>>>>> >>>>> I think this is a little short-sighted. Certificates for vani= ty >>>>>> domains >>>>>> >>>>> are >>>>>> >>>>> certainly doable. Besides P-Asserted-Identity is not a MUST i= n >>>>>> phonebcp. >>>>>> >>>>> :^) >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> The Firewall/Session Border controls will have several crite= ria when >>>>>>> >>>>>> PSAPs >>>>>>> >>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do = what you >>>>>>> >>>>>> suggest >>>>>>> >>>>>> other than the repeat offender rule, which is the first line= of >>>>>>> defense. >>>>>>> >>>>>> They do filter based on criteria that equate to IP Address o= r >>>>>>> Domain of >>>>>>> >>>>>> the >>>>>>> >>>>>> SP, which we can deal with. We'll use what works for the ot= her >>>>>>> users of >>>>>>> >>>>>> these systems, we're unlikely to be able to have emergency >>>>>>> services >>>>>>> >>>>>> special >>>>>>> >>>>>> firewalls or SBCs. >>>>>> >>>>> >>>>>> >>>>> We're not talking about existing firewalls and SBCs. We're ta= lking about >>>>>> >>>>> ESInet Border Control Function. If you don't define what you = want >>>>>> there, >>>>>> >>>>> you'll live with what you get. My suggestions are not beyond >>>>>> what's >>>>>> >>>>> possible, it's all software. >>>>>> >>>>> >>>>>> >>>>> -Marc- >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>> >>>>> >>>> >>>> >>> >>>> >>> >>> >> >>> >> >> > >> > >=20 >=20 >=20 --B_3339998035_321754 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>I have no problem with indications that advise the PSAP call-taker:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>“This caller is using  a SP we don’= t know, please query the caller as to their identity and location.” </SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:11pt'>“There is no validation that the IP address of thi= s caller exists at the reported location, please query further about locatio= n.”<BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> I have a problem with:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>Queuing  the call (as in prior to a human answe= ring) or responding to a call based on the SP (or lack thereof) the caller u= tilized.<BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> I have no problem with:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>Requiring that calls to the ESInet meet a set of ope= n global Industry standard protocol specifications. <BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> This thread started when you described what happens in a PSAP call overload= situation.  Determining the validity/urgency of an emergency call cann= ot happen based on the SP utilized, the failure scenario of the algorithm is= disastrous.<BR> <BR> -Marc-<BR> <BR> <BR> <BR> On 10/31/09 8:43 AM, "Brian Rosen" <<a href=3D"br@brianrosen.net= ">br@brianrosen.net</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>You are looking for trouble when there isn't any= .<BR> <BR> First of all, the latest example is that of a service provider, and not<BR> entirely p2p.  That's what we expect, and we don't expect the scenario= you<BR> are trying to paint.<BR> <BR> Then, ANY provider, regardless of size, should arrange to get whatever<BR> credential we end up deploying.  That means:<BR> A) The devices on their network and/or their own network elements yield<BR> phonebcp compliant emergency calls<BR> B) They correctly forward such calls to the ESInet<BR> C) They include the additional information we ask for, which includes<BR> appropriate contact info<BR> <BR> It doesn't mean much more than that.  It does give us some basis for m= aking<BR> choices, when we have to make choices, about calls.  And please rememb= er,<BR> we're nearly always taking calls wherever they come from: the scenario we<B= R> are spilling all these bits in the last several messages is something we<BR= > hope roughly never happens, but we plan for it anyway.<BR> <BR> I think PSAPs and their contractors will be trying to be proactive about<BR= > looking for calls from unknown providers, but as always, the ones with the<= BR> most calls are going to get more attention than the ones who have fewer<BR> calls.  That's all I meant.  Actually, it occurs to me that they = probably<BR> will go after providers who send calls that don't follow the rules before<B= R> they go after well behaving, but unknown providers.<BR> <BR> Brian<BR> <BR> <BR> On 10/31/09 8:54 AM, "Marc Linsner" <<a href=3D"mlinsner@cisco.c= om">mlinsner@cisco.com</a>> wrote:<BR> <BR> ><BR> ><BR> ><BR> > On 10/30/09 6:41 PM, "Brian Rosen" <<a href=3D"br@brianrose= n.net">br@brianrosen.net</a>> wrote:<BR> ><BR> >> I don't see that as a big problem.  There aren't going to be = thousands of<BR> >> such successful service providers.  It usually quickly settle= s Darwinian<BR> >> style to one or two.  When the PSAPs see a bunch of calls fro= m some new<BR> >> source, they will call them up, and get them on the "we know = you" list.  No<BR> >> big deal. <BR> >><BR> >> You are still speculating about something that hasn't happened, an= d you<BR> >> can't find a good predecessor.  The latest "thing" = is the social newtworks,<BR> >> there were maybe 50 of them, and now there are maybe 5 or 6 that m= atter.<BR> ><BR> > Exactly my point.  In the scenario you've painted, the PSAP is go= ing to<BR> > evaluate the validity/urgency of the request for emergency assistance<= BR> > differently for their customers (as in the PSAP's customer) that chose= to<BR> > use social network 7-50 verses 1-6.  Please explain how my emerge= ncy is<BR> > lesser of a priority because I buy services from social network provid= er<BR> > #29.  This is not the right tool for the PSAP to use for this pur= pose.<BR> > Simply stating these are the only tools available is not good enough.<= BR> ><BR> > -Marc-<BR> ><BR> >><BR> >> Brian<BR> >><BR> >><BR> >> On 10/30/09 6:12 PM, "Marc Linsner" <<a href=3D"mlinsne= r@cisco.com">mlinsner@cisco.com</a>> wrote:<BR> >><BR> >>> It's not that I necessarily believe there will be a lack of SP= s.  I believe<BR> >>> the mix of SPs and the products they offer will change dramati= cally at a<BR> >>> pace that PSAPs won't be able to keep up.  This week Goog= le, next week<BR> >>> Noggle, the next week Boogle, etc.  If in fact the PSAP r= equires<BR> >>> relationships with every SP that may send an emergency call th= eir way, it<BR> >>> will only stifle innovation.<BR> >>><BR> >>> -Marc-<BR> >>><BR> >>><BR> >>> On 10/30/09 4:55 PM, "Brian Rosen" <<a href=3D"br@b= rianrosen.net">br@brianrosen.net</a>> wrote:<BR> >>><BR> >>>> There is way too much speculation here.<BR> >>>><BR> >>>> You are speculating that there will be interesting service= s without service<BR> >>>> providers that have two way interactive media, where the i= dentity of the<BR> >>>> callers is a simple domain name, emergency calls from thos= e devices is<BR> >>>> interesting, they can't provide a suitable callback withou= t a registration<BR> >>>> from the ESRP, and such calls wont be the preferred abuse = call source.<BR> >>>><BR> >>>> When we have that problem, if we ever have that problem, w= e'll solve it.<BR> >>>><BR> >>>> Right now, the simpler case of a direct call from an unkno= wn source because<BR> >>>> you have a proxy server in your boat will get through just= fine nearly all<BR> >>>> the time.  When it doesn't, it will be because that p= ath is being used by<BR> >>>> someone attacking, and the lack of a service provider will= probably be to<BR> >>>> the disadvantage of the direct caller.  I'm not going= to lose sleep over<BR> >>>> that problem.  I'd rather beef up the system so we do= n't have to drop calls<BR> >>>> when we're attacked.  OTOH, I don't want to promote t= he proxy server in the<BR> >>>> boat idea.  If it happens occasionally, we'll cope.<B= R> >>>><BR> >>>> Brian<BR> >>>><BR> >>>><BR> >>>> On 10/30/09 4:14 PM, "Marc Linsner" <<a href=3D= "mlinsner@cisco.com">mlinsner@cisco.com</a>> wrote:<BR> >>>><BR> >>>>><BR> >>>>><BR> >>>>> On 10/30/09 2:29 PM, "Brian Rosen" <<a hr= ef=3D"br@brianrosen.net">br@brianrosen.net</a>> wrote:<BR> >>>>><BR> >>>>>> I'm the messenger here.  PSAPs prefer service= providers to be on the path<BR> >>>>>> of<BR> >>>>>> a call, and they have bad experiences when they ar= en't.<BR> >>>>>><BR> >>>>>> Given their experiences, I can't fault them.<BR> >>>>>><BR> >>>>>> The reason the text is in phonebcp is as you said = it is: because "normal"<BR> >>>>>> is<BR> >>>>>> likely to work.  The fact that "normal&q= uot; means SP path in 99.999% of cases<BR> >>>>>> gets the PSAPs what they want.  They don't ca= re about why we did it, they<BR> >>>>>> care they get the right result.<BR> >>>>><BR> >>>>> I, like others, believe the role/definition of the 'SP= ', as currently<BR> >>>>> defined by the PSAPs, will change significantly going = forward.<BR> >>>>><BR> >>>>>><BR> >>>>>> I don't believe we are going to see vanity domains= used on calls, and<BR> >>>>>> even<BR> >>>>>> if they were in "From", they won't be th= e domain in P-Asserted-Identity,<BR> >>>>>> or<BR> >>>>>> the SubjectAltName of the Identity signature. &nbs= p;If some service that used<BR> >>>>>> email addresses as identities sent us calls, the e= mail address (with its<BR> >>>>>> domain) is the "userpart" of the identit= y, not the whole thing.  There<BR> >>>>>> are<BR> >>>>>> some interesting problems when you have URI to som= ething like the MS IM<BR> >>>>>> systems.  The first "@' (<a href=3D"br@bri= anrosen.net">br@brianrosen.net</a>@msn.com) gets escaped.  We've<BR> >>>>>> built systems that handle that.<BR> >>>>><BR> >>>>> I think this is a little short-sighted.  Certific= ates for vanity domains<BR> >>>>> are<BR> >>>>> certainly doable.  Besides P-Asserted-Identity is= not a MUST in phonebcp.<BR> >>>>> :^)<BR> >>>>><BR> >>>>>><BR> >>>>>> The Firewall/Session Border controls will have sev= eral criteria when<BR> >>>>>> PSAPs<BR> >>>>>> are overloaded, but AFAIK, no existing firewalls o= r SBCs do what you<BR> >>>>>> suggest<BR> >>>>>> other than the repeat offender rule, which is the = first line of defense.<BR> >>>>>> They do filter based on criteria that equate to IP= Address or Domain of<BR> >>>>>> the<BR> >>>>>> SP, which we can deal with.  We'll use what w= orks for the other users of<BR> >>>>>> these systems, we're unlikely to be able to have e= mergency services<BR> >>>>>> special<BR> >>>>>> firewalls or SBCs.<BR> >>>>><BR> >>>>> We're not talking about existing firewalls and SBCs. &= nbsp;We're talking about<BR> >>>>> ESInet Border Control Function.  If you don't def= ine what you want there,<BR> >>>>> you'll live with what you get.  My suggestions ar= e not beyond what's<BR> >>>>> possible, it's all software.<BR> >>>>><BR> >>>>> -Marc-<BR> >>>>><BR> >>>>><BR> >>>>><BR> >>>>><BR> >>>><BR> >>>><BR> >>><BR> >>><BR> >><BR> >><BR> ><BR> ><BR> <BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3339998035_321754-- From br@brianrosen.net Mon Nov 2 06:53:25 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E746228C15B for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 06:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6mrz3EoDMLY for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 06:53:17 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C18B528C16F for <ecrit@ietf.org>; Mon, 2 Nov 2009 06:53:16 -0800 (PST) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1N4yHh-0005kC-Dp; Mon, 02 Nov 2009 08:53:30 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 09:53:26 -0400 From: Brian Rosen <br@brianrosen.net> To: Marc Linsner <mlinsner@cisco.com>, <ecrit@ietf.org> Message-ID: <C7145C96.1EB23%br@brianrosen.net> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWC In-Reply-To: <C7145352.1CF5B%mlinsner@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340000415_20739401" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 02 Nov 2009 14:53:26 -0000 > 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. --B_3340000415_20739401 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sorry, it=B9s an effective strategy. There aren=B9t many better ones when you can=B9t filter by attack signature or specific source address. When 99.99% o= f legitimate calls come from SPs you know, then filtering ones you don=B9t when attacks come that way works well. The current 9-1-1 system in the U.S. has an even worse mechanism. It uses small trunk group sizes to limit how many calls an origination switch can send towards the PSAP. This is the main defense against a local surge of calls. Unfortunately, legitimate calls from callers not related to the surge who happen to be on the same switch get caught. Compared to that, this is strategy is great. If it=B9s not effective, that is, when attacks come from sources you know, which certainly is feasible with many bot-net style attacks, then of course we wouldn=B9t use it. Our primary strategy is spread calls out to every available call taker. 20,000 on duty call takers can process A LOT of bad calls. Of course, there are some attacks which would overwhelm that strategy. We fall back to others. PSAPs like SPs. Please remember that. SPs are really common. No SP is really, really uncommon. If that changes (by itself, not because we did something stupid), then the strategy of filtering by source won=B9t be effective any more. But keep in mind that my major objection to =ADdirect is not the effect it ma= y have on attack filtering, it=B9s the abuse potential. Brian On 11/2/09 10:13 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: > I have no problem with indications that advise the PSAP call-taker: >=20 > 1. =B3This caller is using a SP we don=B9t know, please query the caller as = to > their identity and location.=B2 > 2. =B3There is no validation that the IP address of this caller exists at t= he > reported location, please query further about location.=B2 >=20 > I have a problem with: >=20 > 1. Queuing the call (as in prior to a human answering) or responding to = a > call based on the SP (or lack thereof) the caller utilized. >=20 > I have no problem with: >=20 > 1. Requiring that calls to the ESInet meet a set of open global Industry > standard protocol specifications. >=20 > This thread started when you described what happens in a PSAP call overlo= ad > situation. Determining the validity/urgency of an emergency call cannot > happen based on the SP utilized, the failure scenario of the algorithm is > disastrous. >=20 > -Marc- >=20 >=20 >=20 > On 10/31/09 8:43 AM, "Brian Rosen" <br@brianrosen.net> wrote: >=20 >> You are looking for trouble when there isn't any. >>=20 >> First of all, the latest example is that of a service provider, and not >> entirely p2p. That's what we expect, and we don't expect the scenario y= ou >> are trying to paint. >>=20 >> Then, ANY provider, regardless of size, should arrange to get whatever >> credential we end up deploying. That means: >> A) The devices on their network and/or their own network elements yield >> phonebcp compliant emergency calls >> B) They correctly forward such calls to the ESInet >> C) They include the additional information we ask for, which includes >> appropriate contact info >>=20 >> It doesn't mean much more than that. It does give us some basis for mak= ing >> choices, when we have to make choices, about calls. And please remember= , >> we're nearly always taking calls wherever they come from: the scenario w= e >> are spilling all these bits in the last several messages is something we >> hope roughly never happens, but we plan for it anyway. >>=20 >> I think PSAPs and their contractors will be trying to be proactive about >> looking for calls from unknown providers, but as always, the ones with t= he >> most calls are going to get more attention than the ones who have fewer >> calls. That's all I meant. Actually, it occurs to me that they probabl= y >> will go after providers who send calls that don't follow the rules befor= e >> they go after well behaving, but unknown providers. >>=20 >> Brian >>=20 >>=20 >> On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>=20 >>> > >>> > >>> > >>> > On 10/30/09 6:41 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>> > >>>> >> I don't see that as a big problem. There aren't going to be thousa= nds of >>>> >> such successful service providers. It usually quickly settles Darw= inian >>>> >> style to one or two. When the PSAPs see a bunch of calls from some= new >>>> >> source, they will call them up, and get them on the "we know you" l= ist. No >>>> >> big deal.=20 >>>> >> >>>> >> You are still speculating about something that hasn't happened, and= you >>>> >> can't find a good predecessor. The latest "thing" is the social >>>> newtworks, >>>> >> there were maybe 50 of them, and now there are maybe 5 or 6 that ma= tter. >>> > >>> > Exactly my point. In the scenario you've painted, the PSAP is going = to >>> > evaluate the validity/urgency of the request for emergency assistance >>> > differently for their customers (as in the PSAP's customer) that chos= e to >>> > use social network 7-50 verses 1-6. Please explain how my emergency = is >>> > lesser of a priority because I buy services from social network provi= der >>> > #29. This is not the right tool for the PSAP to use for this purpose= . >>> > Simply stating these are the only tools available is not good enough. >>> > >>> > -Marc- >>> > >>>> >> >>>> >> Brian >>>> >> >>>> >> >>>> >> On 10/30/09 6:12 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>> >> >>>>> >>> It's not that I necessarily believe there will be a lack of SPs. = I >>>>> believe >>>>> >>> the mix of SPs and the products they offer will change dramatical= ly at a >>>>> >>> pace that PSAPs won't be able to keep up. This week Google, next= week >>>>> >>> Noggle, the next week Boogle, etc. If in fact the PSAP requires >>>>> >>> relationships with every SP that may send an emergency call their= way, it >>>>> >>> will only stifle innovation. >>>>> >>> >>>>> >>> -Marc- >>>>> >>> >>>>> >>> >>>>> >>> On 10/30/09 4:55 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>> >>> >>>>>> >>>> There is way too much speculation here. >>>>>> >>>> >>>>>> >>>> You are speculating that there will be interesting services wit= hout >>>>>> service >>>>>> >>>> providers that have two way interactive media, where the identi= ty of the >>>>>> >>>> callers is a simple domain name, emergency calls from those dev= ices is >>>>>> >>>> interesting, they can't provide a suitable callback without a >>>>>> registration >>>>>> >>>> from the ESRP, and such calls wont be the preferred abuse call >>>>>> source. >>>>>> >>>> >>>>>> >>>> When we have that problem, if we ever have that problem, we'll = solve it. >>>>>> >>>> >>>>>> >>>> Right now, the simpler case of a direct call from an unknown so= urce >>>>>> because >>>>>> >>>> you have a proxy server in your boat will get through just fine >>>>>> nearly all >>>>>> >>>> the time. When it doesn't, it will be because that path is bei= ng >>>>>> used by >>>>>> >>>> someone attacking, and the lack of a service provider will prob= ably >>>>>> be to >>>>>> >>>> the disadvantage of the direct caller. I'm not going to lose s= leep over >>>>>> >>>> that problem. I'd rather beef up the system so we don't have t= o >>>>>> drop calls >>>>>> >>>> when we're attacked. OTOH, I don't want to promote the proxy s= erver >>>>>> in the >>>>>> >>>> boat idea. If it happens occasionally, we'll cope. >>>>>> >>>> >>>>>> >>>> Brian >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> On 10/30/09 4:14 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> On 10/30/09 2:29 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>>> >>>>> >>>>>>>> >>>>>> I'm the messenger here. PSAPs prefer service providers to = be on >>>>>>>> the path >>>>>>>> >>>>>> of >>>>>>>> >>>>>> a call, and they have bad experiences when they aren't. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Given their experiences, I can't fault them. >>>>>>>> >>>>>> >>>>>>>> >>>>>> The reason the text is in phonebcp is as you said it is: be= cause >>>>>>>> "normal" >>>>>>>> >>>>>> is >>>>>>>> >>>>>> likely to work. The fact that "normal" means SP path in 99= .999% >>>>>>>> of cases >>>>>>>> >>>>>> gets the PSAPs what they want. They don't care about why w= e did >>>>>>>> it, they >>>>>>>> >>>>>> care they get the right result. >>>>>>> >>>>> >>>>>>> >>>>> I, like others, believe the role/definition of the 'SP', as >>>>>>> currently >>>>>>> >>>>> defined by the PSAPs, will change significantly going forward= . >>>>>>> >>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> I don't believe we are going to see vanity domains used on >>>>>>>> calls, and >>>>>>>> >>>>>> even >>>>>>>> >>>>>> if they were in "From", they won't be the domain in >>>>>>>> P-Asserted-Identity, >>>>>>>> >>>>>> or >>>>>>>> >>>>>> the SubjectAltName of the Identity signature. If some serv= ice >>>>>>>> that used >>>>>>>> >>>>>> email addresses as identities sent us calls, the email addr= ess >>>>>>>> (with its >>>>>>>> >>>>>> domain) is the "userpart" of the identity, not the whole th= ing. There >>>>>>>> >>>>>> are >>>>>>>> >>>>>> some interesting problems when you have URI to something li= ke >>>>>>>> the MS IM >>>>>>>> >>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets >>>>>>>> escaped. We've >>>>>>>> >>>>>> built systems that handle that. >>>>>>> >>>>> >>>>>>> >>>>> I think this is a little short-sighted. Certificates for van= ity >>>>>>> domains >>>>>>> >>>>> are >>>>>>> >>>>> certainly doable. Besides P-Asserted-Identity is not a MUST = in >>>>>>> phonebcp. >>>>>>> >>>>> :^) >>>>>>> >>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> The Firewall/Session Border controls will have several crit= eria when >>>>>>>> >>>>>> PSAPs >>>>>>>> >>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do= what you >>>>>>>> >>>>>> suggest >>>>>>>> >>>>>> other than the repeat offender rule, which is the first lin= e of >>>>>>>> defense. >>>>>>>> >>>>>> They do filter based on criteria that equate to IP Address = or >>>>>>>> Domain of >>>>>>>> >>>>>> the >>>>>>>> >>>>>> SP, which we can deal with. We'll use what works for the o= ther >>>>>>>> users of >>>>>>>> >>>>>> these systems, we're unlikely to be able to have emergency >>>>>>>> services >>>>>>>> >>>>>> special >>>>>>>> >>>>>> firewalls or SBCs. >>>>>>> >>>>> >>>>>>> >>>>> We're not talking about existing firewalls and SBCs. We're >>>>>>> talking about >>>>>>> >>>>> ESInet Border Control Function. If you don't define what you= want >>>>>>> there, >>>>>>> >>>>> you'll live with what you get. My suggestions are not beyond >>>>>>> what's >>>>>>> >>>>> possible, it's all software. >>>>>>> >>>>> >>>>>>> >>>>> -Marc- >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>> >>>>>> >>>> >>>>> >>> >>>>> >>> >>>> >> >>>> >> >>> > >>> > >>=20 >>=20 >>=20 >=20 --B_3340000415_20739401 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Sorry, it’s an effective strategy.  There aren’t many bet= ter ones when you can’t filter by attack signature or specific source = address.  When 99.99% of legitimate calls come from SPs you know, then = filtering ones you don’t when attacks come that way works well.<BR> <BR> The current 9-1-1 system in the U.S. has an even worse mechanism.  It = uses small trunk group sizes to limit how many calls an origination switch c= an send towards the PSAP.  This is the main defense against a local sur= ge of calls.  Unfortunately, legitimate calls from callers not related = to the surge who happen to be on the same switch get caught.  Compared = to that, this is strategy is great.<BR> <BR> If it’s not effective, that is, when attacks come from sources you kn= ow, which certainly is feasible with many bot-net style attacks, then of cou= rse we wouldn’t use it.  Our primary strategy is spread calls out= to every available call taker.  20,000 on duty call takers can process= A LOT of bad calls.  Of course, there are some attacks which would ove= rwhelm that strategy.  We fall back to others.<BR> <BR> PSAPs like SPs.  Please remember that.  SPs are really common. &n= bsp;No SP is really, really uncommon.  If that changes (by itself, not = because we did something stupid), then the strategy of filtering by source w= on’t be effective any more.<BR> <BR> But keep in mind that my major objection to –direct is not the effect= it may have on attack filtering, it’s the abuse potential.<BR> <BR> Brian<BR> <BR> <BR> On 11/2/09 10:13 AM, "Marc Linsner" <<a href=3D"mlinsner@cisco.c= om">mlinsner@cisco.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>I have no problem with indications that advise t= he PSAP call-taker:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>“This caller is using  a SP we don’= t know, please query the caller as to their identity and location.”=20 </SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:11pt'>“There is no validation that the IP address of thi= s caller exists at the reported location, please query further about locatio= n.”<BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> I have a problem with:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>Queuing  the call (as in prior to a human answe= ring) or responding to a call based on the SP (or lack thereof) the caller u= tilized.<BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> I have no problem with:<BR> <BR> </SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>Requiring that calls to the ESInet meet a set of ope= n global Industry standard protocol specifications. <BR> </SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> This thread started when you described what happens in a PSAP call overload= situation.  Determining the validity/urgency of an emergency call cann= ot happen based on the SP utilized, the failure scenario of the algorithm is= disastrous.<BR> <BR> -Marc-<BR> <BR> <BR> <BR> On 10/31/09 8:43 AM, "Brian Rosen" <<a href=3D"br@brianrosen.net= ">br@brianrosen.net</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>You are looking for trouble when there isn't any= .<BR> <BR> First of all, the latest example is that of a service provider, and not<BR> entirely p2p.  That's what we expect, and we don't expect the scenario= you<BR> are trying to paint.<BR> <BR> Then, ANY provider, regardless of size, should arrange to get whatever<BR> credential we end up deploying.  That means:<BR> A) The devices on their network and/or their own network elements yield<BR> phonebcp compliant emergency calls<BR> B) They correctly forward such calls to the ESInet<BR> C) They include the additional information we ask for, which includes<BR> appropriate contact info<BR> <BR> It doesn't mean much more than that.  It does give us some basis for m= aking<BR> choices, when we have to make choices, about calls.  And please rememb= er,<BR> we're nearly always taking calls wherever they come from: the scenario we<B= R> are spilling all these bits in the last several messages is something we<BR= > hope roughly never happens, but we plan for it anyway.<BR> <BR> I think PSAPs and their contractors will be trying to be proactive about<BR= > looking for calls from unknown providers, but as always, the ones with the<= BR> most calls are going to get more attention than the ones who have fewer<BR> calls.  That's all I meant.  Actually, it occurs to me that they = probably<BR> will go after providers who send calls that don't follow the rules before<B= R> they go after well behaving, but unknown providers.<BR> <BR> Brian<BR> <BR> <BR> On 10/31/09 8:54 AM, "Marc Linsner" <<a href=3D"mlinsner@cisco.c= om">mlinsner@cisco.com</a>> wrote:<BR> <BR> ><BR> ><BR> ><BR> > On 10/30/09 6:41 PM, "Brian Rosen" <<a href=3D"br@brianrose= n.net">br@brianrosen.net</a>> wrote:<BR> ><BR> >> I don't see that as a big problem.  There aren't going to be = thousands of<BR> >> such successful service providers.  It usually quickly settle= s Darwinian<BR> >> style to one or two.  When the PSAPs see a bunch of calls fro= m some new<BR> >> source, they will call them up, and get them on the "we know = you" list.  No<BR> >> big deal. <BR> >><BR> >> You are still speculating about something that hasn't happened, an= d you<BR> >> can't find a good predecessor.  The latest "thing" = is the social newtworks,<BR> >> there were maybe 50 of them, and now there are maybe 5 or 6 that m= atter.<BR> ><BR> > Exactly my point.  In the scenario you've painted, the PSAP is go= ing to<BR> > evaluate the validity/urgency of the request for emergency assistance<= BR> > differently for their customers (as in the PSAP's customer) that chose= to<BR> > use social network 7-50 verses 1-6.  Please explain how my emerge= ncy is<BR> > lesser of a priority because I buy services from social network provid= er<BR> > #29.  This is not the right tool for the PSAP to use for this pur= pose.<BR> > Simply stating these are the only tools available is not good enough.<= BR> ><BR> > -Marc-<BR> ><BR> >><BR> >> Brian<BR> >><BR> >><BR> >> On 10/30/09 6:12 PM, "Marc Linsner" <<a href=3D"mlinsne= r@cisco.com">mlinsner@cisco.com</a>> wrote:<BR> >><BR> >>> It's not that I necessarily believe there will be a lack of SP= s.  I believe<BR> >>> the mix of SPs and the products they offer will change dramati= cally at a<BR> >>> pace that PSAPs won't be able to keep up.  This week Goog= le, next week<BR> >>> Noggle, the next week Boogle, etc.  If in fact the PSAP r= equires<BR> >>> relationships with every SP that may send an emergency call th= eir way, it<BR> >>> will only stifle innovation.<BR> >>><BR> >>> -Marc-<BR> >>><BR> >>><BR> >>> On 10/30/09 4:55 PM, "Brian Rosen" <<a href=3D"br@b= rianrosen.net">br@brianrosen.net</a>> wrote:<BR> >>><BR> >>>> There is way too much speculation here.<BR> >>>><BR> >>>> You are speculating that there will be interesting service= s without service<BR> >>>> providers that have two way interactive media, where the i= dentity of the<BR> >>>> callers is a simple domain name, emergency calls from thos= e devices is<BR> >>>> interesting, they can't provide a suitable callback withou= t a registration<BR> >>>> from the ESRP, and such calls wont be the preferred abuse = call source.<BR> >>>><BR> >>>> When we have that problem, if we ever have that problem, w= e'll solve it.<BR> >>>><BR> >>>> Right now, the simpler case of a direct call from an unkno= wn source because<BR> >>>> you have a proxy server in your boat will get through just= fine nearly all<BR> >>>> the time.  When it doesn't, it will be because that p= ath is being used by<BR> >>>> someone attacking, and the lack of a service provider will= probably be to<BR> >>>> the disadvantage of the direct caller.  I'm not going= to lose sleep over<BR> >>>> that problem.  I'd rather beef up the system so we do= n't have to drop calls<BR> >>>> when we're attacked.  OTOH, I don't want to promote t= he proxy server in the<BR> >>>> boat idea.  If it happens occasionally, we'll cope.<B= R> >>>><BR> >>>> Brian<BR> >>>><BR> >>>><BR> >>>> On 10/30/09 4:14 PM, "Marc Linsner" <<a href=3D= "mlinsner@cisco.com">mlinsner@cisco.com</a>> wrote:<BR> >>>><BR> >>>>><BR> >>>>><BR> >>>>> On 10/30/09 2:29 PM, "Brian Rosen" <<a hr= ef=3D"br@brianrosen.net">br@brianrosen.net</a>> wrote:<BR> >>>>><BR> >>>>>> I'm the messenger here.  PSAPs prefer service= providers to be on the path<BR> >>>>>> of<BR> >>>>>> a call, and they have bad experiences when they ar= en't.<BR> >>>>>><BR> >>>>>> Given their experiences, I can't fault them.<BR> >>>>>><BR> >>>>>> The reason the text is in phonebcp is as you said = it is: because "normal"<BR> >>>>>> is<BR> >>>>>> likely to work.  The fact that "normal&q= uot; means SP path in 99.999% of cases<BR> >>>>>> gets the PSAPs what they want.  They don't ca= re about why we did it, they<BR> >>>>>> care they get the right result.<BR> >>>>><BR> >>>>> I, like others, believe the role/definition of the 'SP= ', as currently<BR> >>>>> defined by the PSAPs, will change significantly going = forward.<BR> >>>>><BR> >>>>>><BR> >>>>>> I don't believe we are going to see vanity domains= used on calls, and<BR> >>>>>> even<BR> >>>>>> if they were in "From", they won't be th= e domain in P-Asserted-Identity,<BR> >>>>>> or<BR> >>>>>> the SubjectAltName of the Identity signature. &nbs= p;If some service that used<BR> >>>>>> email addresses as identities sent us calls, the e= mail address (with its<BR> >>>>>> domain) is the "userpart" of the identit= y, not the whole thing.  There<BR> >>>>>> are<BR> >>>>>> some interesting problems when you have URI to som= ething like the MS IM<BR> >>>>>> systems.  The first "@' (<a href=3D"br@bri= anrosen.net">br@brianrosen.net</a>@msn.com) gets escaped.  We've<BR> >>>>>> built systems that handle that.<BR> >>>>><BR> >>>>> I think this is a little short-sighted.  Certific= ates for vanity domains<BR> >>>>> are<BR> >>>>> certainly doable.  Besides P-Asserted-Identity is= not a MUST in phonebcp.<BR> >>>>> :^)<BR> >>>>><BR> >>>>>><BR> >>>>>> The Firewall/Session Border controls will have sev= eral criteria when<BR> >>>>>> PSAPs<BR> >>>>>> are overloaded, but AFAIK, no existing firewalls o= r SBCs do what you<BR> >>>>>> suggest<BR> >>>>>> other than the repeat offender rule, which is the = first line of defense.<BR> >>>>>> They do filter based on criteria that equate to IP= Address or Domain of<BR> >>>>>> the<BR> >>>>>> SP, which we can deal with.  We'll use what w= orks for the other users of<BR> >>>>>> these systems, we're unlikely to be able to have e= mergency services<BR> >>>>>> special<BR> >>>>>> firewalls or SBCs.<BR> >>>>><BR> >>>>> We're not talking about existing firewalls and SBCs. &= nbsp;We're talking about<BR> >>>>> ESInet Border Control Function.  If you don't def= ine what you want there,<BR> >>>>> you'll live with what you get.  My suggestions ar= e not beyond what's<BR> >>>>> possible, it's all software.<BR> >>>>><BR> >>>>> -Marc-<BR> >>>>><BR> >>>>><BR> >>>>><BR> >>>>><BR> >>>><BR> >>>><BR> >>><BR> >>><BR> >><BR> >><BR> ><BR> ><BR> <BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3340000415_20739401-- From mlinsner@cisco.com Mon Nov 2 09:33:29 2009 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46333A6859 for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nPVcyRW+7B1 for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 09:33:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 13DAC3A68F0 for <ecrit@ietf.org>; Mon, 2 Nov 2009 09:33:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEANem7kpAZnwN/2dsb2JhbACaKat2lm+COAaBfgSMBA X-IronPort-AV: E=Sophos;i="4.44,668,1249257600"; d="scan'208";a="66039792" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2009 17:33:47 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA2HXlZA028861; Mon, 2 Nov 2009 17:33:47 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 12:33:47 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 12:33:45 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 12:33:44 -0500 From: Marc Linsner <mlinsner@cisco.com> To: Brian Rosen <br@brianrosen.net>, <ecrit@ietf.org> Message-ID: <C7148228.1CF8D%mlinsner@cisco.com> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMew= In-Reply-To: <C7145C96.1EB23%br@brianrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Nov 2009 17:33:46.0154 (UTC) FILETIME=[A15E78A0:01CA5BE2] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 02 Nov 2009 17:33:29 -0000 On 11/2/09 8:53 AM, "Brian Rosen" <br@brianrosen.net> wrote: > Sorry, it=B9s an effective strategy. There aren=B9t many better ones when yo= u > can=B9t filter by attack signature or specific source address. When 99.99%= of > legitimate calls come from SPs you know, then filtering ones you don=B9t wh= en > attacks come that way works well. These are self-imposed limitations that conveniently allow the claim of 'effective strategy'. NENA is writing how congestion control works. The S= P the call utilizes should be low on the list of criteria used to 'rank' the veracity of the call. You are ignoring the real value of the information included with call. Instead you are focusing on carrying forward the warm and fuzzy from the legacy system. The PS community needs to utilize different tools to deal with calls from the Internet verses calls via the PSTN. -Marc- >=20 > The current 9-1-1 system in the U.S. has an even worse mechanism. It use= s > small trunk group sizes to limit how many calls an origination switch can= send > towards the PSAP. This is the main defense against a local surge of call= s. > Unfortunately, legitimate calls from callers not related to the surge who > happen to be on the same switch get caught. Compared to that, this is > strategy is great. >=20 > If it=B9s not effective, that is, when attacks come from sources you know, = which > certainly is feasible with many bot-net style attacks, then of course we > wouldn=B9t use it. Our primary strategy is spread calls out to every avail= able > call taker. 20,000 on duty call takers can process A LOT of bad calls. = Of > course, there are some attacks which would overwhelm that strategy. We f= all > back to others. >=20 > PSAPs like SPs. Please remember that. SPs are really common. No SP is > really, really uncommon. If that changes (by itself, not because we did > something stupid), then the strategy of filtering by source won=B9t be effe= ctive > any more. >=20 > But keep in mind that my major objection to =ADdirect is not the effect it = may > have on attack filtering, it=B9s the abuse potential. >=20 > Brian >=20 >=20 > On 11/2/09 10:13 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: >=20 >> I have no problem with indications that advise the PSAP call-taker: >>=20 >> 1. =B3This caller is using a SP we don=B9t know, please query the caller as= to >> their identity and location.=B2 >> 2. =B3There is no validation that the IP address of this caller exists at = the >> reported location, please query further about location.=B2 >>=20 >> I have a problem with: >>=20 >> 1. Queuing the call (as in prior to a human answering) or responding to= a >> call based on the SP (or lack thereof) the caller utilized. >>=20 >> I have no problem with: >>=20 >> 1. Requiring that calls to the ESInet meet a set of open global Industry >> standard protocol specifications. >>=20 >> This thread started when you described what happens in a PSAP call overl= oad >> situation. Determining the validity/urgency of an emergency call cannot >> happen based on the SP utilized, the failure scenario of the algorithm i= s >> disastrous. >>=20 >> -Marc- >>=20 >>=20 >>=20 >> On 10/31/09 8:43 AM, "Brian Rosen" <br@brianrosen.net> wrote: >>=20 >>> You are looking for trouble when there isn't any. >>>=20 >>> First of all, the latest example is that of a service provider, and not >>> entirely p2p. That's what we expect, and we don't expect the scenario = you >>> are trying to paint. >>>=20 >>> Then, ANY provider, regardless of size, should arrange to get whatever >>> credential we end up deploying. That means: >>> A) The devices on their network and/or their own network elements yield >>> phonebcp compliant emergency calls >>> B) They correctly forward such calls to the ESInet >>> C) They include the additional information we ask for, which includes >>> appropriate contact info >>>=20 >>> It doesn't mean much more than that. It does give us some basis for ma= king >>> choices, when we have to make choices, about calls. And please remembe= r, >>> we're nearly always taking calls wherever they come from: the scenario = we >>> are spilling all these bits in the last several messages is something w= e >>> hope roughly never happens, but we plan for it anyway. >>>=20 >>> I think PSAPs and their contractors will be trying to be proactive abou= t >>> looking for calls from unknown providers, but as always, the ones with = the >>> most calls are going to get more attention than the ones who have fewer >>> calls. That's all I meant. Actually, it occurs to me that they probab= ly >>> will go after providers who send calls that don't follow the rules befo= re >>> they go after well behaving, but unknown providers. >>>=20 >>> Brian >>>=20 >>>=20 >>> On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 10/30/09 6:41 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>=20 >>>>> I don't see that as a big problem. There aren't going to be thousand= s of >>>>> such successful service providers. It usually quickly settles Darwin= ian >>>>> style to one or two. When the PSAPs see a bunch of calls from some n= ew >>>>> source, they will call them up, and get them on the "we know you" lis= t. >>>>> No >>>>> big deal.=20 >>>>>=20 >>>>> You are still speculating about something that hasn't happened, and y= ou >>>>> can't find a good predecessor. The latest "thing" is the social >>>>> newtworks, >>>>> there were maybe 50 of them, and now there are maybe 5 or 6 that matt= er. >>>>=20 >>>> Exactly my point. In the scenario you've painted, the PSAP is going t= o >>>> evaluate the validity/urgency of the request for emergency assistance >>>> differently for their customers (as in the PSAP's customer) that chose= to >>>> use social network 7-50 verses 1-6. Please explain how my emergency i= s >>>> lesser of a priority because I buy services from social network provid= er >>>> #29. This is not the right tool for the PSAP to use for this purpose. >>>> Simply stating these are the only tools available is not good enough. >>>>=20 >>>> -Marc- >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On 10/30/09 6:12 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>>=20 >>>>>> It's not that I necessarily believe there will be a lack of SPs. I >>>>>> believe >>>>>> the mix of SPs and the products they offer will change dramatically = at a >>>>>> pace that PSAPs won't be able to keep up. This week Google, next we= ek >>>>>> Noggle, the next week Boogle, etc. If in fact the PSAP requires >>>>>> relationships with every SP that may send an emergency call their wa= y, it >>>>>> will only stifle innovation. >>>>>>=20 >>>>>> -Marc- >>>>>>=20 >>>>>>=20 >>>>>> On 10/30/09 4:55 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>>=20 >>>>>>> There is way too much speculation here. >>>>>>>=20 >>>>>>> You are speculating that there will be interesting services without >>>>>>> service >>>>>>> providers that have two way interactive media, where the identity o= f the >>>>>>> callers is a simple domain name, emergency calls from those devices= is >>>>>>> interesting, they can't provide a suitable callback without a >>>>>>> registration >>>>>>> from the ESRP, and such calls wont be the preferred abuse call sour= ce. >>>>>>>=20 >>>>>>> When we have that problem, if we ever have that problem, we'll solv= e it. >>>>>>>=20 >>>>>>> Right now, the simpler case of a direct call from an unknown source >>>>>>> because >>>>>>> you have a proxy server in your boat will get through just fine nea= rly >>>>>>> all >>>>>>> the time. When it doesn't, it will be because that path is being u= sed >>>>>>> by >>>>>>> someone attacking, and the lack of a service provider will probably= be >>>>>>> to >>>>>>> the disadvantage of the direct caller. I'm not going to lose sleep= over >>>>>>> that problem. I'd rather beef up the system so we don't have to dr= op >>>>>>> calls >>>>>>> when we're attacked. OTOH, I don't want to promote the proxy serve= r in >>>>>>> the >>>>>>> boat idea. If it happens occasionally, we'll cope. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>> On 10/30/09 4:14 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 10/30/09 2:29 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>>>>=20 >>>>>>>>> I'm the messenger here. PSAPs prefer service providers to be on = the >>>>>>>>> path >>>>>>>>> of >>>>>>>>> a call, and they have bad experiences when they aren't. >>>>>>>>>=20 >>>>>>>>> Given their experiences, I can't fault them. >>>>>>>>>=20 >>>>>>>>> The reason the text is in phonebcp is as you said it is: because >>>>>>>>> "normal" >>>>>>>>> is >>>>>>>>> likely to work. The fact that "normal" means SP path in 99.999% = of >>>>>>>>> cases >>>>>>>>> gets the PSAPs what they want. They don't care about why we did = it, >>>>>>>>> they >>>>>>>>> care they get the right result. >>>>>>>>=20 >>>>>>>> I, like others, believe the role/definition of the 'SP', as curren= tly >>>>>>>> defined by the PSAPs, will change significantly going forward. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I don't believe we are going to see vanity domains used on calls,= and >>>>>>>>> even >>>>>>>>> if they were in "From", they won't be the domain in >>>>>>>>> P-Asserted-Identity, >>>>>>>>> or >>>>>>>>> the SubjectAltName of the Identity signature. If some service th= at >>>>>>>>> used >>>>>>>>> email addresses as identities sent us calls, the email address (w= ith >>>>>>>>> its >>>>>>>>> domain) is the "userpart" of the identity, not the whole thing. = There >>>>>>>>> are >>>>>>>>> some interesting problems when you have URI to something like the= MS >>>>>>>>> IM >>>>>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. >>>>>>>>> We've >>>>>>>>> built systems that handle that. >>>>>>>>=20 >>>>>>>> I think this is a little short-sighted. Certificates for vanity >>>>>>>> domains >>>>>>>> are >>>>>>>> certainly doable. Besides P-Asserted-Identity is not a MUST in >>>>>>>> phonebcp. >>>>>>>> :^) >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The Firewall/Session Border controls will have several criteria w= hen >>>>>>>>> PSAPs >>>>>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what = you >>>>>>>>> suggest >>>>>>>>> other than the repeat offender rule, which is the first line of >>>>>>>>> defense. >>>>>>>>> They do filter based on criteria that equate to IP Address or Dom= ain >>>>>>>>> of >>>>>>>>> the >>>>>>>>> SP, which we can deal with. We'll use what works for the other u= sers >>>>>>>>> of >>>>>>>>> these systems, we're unlikely to be able to have emergency servic= es >>>>>>>>> special >>>>>>>>> firewalls or SBCs. >>>>>>>>=20 >>>>>>>> We're not talking about existing firewalls and SBCs. We're talkin= g >>>>>>>> about >>>>>>>> ESInet Border Control Function. If you don't define what you want >>>>>>>> there, >>>>>>>> you'll live with what you get. My suggestions are not beyond what= 's >>>>>>>> possible, it's all software. >>>>>>>>=20 >>>>>>>> -Marc- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 From br@brianrosen.net Mon Nov 2 09:56:32 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93BF3A682A for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 09:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4UCS0Fsljb3 for <ecrit@core3.amsl.com>; Mon, 2 Nov 2009 09:56:31 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5F8B83A6859 for <ecrit@ietf.org>; Mon, 2 Nov 2009 09:56:31 -0800 (PST) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1N5190-0008FG-AJ; Mon, 02 Nov 2009 11:56:43 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 12:56:44 -0400 From: Brian Rosen <br@brianrosen.net> To: Marc Linsner <mlinsner@cisco.com>, <ecrit@ietf.org> Message-ID: <C714878C.1EB86%br@brianrosen.net> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJg== In-Reply-To: <C7148228.1CF8D%mlinsner@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 02 Nov 2009 17:56:32 -0000 Nope, just dealing with reality. Reality is that calls come from service providers. They like it that way. If that changes, then strategies should change, but emergency calling ought not to be the driver for any such change. What "real value of the information included with the call" am I ignoring? I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, that is getting pretty hard to do) first. What else should we look for? Brian On 11/2/09 1:33 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >=20 > On 11/2/09 8:53 AM, "Brian Rosen" <br@brianrosen.net> wrote: >=20 >> Sorry, it=B9s an effective strategy. There aren=B9t many better ones when y= ou >> can=B9t filter by attack signature or specific source address. When 99.99= % of >> legitimate calls come from SPs you know, then filtering ones you don=B9t w= hen >> attacks come that way works well. >=20 > These are self-imposed limitations that conveniently allow the claim of > 'effective strategy'. NENA is writing how congestion control works. The= SP > the call utilizes should be low on the list of criteria used to 'rank' th= e > veracity of the call. You are ignoring the real value of the information > included with call. Instead you are focusing on carrying forward the war= m > and fuzzy from the legacy system. >=20 > The PS community needs to utilize different tools to deal with calls from > the Internet verses calls via the PSTN. >=20 > -Marc- >=20 >>=20 >> The current 9-1-1 system in the U.S. has an even worse mechanism. It us= es >> small trunk group sizes to limit how many calls an origination switch ca= n >> send >> towards the PSAP. This is the main defense against a local surge of cal= ls. >> Unfortunately, legitimate calls from callers not related to the surge wh= o >> happen to be on the same switch get caught. Compared to that, this is >> strategy is great. >>=20 >> If it=B9s not effective, that is, when attacks come from sources you know, >> which >> certainly is feasible with many bot-net style attacks, then of course we >> wouldn=B9t use it. Our primary strategy is spread calls out to every avai= lable >> call taker. 20,000 on duty call takers can process A LOT of bad calls. = Of >> course, there are some attacks which would overwhelm that strategy. We = fall >> back to others. >>=20 >> PSAPs like SPs. Please remember that. SPs are really common. No SP is >> really, really uncommon. If that changes (by itself, not because we did >> something stupid), then the strategy of filtering by source won=B9t be >> effective >> any more. >>=20 >> But keep in mind that my major objection to =ADdirect is not the effect it= may >> have on attack filtering, it=B9s the abuse potential. >>=20 >> Brian >>=20 >>=20 >> On 11/2/09 10:13 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>=20 >>> I have no problem with indications that advise the PSAP call-taker: >>>=20 >>> 1. =B3This caller is using a SP we don=B9t know, please query the caller a= s to >>> their identity and location.=B2 >>> 2. =B3There is no validation that the IP address of this caller exists at= the >>> reported location, please query further about location.=B2 >>>=20 >>> I have a problem with: >>>=20 >>> 1. Queuing the call (as in prior to a human answering) or responding t= o a >>> call based on the SP (or lack thereof) the caller utilized. >>>=20 >>> I have no problem with: >>>=20 >>> 1. Requiring that calls to the ESInet meet a set of open global Industr= y >>> standard protocol specifications. >>>=20 >>> This thread started when you described what happens in a PSAP call over= load >>> situation. Determining the validity/urgency of an emergency call canno= t >>> happen based on the SP utilized, the failure scenario of the algorithm = is >>> disastrous. >>>=20 >>> -Marc- >>>=20 >>>=20 >>>=20 >>> On 10/31/09 8:43 AM, "Brian Rosen" <br@brianrosen.net> wrote: >>>=20 >>>> You are looking for trouble when there isn't any. >>>>=20 >>>> First of all, the latest example is that of a service provider, and no= t >>>> entirely p2p. That's what we expect, and we don't expect the scenario= you >>>> are trying to paint. >>>>=20 >>>> Then, ANY provider, regardless of size, should arrange to get whatever >>>> credential we end up deploying. That means: >>>> A) The devices on their network and/or their own network elements yiel= d >>>> phonebcp compliant emergency calls >>>> B) They correctly forward such calls to the ESInet >>>> C) They include the additional information we ask for, which includes >>>> appropriate contact info >>>>=20 >>>> It doesn't mean much more than that. It does give us some basis for m= aking >>>> choices, when we have to make choices, about calls. And please rememb= er, >>>> we're nearly always taking calls wherever they come from: the scenario= we >>>> are spilling all these bits in the last several messages is something = we >>>> hope roughly never happens, but we plan for it anyway. >>>>=20 >>>> I think PSAPs and their contractors will be trying to be proactive abo= ut >>>> looking for calls from unknown providers, but as always, the ones with= the >>>> most calls are going to get more attention than the ones who have fewe= r >>>> calls. That's all I meant. Actually, it occurs to me that they proba= bly >>>> will go after providers who send calls that don't follow the rules bef= ore >>>> they go after well behaving, but unknown providers. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 10/30/09 6:41 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>=20 >>>>>> I don't see that as a big problem. There aren't going to be thousan= ds of >>>>>> such successful service providers. It usually quickly settles Darwi= nian >>>>>> style to one or two. When the PSAPs see a bunch of calls from some = new >>>>>> source, they will call them up, and get them on the "we know you" li= st. >>>>>> No >>>>>> big deal.=20 >>>>>>=20 >>>>>> You are still speculating about something that hasn't happened, and = you >>>>>> can't find a good predecessor. The latest "thing" is the social >>>>>> newtworks, >>>>>> there were maybe 50 of them, and now there are maybe 5 or 6 that mat= ter. >>>>>=20 >>>>> Exactly my point. In the scenario you've painted, the PSAP is going = to >>>>> evaluate the validity/urgency of the request for emergency assistance >>>>> differently for their customers (as in the PSAP's customer) that chos= e to >>>>> use social network 7-50 verses 1-6. Please explain how my emergency = is >>>>> lesser of a priority because I buy services from social network provi= der >>>>> #29. This is not the right tool for the PSAP to use for this purpose= . >>>>> Simply stating these are the only tools available is not good enough. >>>>>=20 >>>>> -Marc- >>>>>=20 >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> On 10/30/09 6:12 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>>>=20 >>>>>>> It's not that I necessarily believe there will be a lack of SPs. I >>>>>>> believe >>>>>>> the mix of SPs and the products they offer will change dramatically= at a >>>>>>> pace that PSAPs won't be able to keep up. This week Google, next w= eek >>>>>>> Noggle, the next week Boogle, etc. If in fact the PSAP requires >>>>>>> relationships with every SP that may send an emergency call their w= ay, >>>>>>> it >>>>>>> will only stifle innovation. >>>>>>>=20 >>>>>>> -Marc- >>>>>>>=20 >>>>>>>=20 >>>>>>> On 10/30/09 4:55 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>>>=20 >>>>>>>> There is way too much speculation here. >>>>>>>>=20 >>>>>>>> You are speculating that there will be interesting services withou= t >>>>>>>> service >>>>>>>> providers that have two way interactive media, where the identity = of >>>>>>>> the >>>>>>>> callers is a simple domain name, emergency calls from those device= s is >>>>>>>> interesting, they can't provide a suitable callback without a >>>>>>>> registration >>>>>>>> from the ESRP, and such calls wont be the preferred abuse call sou= rce. >>>>>>>>=20 >>>>>>>> When we have that problem, if we ever have that problem, we'll sol= ve >>>>>>>> it. >>>>>>>>=20 >>>>>>>> Right now, the simpler case of a direct call from an unknown sourc= e >>>>>>>> because >>>>>>>> you have a proxy server in your boat will get through just fine ne= arly >>>>>>>> all >>>>>>>> the time. When it doesn't, it will be because that path is being = used >>>>>>>> by >>>>>>>> someone attacking, and the lack of a service provider will probabl= y be >>>>>>>> to >>>>>>>> the disadvantage of the direct caller. I'm not going to lose slee= p >>>>>>>> over >>>>>>>> that problem. I'd rather beef up the system so we don't have to d= rop >>>>>>>> calls >>>>>>>> when we're attacked. OTOH, I don't want to promote the proxy serv= er in >>>>>>>> the >>>>>>>> boat idea. If it happens occasionally, we'll cope. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 10/30/09 4:14 PM, "Marc Linsner" <mlinsner@cisco.com> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 10/30/09 2:29 PM, "Brian Rosen" <br@brianrosen.net> wrote: >>>>>>>>>=20 >>>>>>>>>> I'm the messenger here. PSAPs prefer service providers to be on= the >>>>>>>>>> path >>>>>>>>>> of >>>>>>>>>> a call, and they have bad experiences when they aren't. >>>>>>>>>>=20 >>>>>>>>>> Given their experiences, I can't fault them. >>>>>>>>>>=20 >>>>>>>>>> The reason the text is in phonebcp is as you said it is: because >>>>>>>>>> "normal" >>>>>>>>>> is >>>>>>>>>> likely to work. The fact that "normal" means SP path in 99.999%= of >>>>>>>>>> cases >>>>>>>>>> gets the PSAPs what they want. They don't care about why we did= it, >>>>>>>>>> they >>>>>>>>>> care they get the right result. >>>>>>>>>=20 >>>>>>>>> I, like others, believe the role/definition of the 'SP', as curre= ntly >>>>>>>>> defined by the PSAPs, will change significantly going forward. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I don't believe we are going to see vanity domains used on calls= , and >>>>>>>>>> even >>>>>>>>>> if they were in "From", they won't be the domain in >>>>>>>>>> P-Asserted-Identity, >>>>>>>>>> or >>>>>>>>>> the SubjectAltName of the Identity signature. If some service t= hat >>>>>>>>>> used >>>>>>>>>> email addresses as identities sent us calls, the email address (= with >>>>>>>>>> its >>>>>>>>>> domain) is the "userpart" of the identity, not the whole thing. >>>>>>>>>> There >>>>>>>>>> are >>>>>>>>>> some interesting problems when you have URI to something like th= e MS >>>>>>>>>> IM >>>>>>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped= . >>>>>>>>>> We've >>>>>>>>>> built systems that handle that. >>>>>>>>>=20 >>>>>>>>> I think this is a little short-sighted. Certificates for vanity >>>>>>>>> domains >>>>>>>>> are >>>>>>>>> certainly doable. Besides P-Asserted-Identity is not a MUST in >>>>>>>>> phonebcp. >>>>>>>>> :^) >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The Firewall/Session Border controls will have several criteria = when >>>>>>>>>> PSAPs >>>>>>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what= you >>>>>>>>>> suggest >>>>>>>>>> other than the repeat offender rule, which is the first line of >>>>>>>>>> defense. >>>>>>>>>> They do filter based on criteria that equate to IP Address or Do= main >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> SP, which we can deal with. We'll use what works for the other = users >>>>>>>>>> of >>>>>>>>>> these systems, we're unlikely to be able to have emergency servi= ces >>>>>>>>>> special >>>>>>>>>> firewalls or SBCs. >>>>>>>>>=20 >>>>>>>>> We're not talking about existing firewalls and SBCs. We're talki= ng >>>>>>>>> about >>>>>>>>> ESInet Border Control Function. If you don't define what you wan= t >>>>>>>>> there, >>>>>>>>> you'll live with what you get. My suggestions are not beyond wha= t's >>>>>>>>> possible, it's all software. >>>>>>>>>=20 >>>>>>>>> -Marc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 >=20 From mlinsner@cisco.com Tue Nov 3 06:18:29 2009 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7214D3A6A16 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 06:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ecKLLVeczoF for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 06:18:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B00723A6968 for <ecrit@ietf.org>; Tue, 3 Nov 2009 06:18:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKPK70qrRN+J/2dsb2JhbADHBJd9gjmCBAQ X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="423738570" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2009 14:18:49 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nA3EInpI002630; Tue, 3 Nov 2009 14:18:49 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:18:48 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:18:48 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Nov 2009 09:18:46 -0500 From: Marc Linsner <mlinsner@cisco.com> To: Brian Rosen <br@brianrosen.net>, <ecrit@ietf.org> Message-ID: <C715A5F6.1D049%mlinsner@cisco.com> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXT In-Reply-To: <C714878C.1EB86%br@brianrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 14:18:48.0535 (UTC) FILETIME=[8F753670:01CA5C90] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 Nov 2009 14:18:29 -0000 On 11/2/09 11:56 AM, "Brian Rosen" <br@brianrosen.net> wrote: > Nope, just dealing with reality. > > Reality is that calls come from service providers. They like it that way. I'll ask again, how does a call coming from a particular service provider relate to the nature/veracity of the emergency? > > If that changes, then strategies should change, but emergency calling ought > not to be the driver for any such change. I have doubts that PS could alter the VoIP marketplace. > > What "real value of the information included with the call" am I ignoring? > I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, > that is getting pretty hard to do) first. What else should we look for? 1) Location: Have I had other calls within x meters of this location in the last 5 minutes? 20 minutes? 1 hour? 24 hours? 2) Caller Identity (From; Contact): Have I had other calls with the same identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours? 3) Network Address: Have I received other calls from this IP address in the last 5 minutes? 20 minutes? 1 hour? 24 hours? -Marc- From br@brianrosen.net Tue Nov 3 06:36:55 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1403A68A9 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 06:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlj7HO5e6TzV for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 06:36:54 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7676C3A67B1 for <ecrit@ietf.org>; Tue, 3 Nov 2009 06:36:54 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1N5KVQ-00013a-Ag; Tue, 03 Nov 2009 08:37:08 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Nov 2009 09:37:10 -0400 From: Brian Rosen <br@brianrosen.net> To: Marc Linsner <mlinsner@cisco.com>, <ecrit@ietf.org> Message-ID: <C715AA46.1EC73%br@brianrosen.net> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXTAACkgmg= In-Reply-To: <C715A5F6.1D049%mlinsner@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 Nov 2009 14:36:55 -0000 inline On 11/3/09 10:18 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: > > > On 11/2/09 11:56 AM, "Brian Rosen" <br@brianrosen.net> wrote: > >> Nope, just dealing with reality. >> >> Reality is that calls come from service providers. They like it that way. > > I'll ask again, how does a call coming from a particular service provider > relate to the nature/veracity of the emergency? The quality of the information, and the ability to get additional assistance, if needed, depends on the SP, if there is any. Most SPs have dedicated emergency call teams that will quickly assist a PSAP if there is a problem. They have information which may be valuable to the PSAP. PSAPs appreciate this. They depend on it. They really work over SPs who don't do that. > >> >> If that changes, then strategies should change, but emergency calling ought >> not to be the driver for any such change. > > I have doubts that PS could alter the VoIP marketplace. I assume "PS" is "SP". SPs ARE the VoIP marketplace. There is no VoIP marketplace without SPs presently. There is no reason to think that will change > >> >> What "real value of the information included with the call" am I ignoring? >> I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, >> that is getting pretty hard to do) first. What else should we look for? > > > 1) Location: Have I had other calls within x meters of this location in the > last 5 minutes? 20 minutes? 1 hour? 24 hours? The primary problem is abuse. What should I do if I had a legitimate call from the same location, but a different address/SP/...? What should I do if I had an abusive call from the same location? Our statistics on that are probably poor, but my personal opinion is that location is not a good indicator of abuse. I suppose it depends on how reliable location will be with abusive calls. If it turns out to be very reliable, that might be helpful. I suspect the abuser will manage to make location unreliable. I guess we will see. We certainly have the ability to use location as an input to the routing decisions, so no problem if it actually works. Of course, in the current systems, you don't get location with a "simless" call. I agree that we shouldn't assume that will be the case going forward. I would not use this for a DDoS attack. That would kill a call from a non-compromised device in a residence/office with one that was compromised. > > 2) Caller Identity (From; Contact): Have I had other calls with the same > identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours? Yes, this is like address. We'll clearly start with that. If it works, that's our primary defense. Often effective on abuse, usually not effective enough on a DDoS: you shut off the sources you know are bad, but too many new ones pop up to make that effective enough. It's also usually spoofed. > > 3) Network Address: Have I received other calls from this IP address in the > last 5 minutes? 20 minutes? 1 hour? 24 hours? As above. The "filter based on source SP" is a secondary line of defense. An attack signature is an even better line of primary attack, if there is one. Normal abuse would not have a signature. A DDoS attack often does. > > -Marc- > > > From Martin.Dawson@andrew.com Tue Nov 3 07:23:08 2009 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3AE28C0E0 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlRhXqNekzz3 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 07:23:06 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id BCE963A659B for <ecrit@ietf.org>; Tue, 3 Nov 2009 07:23:05 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:35252 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4938490AbZKCPXV convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org>); Tue, 3 Nov 2009 09:23:21 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 3 Nov 2009 09:23:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 3 Nov 2009 23:23:16 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: Brian Rosen <br@brianrosen.net>, Marc Linsner <mlinsner@cisco.com>, "ecrit@ietf.org" <ecrit@ietf.org> Date: Tue, 3 Nov 2009 23:23:14 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXTAACkgmgAANqioA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2521AB@SISPE7MB1.commscope.com> References: <C715A5F6.1D049%mlinsner@cisco.com> <C715AA46.1EC73%br@brianrosen.net> In-Reply-To: <C715AA46.1EC73%br@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 Nov 2009 15:23:08 -0000 Hi Brian, Please *define* what you mean when you keep saying SP in this thread. There are two VoIP providers I use regularly; MyNetFone which is an Oz provider and Skype. There are others as well that I use as circumstance suggests. So... come to the US and I'll only be entitled to second class emergency service calling? Skype is the one I use the most, though I have a number of subscriptions. The most recent one is "martin-psp" which I exclusively log onto from my PSP and use, again, in circumstances where it's most convenient. Now I don't *need* to provide any useful information (from an ESP perspective) to have these accounts. There's no identity information of the type you refer to. The only reason Skype want more rigorous identity information is when they want to charge me money (e.g. for Skype out/in) - even then it might just be a PayPal username. The only reason any commercial VSP wants this sort of information is when they want to charge money. So... you appear to be limiting "premium" emergency service access to people with credit cards. And - in any case - you haven't addressed your invented problem. People can still call the ESRP without going through one of these "blessed" VSP operators. So what have you achieved? There's no empirical, or even anecdotal, evidence for your claims as far as I know. Please cite your sources. We've put the mechanisms in place to provide reliable location identity with calls (via the ISPs of course). Where is the study that shows that people are going to go running off to free airport WiFi access points (despite the fact that their location will be known) and start making nuisance calls in high volume? By the same token, where is the evidence that this would be mitigated by a patchwork of occasional and often foreign VSP subscriptions? Regards, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 4 November 2009 12:37 AM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered inline On 11/3/09 10:18 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: > > > On 11/2/09 11:56 AM, "Brian Rosen" <br@brianrosen.net> wrote: > >> Nope, just dealing with reality. >> >> Reality is that calls come from service providers. They like it that way. > > I'll ask again, how does a call coming from a particular service provider > relate to the nature/veracity of the emergency? The quality of the information, and the ability to get additional assistance, if needed, depends on the SP, if there is any. Most SPs have dedicated emergency call teams that will quickly assist a PSAP if there is a problem. They have information which may be valuable to the PSAP. PSAPs appreciate this. They depend on it. They really work over SPs who don't do that. > >> >> If that changes, then strategies should change, but emergency calling ought >> not to be the driver for any such change. > > I have doubts that PS could alter the VoIP marketplace. I assume "PS" is "SP". SPs ARE the VoIP marketplace. There is no VoIP marketplace without SPs presently. There is no reason to think that will change > >> >> What "real value of the information included with the call" am I ignoring? >> I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, >> that is getting pretty hard to do) first. What else should we look for? > > > 1) Location: Have I had other calls within x meters of this location in the > last 5 minutes? 20 minutes? 1 hour? 24 hours? The primary problem is abuse. What should I do if I had a legitimate call from the same location, but a different address/SP/...? What should I do if I had an abusive call from the same location? Our statistics on that are probably poor, but my personal opinion is that location is not a good indicator of abuse. I suppose it depends on how reliable location will be with abusive calls. If it turns out to be very reliable, that might be helpful. I suspect the abuser will manage to make location unreliable. I guess we will see. We certainly have the ability to use location as an input to the routing decisions, so no problem if it actually works. Of course, in the current systems, you don't get location with a "simless" call. I agree that we shouldn't assume that will be the case going forward. I would not use this for a DDoS attack. That would kill a call from a non-compromised device in a residence/office with one that was compromised. > > 2) Caller Identity (From; Contact): Have I had other calls with the same > identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours? Yes, this is like address. We'll clearly start with that. If it works, that's our primary defense. Often effective on abuse, usually not effective enough on a DDoS: you shut off the sources you know are bad, but too many new ones pop up to make that effective enough. It's also usually spoofed. > > 3) Network Address: Have I received other calls from this IP address in the > last 5 minutes? 20 minutes? 1 hour? 24 hours? As above. The "filter based on source SP" is a secondary line of defense. An attack signature is an even better line of primary attack, if there is one. Normal abuse would not have a signature. A DDoS attack often does. > > -Marc- > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Nov 3 08:02:12 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A9A3A67D8 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 08:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SowCTcx+Ee-i for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 08:02:11 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1D1643A657C for <ecrit@ietf.org>; Tue, 3 Nov 2009 08:02:11 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1N5Lpv-00063l-3K; Tue, 03 Nov 2009 10:02:23 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Nov 2009 11:02:26 -0400 From: Brian Rosen <br@brianrosen.net> To: "Dawson, Martin" <Martin.Dawson@andrew.com>, Marc Linsner <mlinsner@cisco.com>, "ecrit@ietf.org" <ecrit@ietf.org> Message-ID: <C715BE42.1ECAD%br@brianrosen.net> Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXTAACkgmgAANqioAACH7Zs In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2521AB@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 Nov 2009 16:02:12 -0000 I guess I've pretty much said my piece here Martin. We'll accept calls from Skype, regardless of the fact that the identity may be pretty weak. These days, law enforcement can do pretty well with an IP address and email address, but it's not foolproof. It's my opinion, after talking to them, that PSAPs STRONGLY prefer that a service provider be in the path, and by service provider they mean calling network and not ISP. For the purposes of this discussion, they don't want calls that have no SP. I hesitate to call them VSPs, because "Voice" isn't right, but that's the SP we mean. I agree that we'll be looking for the ISP to be able to help us with abuse if we need them to. We do want signed location, to provide some integrity protection, and we definitely need the identity of the ISP that provided location in the PIDF. That's an AND, and not an OR though. It's hard to call location a reliable identity. Too easy to discard. We DO take calls without location. We don't like those either. In normal circumstances, we take calls from anywhere, regardless of whether they follow rules. Frankly, I think if the call has an INVITE that looks vaguely reasonable, with any form of sos urn, we'll probably take it until it proves to be abusive or part of an attack. So, yes, we'll take a call not from an SP, but we don't want to see such calls. We certainly don't want to encourage them. But I think I am repeating myself, so unless there is something new, I'll take a break from this thread. Brian On 11/3/09 11:23 AM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Hi Brian, > > Please *define* what you mean when you keep saying SP in this thread. > > There are two VoIP providers I use regularly; MyNetFone which is an Oz > provider and Skype. There are others as well that I use as circumstance > suggests. So... come to the US and I'll only be entitled to second class > emergency service calling? > > Skype is the one I use the most, though I have a number of subscriptions. The > most recent one is "martin-psp" which I exclusively log onto from my PSP and > use, again, in circumstances where it's most convenient. > > Now I don't *need* to provide any useful information (from an ESP perspective) > to have these accounts. There's no identity information of the type you refer > to. > > The only reason Skype want more rigorous identity information is when they > want to charge me money (e.g. for Skype out/in) - even then it might just be a > PayPal username. The only reason any commercial VSP wants this sort of > information is when they want to charge money. So... you appear to be limiting > "premium" emergency service access to people with credit cards. > > And - in any case - you haven't addressed your invented problem. People can > still call the ESRP without going through one of these "blessed" VSP > operators. So what have you achieved? > > There's no empirical, or even anecdotal, evidence for your claims as far as I > know. Please cite your sources. We've put the mechanisms in place to provide > reliable location identity with calls (via the ISPs of course). Where is the > study that shows that people are going to go running off to free airport WiFi > access points (despite the fact that their location will be known) and start > making nuisance calls in high volume? By the same token, where is the evidence > that this would be mitigated by a patchwork of occasional and often foreign > VSP subscriptions? > > Regards, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 4 November 2009 12:37 AM > To: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > inline > > > On 11/3/09 10:18 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: > >> >> >> On 11/2/09 11:56 AM, "Brian Rosen" <br@brianrosen.net> wrote: >> >>> Nope, just dealing with reality. >>> >>> Reality is that calls come from service providers. They like it that way. >> >> I'll ask again, how does a call coming from a particular service provider >> relate to the nature/veracity of the emergency? > The quality of the information, and the ability to get additional > assistance, if needed, depends on the SP, if there is any. Most SPs have > dedicated emergency call teams that will quickly assist a PSAP if there is a > problem. They have information which may be valuable to the PSAP. PSAPs > appreciate this. They depend on it. They really work over SPs who don't do > that. > > >> >>> >>> If that changes, then strategies should change, but emergency calling ought >>> not to be the driver for any such change. >> >> I have doubts that PS could alter the VoIP marketplace. > I assume "PS" is "SP". SPs ARE the VoIP marketplace. There is no VoIP > marketplace without SPs presently. There is no reason to think that will > change > >> >>> >>> What "real value of the information included with the call" am I ignoring? >>> I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, >>> that is getting pretty hard to do) first. What else should we look for? >> >> >> 1) Location: Have I had other calls within x meters of this location in the >> last 5 minutes? 20 minutes? 1 hour? 24 hours? > The primary problem is abuse. What should I do if I had a legitimate call > from the same location, but a different address/SP/...? What should I do if > I had an abusive call from the same location? Our statistics on that are > probably poor, but my personal opinion is that location is not a good > indicator of abuse. I suppose it depends on how reliable location will be > with abusive calls. If it turns out to be very reliable, that might be > helpful. I suspect the abuser will manage to make location unreliable. I > guess we will see. We certainly have the ability to use location as an > input to the routing decisions, so no problem if it actually works. > > Of course, in the current systems, you don't get location with a "simless" > call. I agree that we shouldn't assume that will be the case going forward. > > I would not use this for a DDoS attack. That would kill a call from a > non-compromised device in a residence/office with one that was compromised. > >> >> 2) Caller Identity (From; Contact): Have I had other calls with the same >> identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours? > Yes, this is like address. We'll clearly start with that. If it works, > that's our primary defense. Often effective on abuse, usually not > effective enough on a DDoS: you shut off the sources you know are bad, but > too many new ones pop up to make that effective enough. It's also usually > spoofed. > >> >> 3) Network Address: Have I received other calls from this IP address in the >> last 5 minutes? 20 minutes? 1 hour? 24 hours? > As above. > > The "filter based on source SP" is a secondary line of defense. An attack > signature is an even better line of primary attack, if there is one. Normal > abuse would not have a signature. A DDoS attack often does. >> >> -Marc- >> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hgs@cs.columbia.edu Tue Nov 3 19:45:23 2009 Return-Path: <hgs@cs.columbia.edu> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C563A6945 for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 19:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQPdqoDMg1DM for <ecrit@core3.amsl.com>; Tue, 3 Nov 2009 19:45:22 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 8EBB83A693C for <ecrit@ietf.org>; Tue, 3 Nov 2009 19:45:22 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA43jeTt015091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 22:45:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne <hgs@cs.columbia.edu> In-Reply-To: <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com> Date: Tue, 3 Nov 2009 22:45:39 -0500 Content-Transfer-Encoding: 7bit Message-Id: <EA9D304C-78BA-492E-844F-1C9A4F299E93@cs.columbia.edu> References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com> To: Ted Hardie <ted.ietf@gmail.com> X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org Subject: Re: [Ecrit] Service URN IANA Policy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 Nov 2009 03:45:23 -0000 Picking up an earlier thread... Ted, are you looking for general guidance for all top-level service URNs, present and future, or as a meta-requirement, i.e., each top-level service should provide guidance on whether more "liberal" or "conservative" policies are appropriate? For example, for emergency services, "conservative" seems appropriate, while for our point-of- interest services (hotels, restaurants, banks, ...), a more liberal policy, with a lower threshold, seems to be more in keeping with the necessarily imprecise definitions of such services. Henning On Sep 30, 2009, at 12:44 PM, Ted Hardie wrote: > Howdy, > > I don't have any problems with this allocation policy, but I see two > things in the draft that should probably change. The appointment > should be by the IESG, not the RAI area director or directors; this is > the traditional appointment mechanism and it allows other ADs to > contribute, even if RAI leads. For services that are not SOS-related, > other areas may have significant input. Second, some text in the > document that describes the conditions under which new entries are > approved or denied is very useful, as it guides the later incumbents > in the role. In the URI space, for example, there are two strains of > thought about minting new schemes: one is that it should be > restricted to cases which absolutely cannot be met by an existing > scheme; the second is that the schemes will be minted anyway and that > registration largely serves to avoid interoperability problems. > Having the working group provide general guidance on this point is > very useful, in my opinion. > From MILANPA@nortel.com Thu Nov 5 06:28:03 2009 Return-Path: <MILANPA@nortel.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52628C1CF for <ecrit@core3.amsl.com>; Thu, 5 Nov 2009 06:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n3U0LYqLEtC for <ecrit@core3.amsl.com>; Thu, 5 Nov 2009 06:28:01 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6C4B428C1D2 for <ecrit@ietf.org>; Thu, 5 Nov 2009 06:28:01 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nA5ESI012128 for <ecrit@ietf.org>; Thu, 5 Nov 2009 14:28:18 GMT Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nA5ES2W23585 for <ecrit@ietf.org>; Thu, 5 Nov 2009 14:28:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5E24.2E4DF127" Date: Thu, 5 Nov 2009 14:27:59 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900B314C2D@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: marking of PSAP call backs Thread-Index: AcpeJCyv6L0It9iDThiC58Grf/F+Sw== From: "Milan Patel" <milanpa@nortel.com> To: "ecrit" <ecrit@ietf.org> Subject: [Ecrit] marking of PSAP call backs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 Nov 2009 14:28:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5E24.2E4DF127 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 For next week's 3GPP CT1 meeting I have submitted a document based on the Internet-Draft for marking PSAP call backs. The intention is to get some feedback from 3GPP on which of the solution approaches, if any, are a good way to progress work in for this feature. Also, the paper intends to get a decision on whether 3GPP see that it is possible to fulfil the requirement of marking PSAP call backs within the 3GPP release 9 timeframe.=20 The Internet-Draft is: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 The 3GPP paper is available at: http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1/TSGC1_62_Beijing/docs /C1-095075.zip =20 I will update you on the discussion that occurs next week. In the mean time if you have any immediate feedback or comments on the paper or the Internet-Draft, I would appreciate them.=20 Best regards, Milan =20 Milan Patel=20 Carrier Networks Core Standards=20 Nortel=20 milanpa@nortel.com=20 Telephone +44 162 843 2381 / ESN 560 2381=20 Mobile +44 774 053 9261 / ESN 748 9261=20 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV =20 ------_=_NextPart_001_01CA5E24.2E4DF127 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:10.0pt; font-family:Arial;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:#606420; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {margin:0cm; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3D"#606420"> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>Hi Folks,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>For next week's 3GPP CT1 meeting I have submitted a document = based on the Internet-Draft for marking PSAP call backs. The intention is to get = some feedback from 3GPP on which of the solution approaches, if any, are a = good way to progress work in for this feature. Also, the paper intends to get a = decision on whether 3GPP see that it is possible to fulfil the requirement of = marking PSAP call backs within the 3GPP release 9 timeframe. = <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>The Internet-Draft is: </span><span lang=3DEN-GB><a href=3D"http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-= 01">http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01</= a><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>The 3GPP paper is available at:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'><a href=3D"http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1/TSGC1_62_Beiji= ng/docs/C1-095075.zip">http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1= /TSGC1_62_Beijing/docs/C1-095075.zip</a><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>I will update you on the discussion that occurs next week. In = the mean time if you have any immediate feedback or comments on the paper or the = Internet-Draft, I would appreciate them. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'>Best regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font = size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt'>Milan</span></font></st1:place></st1:City><spa= n lang=3DEN-GB><o:p></o:p></span></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'>Milan Patel</span></font> <br> <font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family: Arial'>Carrier Networks Core Standards</span></font> <br> <font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family: Arial'>Nortel</span></font> <br> <font size=3D2 face=3DArial><span lang=3DES = style=3D'font-size:10.0pt;font-family:Arial'>milanpa@nortel.com</span></f= ont> <br> <font size=3D2 face=3DArial><span lang=3DES = style=3D'font-size:10.0pt;font-family:Arial'>Telephone +44 162 843 2381 / ESN 560 2381</span></font> <br> <st1:place w:st=3D"on"><font size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size: 10.0pt;font-family:Arial'>Mobile</span></font></st1:place><font = size=3D2 face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family:Arial'> +44 774 053 9261 / ESN 748 9261</span></font><span lang=3DEN-GB> = </span><o:p></o:p></p> <p><b><i><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold;font-style:italic'>For = the Companies listed below, The Institute of Chartered Accountants in = England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to = act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act = 1986.</span></font></i></b><o:p></o:p></p> <p><b><i><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold;font-style:italic'>The = affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as = agents of the Companies only and without personal = liability.</span></font></i></b><o:p></o:p></p> <p><b><i><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold;font-style:italic'>The = Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel = Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel = Networks</span></font></i></b><b><i><span style=3D'font-weight:bold;font-style:italic'> </span></i></b><b><i><font = size=3D2 color=3Dblack face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family: Arial;color:black;font-weight:bold;font-style:italic'>(Austria)</span></f= ont></i></b><b><i><span lang=3DEN-GB style=3D'font-weight:bold;font-style:italic'> = </span></i></b><b><i><font size=3D2 color=3Dblack face=3DArial><span lang=3DEN-GB = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold;font-style:italic'>GmbH; = Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks = Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks = Romania SRL; Nortel Networks AB; Nortel Networks International Finance & = Holding BV</span></font></i></b><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = lang=3DEN-GB><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01CA5E24.2E4DF127-- From Martin.Dawson@andrew.com Thu Nov 5 16:32:06 2009 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D0B3A67CF for <ecrit@core3.amsl.com>; Thu, 5 Nov 2009 16:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyaRK+WyYE7g for <ecrit@core3.amsl.com>; Thu, 5 Nov 2009 16:32:05 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id CD2E63A67E2 for <ecrit@ietf.org>; Thu, 5 Nov 2009 16:32:04 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:31507 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4985336AbZKFAc1 convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org>); Thu, 5 Nov 2009 18:32:27 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 5 Nov 2009 18:32:27 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 6 Nov 2009 08:32:23 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: Brian Rosen <br@brianrosen.net>, Marc Linsner <mlinsner@cisco.com>, "ecrit@ietf.org" <ecrit@ietf.org> Date: Fri, 6 Nov 2009 08:32:22 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXTAACkgmgAANqioAACH7ZsAHZBSGA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4A38@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F2521AB@SISPE7MB1.commscope.com> <C715BE42.1ECAD%br@brianrosen.net> In-Reply-To: <C715BE42.1ECAD%br@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 Nov 2009 00:32:06 -0000 Thanks Brian, I'm glad to draw a veil over your comments. Obviously I've found them less than convincing - and in some respects alarming. The draft, I submit, stands worthy of being progressed in its own right. I'll also add that a key feature it adds in conjunction with ECRIT - the temporary registration - is of potential utility regardless of the call being direct from the UA or via a VoIP proxy (be it a VSP or, more sensibly, something like an enterprise IP PABX). Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 4 November 2009 2:02 AM To: Dawson, Martin; Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered I guess I've pretty much said my piece here Martin. We'll accept calls from Skype, regardless of the fact that the identity may be pretty weak. These days, law enforcement can do pretty well with an IP address and email address, but it's not foolproof. It's my opinion, after talking to them, that PSAPs STRONGLY prefer that a service provider be in the path, and by service provider they mean calling network and not ISP. For the purposes of this discussion, they don't want calls that have no SP. I hesitate to call them VSPs, because "Voice" isn't right, but that's the SP we mean. I agree that we'll be looking for the ISP to be able to help us with abuse if we need them to. We do want signed location, to provide some integrity protection, and we definitely need the identity of the ISP that provided location in the PIDF. That's an AND, and not an OR though. It's hard to call location a reliable identity. Too easy to discard. We DO take calls without location. We don't like those either. In normal circumstances, we take calls from anywhere, regardless of whether they follow rules. Frankly, I think if the call has an INVITE that looks vaguely reasonable, with any form of sos urn, we'll probably take it until it proves to be abusive or part of an attack. So, yes, we'll take a call not from an SP, but we don't want to see such calls. We certainly don't want to encourage them. But I think I am repeating myself, so unless there is something new, I'll take a break from this thread. Brian On 11/3/09 11:23 AM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Hi Brian, > > Please *define* what you mean when you keep saying SP in this thread. > > There are two VoIP providers I use regularly; MyNetFone which is an Oz > provider and Skype. There are others as well that I use as circumstance > suggests. So... come to the US and I'll only be entitled to second class > emergency service calling? > > Skype is the one I use the most, though I have a number of subscriptions. The > most recent one is "martin-psp" which I exclusively log onto from my PSP and > use, again, in circumstances where it's most convenient. > > Now I don't *need* to provide any useful information (from an ESP perspective) > to have these accounts. There's no identity information of the type you refer > to. > > The only reason Skype want more rigorous identity information is when they > want to charge me money (e.g. for Skype out/in) - even then it might just be a > PayPal username. The only reason any commercial VSP wants this sort of > information is when they want to charge money. So... you appear to be limiting > "premium" emergency service access to people with credit cards. > > And - in any case - you haven't addressed your invented problem. People can > still call the ESRP without going through one of these "blessed" VSP > operators. So what have you achieved? > > There's no empirical, or even anecdotal, evidence for your claims as far as I > know. Please cite your sources. We've put the mechanisms in place to provide > reliable location identity with calls (via the ISPs of course). Where is the > study that shows that people are going to go running off to free airport WiFi > access points (despite the fact that their location will be known) and start > making nuisance calls in high volume? By the same token, where is the evidence > that this would be mitigated by a patchwork of occasional and often foreign > VSP subscriptions? > > Regards, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 4 November 2009 12:37 AM > To: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > inline > > > On 11/3/09 10:18 AM, "Marc Linsner" <mlinsner@cisco.com> wrote: > >> >> >> On 11/2/09 11:56 AM, "Brian Rosen" <br@brianrosen.net> wrote: >> >>> Nope, just dealing with reality. >>> >>> Reality is that calls come from service providers. They like it that way. >> >> I'll ask again, how does a call coming from a particular service provider >> relate to the nature/veracity of the emergency? > The quality of the information, and the ability to get additional > assistance, if needed, depends on the SP, if there is any. Most SPs have > dedicated emergency call teams that will quickly assist a PSAP if there is a > problem. They have information which may be valuable to the PSAP. PSAPs > appreciate this. They depend on it. They really work over SPs who don't do > that. > > >> >>> >>> If that changes, then strategies should change, but emergency calling ought >>> not to be the driver for any such change. >> >> I have doubts that PS could alter the VoIP marketplace. > I assume "PS" is "SP". SPs ARE the VoIP marketplace. There is no VoIP > marketplace without SPs presently. There is no reason to think that will > change > >> >>> >>> What "real value of the information included with the call" am I ignoring? >>> I said we'll deal with addresses (albeit, with SBCs and all manner of NATs, >>> that is getting pretty hard to do) first. What else should we look for? >> >> >> 1) Location: Have I had other calls within x meters of this location in the >> last 5 minutes? 20 minutes? 1 hour? 24 hours? > The primary problem is abuse. What should I do if I had a legitimate call > from the same location, but a different address/SP/...? What should I do if > I had an abusive call from the same location? Our statistics on that are > probably poor, but my personal opinion is that location is not a good > indicator of abuse. I suppose it depends on how reliable location will be > with abusive calls. If it turns out to be very reliable, that might be > helpful. I suspect the abuser will manage to make location unreliable. I > guess we will see. We certainly have the ability to use location as an > input to the routing decisions, so no problem if it actually works. > > Of course, in the current systems, you don't get location with a "simless" > call. I agree that we shouldn't assume that will be the case going forward. > > I would not use this for a DDoS attack. That would kill a call from a > non-compromised device in a residence/office with one that was compromised. > >> >> 2) Caller Identity (From; Contact): Have I had other calls with the same >> identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours? > Yes, this is like address. We'll clearly start with that. If it works, > that's our primary defense. Often effective on abuse, usually not > effective enough on a DDoS: you shut off the sources you know are bad, but > too many new ones pop up to make that effective enough. It's also usually > spoofed. > >> >> 3) Network Address: Have I received other calls from this IP address in the >> last 5 minutes? 20 minutes? 1 hour? 24 hours? > As above. > > The "filter based on source SP" is a secondary line of defense. An attack > signature is an even better line of primary attack, if there is one. Normal > abuse would not have a signature. A DDoS attack often does. >> >> -Marc- >> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From fluffy@cisco.com Sat Nov 7 15:37:10 2009 Return-Path: <fluffy@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1E83A679C for <ecrit@core3.amsl.com>; Sat, 7 Nov 2009 15:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.494 X-Spam-Level: X-Spam-Status: No, score=-105.494 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOHpnkJGAnsg for <ecrit@core3.amsl.com>; Sat, 7 Nov 2009 15:37:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AECCD3A68D8 for <ecrit@ietf.org>; Sat, 7 Nov 2009 15:37:09 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOKT9UpAaHte/2dsb2JhbADCfpchgj+BfwSCYA X-IronPort-AV: E=Sophos;i="4.44,701,1249257600"; d="scan'208";a="102910662" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2009 23:37:05 +0000 Received: from tky-vpn-client-231-209.cisco.com (tky-vpn-client-231-209.cisco.com [10.70.231.209]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA7Nb2t0017491; Sat, 7 Nov 2009 23:37:03 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E900B1CA59D@zharhxm1.corp.nortel.com> Date: Sat, 7 Nov 2009 08:04:43 +0900 Content-Transfer-Encoding: 7bit Message-Id: <47ED2AE6-6BD2-40AD-9E9F-B97A60538F4B@cisco.com> References: <0913B6CD18F370498CD65864CF254E900B1CA59D@zharhxm1.corp.nortel.com> To: ECRIT <ecrit@ietf.org> X-Mailer: Apple Mail (2.1076) Cc: Hannes Tschofenig <hannes.tschofenig@nsn.com> Subject: Re: [Ecrit] New Version Notification for draft-patel-ecrit-sos-parameter-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 07 Nov 2009 23:37:10 -0000 It was pointed out to me that some registrars that do not support the emergency registration will accept a contact with the sos parameter and will also return it in the 200. They just copy the data. Because of this, I don't think that detecting the parameter in the 200 is a sufficient way for the UA to know the registrar supports this mechanism. Due to it's importance for emergency calls, this seems like a real problem. My recommended fix to this would be to add a required/supported option tag. I realize this is not great news to many of the folks involved but from what I have heard, this does sounds like a problem. Glad to hear any ideas on how to get a solutions published quickly that meets 3GPPs requirements. Cullen <with my AD hat on> On Oct 27, 2009, at 7:14 , Milan Patel wrote: > Hi Cullen, > > I have submitted a new version of draft-patel-ecrit-sos-parameter > > Latest changes are: > - clarification of use > - change of URI parameter name to "reg-type" which can have a value > - specifically for 3GPP's IMS emergency services solution, "reg-type" > takes the value "sos". > > - the URI parameter is extensible to allow other values to be used in > the future for other use cases where the registration type needs to be > explicitly identified to the registrar. > > I hope this helps in addressing the concerns that you and others had > about the previous version. > Due to the 3GPP release 7 dependency on this draft, I hope we can > reach > consensus on this draft as soon as possible. > > Best regards, > Milan > > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 26 October 2009 22:04 > To: Patel, Milan (MOP:EP10) > Subject: New Version Notification for draft-patel-ecrit-sos- > parameter-07 > > > > A new version of I-D, draft-patel-ecrit-sos-parameter-07.txt has been > successfuly submitted by Milan Patel and posted to the IETF > repository. > > Filename: draft-patel-ecrit-sos-parameter > Revision: 07 > Title: SOS Uniform Resource Identifier (URI) Parameter for > Marking of Session Initiation Protocol (SIP) Requests related to > Emergency Services > Creation_date: 2009-10-26 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document defines a new Session Initiation Protocol (SIP) Uniform > Resource Identifier (URI) parameter intended for marking SIP > registration requests related to emergency services. The URI > parameter is extensible to allow future values to be defined if > required by other use cases that require specific SIP registrations > to be distinctly identified. The usage of this new URI parameter > complements the usage of the Service Uniform Resource Name (URN) and > is not intended to replace it. > > > > > The IETF Secretariat. > > From hgs@cs.columbia.edu Sun Nov 8 07:22:57 2009 Return-Path: <hgs@cs.columbia.edu> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DD228C0FA for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 07:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip1I2g9Q3kJW for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 07:22:56 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 3CE7B28C18F for <ecrit@ietf.org>; Sun, 8 Nov 2009 07:22:56 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA8FNKMl013136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ecrit@ietf.org>; Sun, 8 Nov 2009 10:23:21 -0500 (EST) From: Henning Schulzrinne <hgs@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 8 Nov 2009 10:23:20 -0500 References: <41AEEE92-10BD-437B-9B8B-2F82E1A49245@cs.columbia.edu> To: ECRIT <ecrit@ietf.org> Message-Id: <10EEBD8B-B42D-4108-8D7C-F522EFD8528E@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Nov 2009 15:22:57 -0000 Some of the discussion has been superseded since then, but I'm forwarding the message exchange, as suggested by Gabor. Henning Begin forwarded message: > From: Henning Schulzrinne <hgs@cs.columbia.edu> > Date: November 2, 2008 2:04:27 PM EST > To: <Gabor.Bajko@nokia.com> <Gabor.Bajko@nokia.com> > Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Stephen McCann <stephen.mccann@roke.co.uk > > > Subject: Re: Comments on draft-schulzrinne-ecrit-unauthenticated- > access-03 - Section 1 > > > On Nov 1, 2008, at 4:39 AM, <Gabor.Bajko@nokia.com> <Gabor.Bajko@nokia.com > > wrote: > >> Isn't it a safe assumtion that in case of NAA, the existence of a VSP >> does not matter? I.e., when the ISP gives access to an NAA device for >> emergency calls purposes, it is expected to provide additional >> assistance for the end host to place the emergency call, without >> requiring the end host to have a VSP. > > Depends on the assumptions. If PSAPs rely on VSPs to provide user > identity to deal with prank calls, for example, the presence or > absence of a VSP could matter in the NAA case. We haven't discussed > that aspect much, but I wouldn't be surprised if the PSAP started > getting worried if there's no realistic way to track down crank calls. > >> >> >> In NVP case the ISP has no means to know that it needs to provide >> emergency call related additional assistance to the end host. The end >> host is pretty much on its own and needs to have a way to determine >> its >> location and find a LoST server, even in case RFC5223 is not >> supported >> by the ISP. > > Realistically, in the NVP case, the ISP has to at least provide a > pointer to a LoST server. I don't think we have any other way to > provide the caller with that information, given that manual > configuration isn't really a viable option. > > The text I wrote alludes to that. Are you disagreeing with the text > or the formulation? > > >> >> Or, have a separate requirement that ISPs committed to assist end >> hosts >> in emergency calling, need to support RFC5223. Or, as described in >> section 5, have an ESRP which routes the call to the PSAP to which >> that >> access network belongs to. > > This is probably something that the phone-BCP needs to address, > namely what happens if the client cannot find a LoST server. In that > case, the ISP would have to offer an ESRP, as you say. Here's some > text for the current draft: > > OLD: > >>> the ISP MUST provide the address of a LoST server via DHCP [rfc] if >>> this model is to be supported. > > > NEW: > > the ISP MUST either provide the ... or an outbound proxy that can > recognize and route emergency calls. Providing a reference to a LoST > server is preferred since it allows the user agent to automatically > obtain the local emergency dial strings. > > >> >> >> The ZBP case can be split into either NVP or regular VoIP emergency >> call >> through a VoIP service provider, depending on whether the VSP is >> required by regulation to provide emergency calling services to such >> customers or not. > > That's true, except for the discussion about fraud prevention. The > current text alludes to that. > > It seemed worthwhile to split out the case since it needs to be > addressed explicitly by regulation and VSP need to take it into > account in building their infrastructure. (For example, this will > probably affect how they handle any RADIUS-based authentication, > since it now differs for REGISTER and emergency INVITE.) > > >> >> >> I think it is good to have these definitions, but at the end it all >> comes down to what assistance an ISP needs to provide to an end >> host in >> the NAA case, or what the end host is supposed to do when it does >> have >> network access, but does not have a VSP which could assist it in >> emergency calling. > > Right - I was just trying to divide the cases, even though the most > interesting case is the NAA case. The previous version wasn't all > that clear on the distinctions and lumped together NAA and NVP. As > you say, these differ significantly. > > In general, do you have specific text suggestions to improve clarity? > > Henning > > From hgs@cs.columbia.edu Sun Nov 8 07:23:32 2009 Return-Path: <hgs@cs.columbia.edu> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C211528C139 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 07:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LbW2lbo8v9n for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 07:23:31 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 87ADD28C191 for <ecrit@ietf.org>; Sun, 8 Nov 2009 07:23:31 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA8FNKMm013136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ecrit@ietf.org>; Sun, 8 Nov 2009 10:23:56 -0500 (EST) From: Henning Schulzrinne <hgs@cs.columbia.edu> Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 10:23:56 -0500 References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> To: ECRIT <ecrit@ietf.org> Message-Id: <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Nov 2009 15:23:32 -0000 Begin forwarded message: > From: Henning Schulzrinne <hgs@cs.columbia.edu> > Date: October 28, 2008 5:30:39 PM EDT > To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> > Cc: G=E1bor Bajk=F3 <Gabor.Bajko@nokia.com>, Stephen McCann = <stephen.mccann@roke.co.uk=20 > > > Subject: Comments on draft-schulzrinne-ecrit-unauthenticated-=20 > access-03 - Section 1 > > I think the current terminology is really confusing, as it =20 > commingles access authorization and VSP authorization, which have =20 > rather different consequences. Thus, if this is the WiMax =20 > terminology, I think they are just wrong and we shouldn't propagate =20= > their confusing terminology. > > I'm not sure about my attempt below, so I'd appreciate comments. In =20= > particular, there might be a better name instead of ZBP. > > --- > > Second paragraph and following: > > Roughly speaking, the IETF emergency services architecture [bcp] =20 > divides responsibility for handling emergency calls between the =20 > access network (ISP), the VoIP service provider (VSP) and the =20 > provider of emergency signaling services, the emergency service =20 > network (ESN). The access network may provide location information =20 > to end systems, but does not have to provide any VoIP signaling =20 > functionality. The emergency caller can reach the ESN either =20 > directly or through the VoIP provider's outbound proxy. Any of the =20 > three parties can provide the mapping from location to PSAP URI by =20 > offering LoST [RFC] services. > > In general, a set of automated configuration mechanisms allows a =20 > device to function in a variety of architectures, without the user =20 > being aware of the details on who provides location, mapping =20 > services or call routing services. However, if emergency calling is =20= > to be supported when the calling device lacks access network =20 > authorization or does not have a VoIP provider, one or more of the =20 > providers may need to provide additional services and functions. > > In all cases, the end device MUST be able to perform a LoST lookup =20 > and otherwise conduct the emergency call in the same manner as when =20= > the three exceptional conditions discussed below do not apply. > > We distinguish between three conditions: > > (1) No access authorization (NAA): The current access network =20 > requires access authorization and the caller does not have valid =20 > user credentials. (This includes the case where the access network =20 > allows pay-per-use, as is common for wireless hotspots, but there is =20= > insufficient time to pay for access.) > > (2) No VoIP provider (NVP): The caller does not have a VoIP service =20= > provider (VSP) at the time of the call. > > (3) Zero-balance VoIP provider (ZBP): The caller has valid =20 > credentials with a VSP, but is not allowed to place calls, e.g., =20 > because the user has a zero balance in a prepaid account. > > A user may well suffer from both NAA and NVP or ZBP at the same =20 > time. Depending on local policy and regulations, it may not be =20 > possible to place emergency calls in the NAA case. Unless local =20 > regulations require user identification, it should always be =20 > possible to place calls in the NVP case, with minimal impact on the =20= > ISP. Unless the ESN requires that all calls traverse a known set of =20= > VSPs, a caller should be able to place an emergency call in the ZBP =20= > case. We discuss each case in separate sections below. > > ---- > > <section>No Access Authorization (NAA) > > In the NAA (No Access Authorization) case, the emergency caller does =20= > not posses valid credentials for the access network. If local =20 > regulations or policy allows or require, the access network may or =20 > needs to cooperate in providing emergency calling services. =20 > Generally, the ISP will want to ensure that devices do not pretend =20 > to place emergency calls, but then abuse the access for obtaining =20 > more general services fraudulently. > > In particular, the ISP MUST allow emergency callers to acquire an IP =20= > address and to reach a LoST server, either provided by the ISP or =20 > some third party. It SHOULD also provide location information via =20 > one of the mechanisms specified in [bcp] without requiring =20 > authorization unless it can safely assume that all nodes in the =20 > access network can determine their own location, e.g., via GPS. > > The details of how filtering is performed depends on the details of =20= > the ISP architecture and are beyond the scope of this document. We =20 > illustrate a possible model. If the ISP runs its own LoST server, it =20= > would maintain an access control list including all IP addresses =20 > contained in responses returned by the LoST server, as well as the =20 > LoST server itself. (It may need to translate the domain names =20 > returned to IP addresses and hope that the resolution captures all =20 > possible DNS responses.) Since the media destination addresses are =20 > not predictable, the ISP also has to provide a SIP outbound proxy so =20= > that it can determine the media addresses and add those to the =20 > filter list. > > <section>No VoIP Service Provider (NVP) > > In the second case, the emergency caller has no current VoIP service =20= > provider (VSP). This case poses no particular difficulties unless it =20= > is assumed that only VSPs provide LoST server or that ESNs only =20 > accept calls that reach it through a set of known VSPs. However, =20 > since the calling device cannot obtain configuration information =20 > from its VSP, the ISP MUST provide the address of a LoST server via =20= > DHCP [rfc] if this model is to be supported. The LoST server may be =20= > operated either by the ISP or a third party. > > <section>Zero-Balance VoIP Service Provider (ZBP) > > In the case of zero-balance VoIP service provider, the VSP can =20 > authenticate the caller, but the caller is not authorized to place =20 > regular VoIP calls, e.g., because the contract has expired or the =20 > prepaid account for the customer has been depleted. Naturally, a VSP =20= > can simply disallow access by such customers, so that all such =20 > customers find themselves in the NVP situation described above. If =20 > VSPs desire or are required by regulation to provide emergency =20 > calling services to such customers, they need to provide LoST =20 > services to such customers and may need to provide outbound SIP =20 > proxy services. As usual, the calling device looks up the LoST =20 > server via SIP configuration. > > Unless the emergency call traverses a PSTN gateway or the VSP =20 > charges for IP-to-IP calls, there is little potential for fraud. If =20= > the VSP also operates the LoST server, the outbound proxy MAY =20 > restrict outbound calls to the SIP URIs returned by the LoST server. =20= > It is NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that =20 > list may change. > > --- > > Henning > > > > > > > > > > From ted.ietf@gmail.com Sun Nov 8 16:47:19 2009 Return-Path: <ted.ietf@gmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA4B3A6A24 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 16:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YjhYRAIw9Ci for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 16:47:19 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id EBCE43A68E7 for <ecrit@ietf.org>; Sun, 8 Nov 2009 16:47:18 -0800 (PST) Received: by pxi1 with SMTP id 1so1905249pxi.32 for <ecrit@ietf.org>; Sun, 08 Nov 2009 16:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hoKH1cInHqgCcw88ZQXOPVwrbjCPLsgzFDwB6z8pgFE=; b=XhA51rbwiANKfWIEqWF8zJNbbkKDr8tcL8LamE/y4ASBWYInabtu2kcRTCukasmnAW psdwImVtXEnLdg46wkgDEVyZIbmkOlzaOshiFZltHbNX75fMI5UbKORqDl/IBWY1TyQI Pd9m6XF9O6NAuJSxPInPhUacv6vEWPySXBlnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=clXdBCrK9l2N9ypnEi5QPedJiG0jeWTlPMe1PalQYDYJRJdVRcW3TOxcq1qQd3qfp2 MXkC4PGTIUMJx9Y8DdhU1bGZYjVK4Q9mCqCSzIuVWmDvuqllq97fEwUnkIgLr1VGopqM L9UnVdBgDUbGSYhYMVK6GEu9xGKxH/xV8ul3k= MIME-Version: 1.0 Received: by 10.142.2.14 with SMTP id 14mr751366wfb.93.1257727661764; Sun, 08 Nov 2009 16:47:41 -0800 (PST) In-Reply-To: <EA9D304C-78BA-492E-844F-1C9A4F299E93@cs.columbia.edu> References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com> <EA9D304C-78BA-492E-844F-1C9A4F299E93@cs.columbia.edu> Date: Sun, 8 Nov 2009 16:47:41 -0800 Message-ID: <6e04e83a0911081647k62b8bd63y680b2c242b330b2@mail.gmail.com> From: Ted Hardie <ted.ietf@gmail.com> To: Henning Schulzrinne <hgs@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org Subject: Re: [Ecrit] Service URN IANA Policy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 00:47:19 -0000 Hi Henning, Sorry for the delay in replying. I am looking for guidance to the expert who reviews whether or not a top-level-service URN goes in. The advice to the expert reviewer for the sub-services would presumably be useful as well, but it can't really go into this document and can't be required since the introduction of top-level-service URNs no longer requires a document. One advantage of requiring a document is ensuring that the document can contain advice on the sub-service, but that may not be the right trade-off. If we did go that way, I would argue for "specification required" rather than standards action. regards, Ted On Tue, Nov 3, 2009 at 7:45 PM, Henning Schulzrinne <hgs@cs.columbia.edu> w= rote: > Picking up an earlier thread... > > Ted, > > are you looking for general guidance for all top-level service URNs, pres= ent > and future, or as a meta-requirement, i.e., each top-level service should > provide guidance on whether more "liberal" or "conservative" policies are > appropriate? For example, for emergency services, "conservative" seems > appropriate, while for our point-of-interest services (hotels, restaurant= s, > banks, ...), a more liberal policy, with a lower threshold, seems to be m= ore > in keeping with the necessarily imprecise definitions of such services. > > Henning > > On Sep 30, 2009, at 12:44 PM, Ted Hardie wrote: > >> Howdy, >> >> I don't have any problems with this allocation policy, but I see two >> things in the draft that should probably change. =A0The appointment >> should be by the IESG, not the RAI area director or directors; this is >> the traditional appointment mechanism and it allows other ADs to >> contribute, even if RAI leads. =A0For services that are not SOS-related, >> other areas may have significant input. =A0Second, some text in the >> document that describes the conditions under which new entries are >> approved or denied is very useful, as it guides the later incumbents >> in the role. =A0In the URI space, for example, there are two strains of >> thought about minting new schemes: =A0one is that it should be >> restricted to cases which absolutely cannot be met by an existing >> scheme; the second is that the schemes will be minted anyway and that >> registration largely serves to avoid interoperability problems. >> Having the working group provide general guidance on this point is >> very useful, in my opinion. >> > > From Ray.Bellis@nominet.org.uk Sun Nov 8 18:48:41 2009 Return-Path: <Ray.Bellis@nominet.org.uk> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC893A6A4C for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 18:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.678 X-Spam-Level: X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmqTyAss0JmL for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 18:48:39 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 3AECE3A6A33 for <ecrit@ietf.org>; Sun, 8 Nov 2009 18:48:38 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=MYpLe9KFLveZd4i0p50H+Tnax4BAvlxVSOKjesrMghNi/wJ2jxnEcbGE fXICzQZZYaj2eTwDFQ7waE+hBik32ejkeoLGH9q5BDv6PeK4cuhAYDOOB Rch9cpg2Lvnb1Qv; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257734945; x=1289270945; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Fwd:=20Comments=20on=09draft-schulzrinne-ecrit-unaut henticated-access-03=0D=0A=20-=20Section=201|Date:=20Mon, =209=20Nov=202009=2011:49:02=20+0900|Message-ID:=20<OFD44 F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nomi net.org.uk>|To:=20Henning=20Schulzrinne=20<hgs@cs.columbi a.edu>|Cc:=20ECRIT=20<ecrit@ietf.org>|MIME-Version:=201.0 |In-Reply-To:=20<6E230B52-2340-43F7-9EF0-16912DC307E8@cs. columbia.edu>|References:=20<15F9ABA8-B0D3-4F7F-BD8C-28A6 B8A40A4D@cs.columbia.edu>=20<6E230B52-2340-43F7-9EF0-1691 2DC307E8@cs.columbia.edu>; bh=WGtea1PQNiz6/r3H9bTkXIUl6f1Tc9e9uDgqpq2KRI0=; b=BhqjIAFpc26rtR+IYRiVxyRlyMlbatFRqe81AVDBorfqTsKEDmUZDHWX TWrNN7B26AEwQBZhFhHVrGvMsZZxrjlVxHTMBcP0JDjUGFShTgvuYgtEn 9JT46FUuoASeBwY; X-IronPort-AV: E=Sophos;i="4.44,705,1249254000"; d="scan'208";a="14181805" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 09 Nov 2009 02:49:03 +0000 In-Reply-To: <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> To: Henning Schulzrinne <hgs@cs.columbia.edu> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> From: Ray.Bellis@nominet.org.uk Date: Mon, 9 Nov 2009 11:49:02 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/11/2009 02:49:03 AM, Serialize complete at 09/11/2009 02:49:03 AM Content-Type: multipart/alternative; boundary="=_alternative 000F70F949257669_=" Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 02:48:41 -0000 This is a multipart message in MIME format. --=_alternative 000F70F949257669_= Content-Type: text/plain; charset="US-ASCII" > <section>No Access Authorization (NAA) > > In the NAA (No Access Authorization) case, the emergency caller does > not posses valid credentials for the access network. If local > regulations or policy allows or require, the access network may or > needs to cooperate in providing emergency calling services. > Generally, the ISP will want to ensure that devices do not pretend > to place emergency calls, but then abuse the access for obtaining > more general services fraudulently. As the Network Ops guy in my previous job, I have to admit that I have great difficulty understanding the NNA issue. In the UK it's very likely that access networks will be required (by regulation) to assist with emergency calls, but there's _no_ way that this regulation will ever apply to users that are unknown to the ISP. We offered ADSL services and _fixed_ wireless access. On neither of these networks would it have been practical to support unauthenticated users. Your "pay-per-use" public WiFi (or 802.16e mobile WiMax) example is in fact the only technology I can think of where this could usefully apply. In particular this is because commonly-used WiFi access control systems need full IP connectivity, even if it's just into a walled garden. Most other technologies authenticate at lower layers than that - think PPP, or similar. I believe that more explanation is necessary of exactly what sorts of ISP and access network technologies you believe might be covered by this requirement. Ray --=_alternative 000F70F949257669_= Content-Type: text/html; charset="US-ASCII" <tt><font size=2>> <section>No Access Authorization (NAA)<br> ><br> > In the NAA (No Access Authorization) case, the emergency caller does  <br> > not posses valid credentials for the access network. If local  <br> > regulations or policy allows or require, the access network may or  <br> > needs to cooperate in providing emergency calling services.  <br> > Generally, the ISP will want to ensure that devices do not pretend  <br> > to place emergency calls, but then abuse the access for obtaining  <br> > more general services fraudulently.<br> </font></tt> <br><tt><font size=2>As the Network Ops guy in my previous job, I have to admit that I have great difficulty understanding the NNA issue.</font></tt> <br> <br><tt><font size=2>In the UK it's very likely that access networks will be required (by regulation) to assist with emergency calls, but there's _no_ way that this regulation will ever apply to users that are unknown to the ISP.</font></tt> <br> <br><tt><font size=2>We offered ADSL services and _fixed_ wireless access.  On neither of these networks would it have been practical to support unauthenticated users.</font></tt> <br> <br><tt><font size=2>Your "pay-per-use" public WiFi (or 802.16e mobile WiMax) example is in fact the only technology I can think of where this could usefully apply.  In particular this is because commonly-used WiFi access control systems need full IP connectivity, even if it's just into a walled garden.  Most other technologies authenticate at lower layers than that - think PPP, or similar.</font></tt> <br> <br><tt><font size=2>I believe that more explanation is necessary of exactly what sorts of ISP and access network technologies you believe might be covered by this requirement.</font></tt> <br> <br><tt><font size=2>Ray</font></tt> <br> --=_alternative 000F70F949257669_=-- From hgs@cs.columbia.edu Sun Nov 8 19:27:05 2009 Return-Path: <hgs@cs.columbia.edu> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19F53A6822 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 19:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z06H6aDcf3y for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 19:27:05 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id F09E83A67F1 for <ecrit@ietf.org>; Sun, 8 Nov 2009 19:27:04 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA93RSaw020698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Nov 2009 22:27:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne <hgs@cs.columbia.edu> In-Reply-To: <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> Date: Sun, 8 Nov 2009 22:27:28 -0500 Content-Transfer-Encoding: 7bit Message-Id: <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 03:27:05 -0000 I agree that this requires L2 cooperation in many cases. There is a separate discussion on the L2 case that will apparently take place in ECRIT, with EAP as one main topic of discussion. Henning On Nov 8, 2009, at 9:49 PM, Ray.Bellis@nominet.org.uk wrote: > > <section>No Access Authorization (NAA) > > > > In the NAA (No Access Authorization) case, the emergency caller does > > not posses valid credentials for the access network. If local > > regulations or policy allows or require, the access network may or > > needs to cooperate in providing emergency calling services. > > Generally, the ISP will want to ensure that devices do not pretend > > to place emergency calls, but then abuse the access for obtaining > > more general services fraudulently. > > As the Network Ops guy in my previous job, I have to admit that I > have great difficulty understanding the NNA issue. > > In the UK it's very likely that access networks will be required (by > regulation) to assist with emergency calls, but there's _no_ way > that this regulation will ever apply to users that are unknown to > the ISP. > > We offered ADSL services and _fixed_ wireless access. On neither of > these networks would it have been practical to support > unauthenticated users. > > Your "pay-per-use" public WiFi (or 802.16e mobile WiMax) example is > in fact the only technology I can think of where this could usefully > apply. In particular this is because commonly-used WiFi access > control systems need full IP connectivity, even if it's just into a > walled garden. Most other technologies authenticate at lower layers > than that - think PPP, or similar. > > I believe that more explanation is necessary of exactly what sorts > of ISP and access network technologies you believe might be covered > by this requirement. > > Ray From Ray.Bellis@nominet.org.uk Sun Nov 8 20:09:51 2009 Return-Path: <Ray.Bellis@nominet.org.uk> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F173A6820 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tlCyGnE0Ypr for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:09:51 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id DEFBE3A67F1 for <ecrit@ietf.org>; Sun, 8 Nov 2009 20:09:50 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=CWbBJa2unwRcbAfNcmMuXopP8JRl+55bm2m/jEt2raM7folaTKfv3Wak rhhCvsnNoir7pkX5cK1zhloIOqZzWVY1exE4MbpXPzXTNBpXB2YbYjJn6 c6pz/DkthqPIc1a; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257739817; x=1289275817; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Fwd:=20Comments=20on=09draft-schulzrinne-ecrit-unaut henticated-access-03=0D=0A=20-=20Section=201|Date:=20Mon, =209=20Nov=202009=2013:10:12=20+0900|Message-ID:=20<OF12C 6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nomi net.org.uk>|To:=20Henning=20Schulzrinne=20<hgs@cs.columbi a.edu>|Cc:=20ECRIT=20<ecrit@ietf.org>|MIME-Version:=201.0 |In-Reply-To:=20<564BBE0C-AEBD-428F-9597-C56F3934678A@cs. columbia.edu>|References:=20<15F9ABA8-B0D3-4F7F-BD8C-28A6 B8A40A4D@cs.columbia.edu>=20<6E230B52-2340-43F7-9EF0-1691 2DC307E8@cs.columbia.edu>=20<OFD44F2219.8D2A5E10-ON802576 69.000DBA41-49257669.000F70FB@nominet.org.uk>=20<564BBE0C -AEBD-428F-9597-C56F3934678A@cs.columbia.edu>; bh=QQzU0oeBaxrS+1P5HX4ytBDgHpvVR/M68qWrN12dOAE=; b=znFeY8Tc9bv4RHEiiGqu9+Vs8zfd+f1+Vf6ynZfE2hvSnVtYjAtQMmhX Jmm4KWcvUYhsUaWPLpmlU6ywnEQG2GtYdVhfUabcixGA3g8wRMs85/S5V N0Ov2dEx+mB09xE; X-IronPort-AV: E=Sophos;i="4.44,705,1249254000"; d="scan'208";a="19225293" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 09 Nov 2009 04:10:15 +0000 In-Reply-To: <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> To: Henning Schulzrinne <hgs@cs.columbia.edu> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> From: Ray.Bellis@nominet.org.uk Date: Mon, 9 Nov 2009 13:10:12 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/11/2009 04:10:14 AM, Serialize complete at 09/11/2009 04:10:14 AM Content-Type: multipart/alternative; boundary="=_alternative 0016E73449257669_=" Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 04:09:52 -0000 This is a multipart message in MIME format. --=_alternative 0016E73449257669_= Content-Type: text/plain; charset="US-ASCII" > I agree that this requires L2 cooperation in many cases. There is a > separate discussion on the L2 case that will apparently take place in > ECRIT, with EAP as one main topic of discussion. I think that misses my point. Where an access network _already_ uses the full IP stack to authenticate customers (using a web portal for example) then unauthenticated access is relatively easy. Such networks already satisfy the requirement to give out a Layer 3 IP address to any client regardless of their layer 1 or 2 connectivity or identifiers. However if the authentication happens at much lower levels then (IMHO) it will be _very_ difficult to support unauthenticated access. Ray --=_alternative 0016E73449257669_= Content-Type: text/html; charset="US-ASCII" <tt><font size=2><br> > I agree that this requires L2 cooperation in many cases. There is a  <br> > separate discussion on the L2 case that will apparently take place in  <br> > ECRIT, with EAP as one main topic of discussion.<br> </font></tt> <br><tt><font size=2>I think that misses my point.</font></tt> <br> <br><tt><font size=2>Where an access network _already_ uses the full IP stack to authenticate customers (using a web portal for example) then unauthenticated access is relatively easy.   Such networks already satisfy the requirement to give out a Layer 3 IP address to any client regardless of their layer 1 or 2 connectivity or identifiers.</font></tt> <br> <br><tt><font size=2>However if the authentication happens at much lower levels then (IMHO) it will be _very_ difficult to support unauthenticated access.</font></tt> <br> <br><tt><font size=2>Ray</font></tt> <br> --=_alternative 0016E73449257669_=-- From drage@alcatel-lucent.com Sun Nov 8 20:26:55 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6524C28C151 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3BgFL24FeRo for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:26:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 3979D28C14E for <ecrit@ietf.org>; Sun, 8 Nov 2009 20:26:53 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA94RFIv021721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Nov 2009 05:27:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 9 Nov 2009 05:27:15 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Cullen Jennings <fluffy@cisco.com>, ECRIT <ecrit@ietf.org> Date: Mon, 9 Nov 2009 05:27:12 +0100 Thread-Topic: [Ecrit] New Version Notification for draft-patel-ecrit-sos-parameter-07 Thread-Index: AcpgA00uz26Tfj7RS+WQ2WAdnw/ljwA8VYnQ Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2092E5E40@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <0913B6CD18F370498CD65864CF254E900B1CA59D@zharhxm1.corp.nortel.com> <47ED2AE6-6BD2-40AD-9E9F-B97A60538F4B@cisco.com> In-Reply-To: <47ED2AE6-6BD2-40AD-9E9F-B97A60538F4B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: Hannes Tschofenig <hannes.tschofenig@nsn.com> Subject: Re: [Ecrit] New Version Notification for draft-patel-ecrit-sos-parameter-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 04:26:55 -0000 So just to be clear here. You are presumably proposing an option tag in addition to the new URI param= eter. Use of the option tag without the parameter would merely confirm that the e= xtension was supported. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Cullen Jennings > Sent: Friday, November 06, 2009 11:05 PM > To: ECRIT > Cc: Hannes Tschofenig > Subject: Re: [Ecrit] New Version Notification for=20 > draft-patel-ecrit-sos-parameter-07 >=20 >=20 > It was pointed out to me that some registrars that do not=20 > support the emergency registration will accept a contact with=20 > the sos parameter and will also return it in the 200. They=20 > just copy the data. Because of this, I don't think that=20 > detecting the parameter in the 200 is a sufficient way for=20 > the UA to know the registrar supports this mechanism. Due to=20 > it's importance for emergency calls, this seems like a real problem. >=20 > My recommended fix to this would be to add a=20 > required/supported option tag. I realize this is not great=20 > news to many of the folks involved but from what I have=20 > heard, this does sounds like a problem. Glad to hear any=20 > ideas on how to get a solutions published quickly that meets=20 > 3GPPs requirements. >=20 > Cullen <with my AD hat on> >=20 >=20 > On Oct 27, 2009, at 7:14 , Milan Patel wrote: >=20 > > Hi Cullen, > > > > I have submitted a new version of draft-patel-ecrit-sos-parameter > > > > Latest changes are: > > - clarification of use > > - change of URI parameter name to "reg-type" which can have a value > > - specifically for 3GPP's IMS emergency services solution,=20 > "reg-type" > > takes the value "sos". > > > > - the URI parameter is extensible to allow other values to=20 > be used in=20 > > the future for other use cases where the registration type=20 > needs to be=20 > > explicitly identified to the registrar. > > > > I hope this helps in addressing the concerns that you and=20 > others had=20 > > about the previous version. > > Due to the 3GPP release 7 dependency on this draft, I hope we can=20 > > reach consensus on this draft as soon as possible. > > > > Best regards, > > Milan > > > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 26 October 2009 22:04 > > To: Patel, Milan (MOP:EP10) > > Subject: New Version Notification for draft-patel-ecrit-sos- > > parameter-07 > > > > > > > > A new version of I-D,=20 > draft-patel-ecrit-sos-parameter-07.txt has been=20 > > successfuly submitted by Milan Patel and posted to the IETF=20 > > repository. > > > > Filename: draft-patel-ecrit-sos-parameter > > Revision: 07 > > Title: SOS Uniform Resource Identifier (URI)=20 > Parameter for > > Marking of Session Initiation Protocol (SIP) Requests related to=20 > > Emergency Services > > Creation_date: 2009-10-26 > > WG ID: Independent Submission > > Number_of_pages: 8 > > > > Abstract: > > This document defines a new Session Initiation Protocol=20 > (SIP) Uniform=20 > > Resource Identifier (URI) parameter intended for marking SIP=20 > > registration requests related to emergency services. The URI=20 > > parameter is extensible to allow future values to be defined if=20 > > required by other use cases that require specific SIP=20 > registrations to=20 > > be distinctly identified. The usage of this new URI parameter=20 > > complements the usage of the Service Uniform Resource Name=20 > (URN) and=20 > > is not intended to replace it. > > > > > > > > > > The IETF Secretariat. > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From bernard_aboba@hotmail.com Sun Nov 8 20:46:01 2009 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEDF28C14F for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HbqHzf3rCwP for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:45:58 -0800 (PST) Received: from blu0-omc1-s34.blu0.hotmail.com (blu0-omc1-s34.blu0.hotmail.com [65.55.116.45]) by core3.amsl.com (Postfix) with ESMTP id 423A628C0DF for <ecrit@ietf.org>; Sun, 8 Nov 2009 20:45:58 -0800 (PST) Received: from BLU137-DS7 ([65.55.116.7]) by blu0-omc1-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 20:46:23 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: <Ray.Bellis@nominet.org.uk>, "'Henning Schulzrinne'" <hgs@cs.columbia.edu> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> In-Reply-To: <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> Date: Sun, 8 Nov 2009 20:46:32 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CA60B4.8E397370" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpg8o0nLjnjoq4rTzirtDkmY4C3TQABJzRg Content-Language: en-us X-OriginalArrivalTime: 09 Nov 2009 04:46:23.0964 (UTC) FILETIME=[96FA11C0:01CA60F7] Cc: 'ECRIT' <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 04:46:01 -0000 ------=_NextPart_000_00F0_01CA60B4.8E397370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ray Bellis said: "However if the authentication happens at much lower levels then (IMHO) it will be _very_ difficult to support unauthenticated access. " Why? Existing authentication mechanisms (such as EAP-TLS, described in RFC 5216) already support client unauthenticated access. All that is necessary is for the client to send an emergency NAI to signal the need for emergency access. The server will still send its certificate which the client should verify. The server can either not request the client certificate based on the emergency NAI, or it can ask for it, but the client will not supply it and the server needs to then conclude the authentication by placing the client on an emergency VLAN. ------=_NextPart_000_00F0_01CA60B4.8E397370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} tt {mso-style-priority:99; font-family:"Courier New";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"; color:#1F497D'>Ray Bellis said:<o:p></o:p></span></b></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"; color:#1F497D'><o:p> </o:p></span></b></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"; color:#1F497D'>“</span></b><tt><span = style=3D'font-size:10.0pt'>However if the authentication happens at much lower levels then (IMHO) it will be = _very_ difficult to support unauthenticated access.</span></tt> <span style=3D'color:#1F497D'>“<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Why? =   Existing authentication mechanisms (such as EAP-TLS, described in RFC 5216) already support = client unauthenticated access.  All that is necessary is for the client to = send an emergency NAI to signal the need for emergency access.  The server will still = send its certificate which the client should verify.  The server can either = not request the client certificate based on the emergency NAI, or it can ask for it, = but the client will not supply it and the server needs to then conclude the = authentication by placing the client on an emergency VLAN. </span><o:p></o:p></p> </div> </body> </html> ------=_NextPart_000_00F0_01CA60B4.8E397370-- From Martin.Dawson@andrew.com Sun Nov 8 20:58:37 2009 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D8E3A6936 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riNGtjibAMIG for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 20:58:33 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 1E0CE3A6942 for <ecrit@ietf.org>; Sun, 8 Nov 2009 20:58:33 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:50815 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5034659AbZKIE66 (ORCPT <rfc822;ecrit@ietf.org>); Sun, 8 Nov 2009 22:58:58 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 8 Nov 2009 22:58:58 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 9 Nov 2009 12:58:53 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: Bernard Aboba <bernard_aboba@hotmail.com>, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.org.uk>, 'Henning Schulzrinne' <hgs@cs.columbia.edu> Date: Mon, 9 Nov 2009 12:58:49 +0800 Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg8o0nLjnjoq4rTzirtDkmY4C3TQABJzRgAABqFRA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4E1C@SISPE7MB1.commscope.com> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> In-Reply-To: <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F0F2E4E1CSISPE7MB1commsc_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: 'ECRIT' <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 04:58:37 -0000 --_000_8B0A9FCBB9832F43971E38010638454F0F2E4E1CSISPE7MB1commsc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And, of course, having granted the device "emergency only access", the only= services the network needs to permit the device access to are the LIS, LoS= T, and the PSAP URI applicable to the point of connect. Unless of course you're also going to let it go off to some arbitrary third= party VSP that has no relationship with the network just so that VSP can p= roxy the emergency call. Then you've bought yourself a whole world of pain = and uncertainty... Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= ernard Aboba Sent: Monday, 9 November 2009 3:47 PM To: Ray.Bellis@nominet.org.uk; 'Henning Schulzrinne' Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticat= ed-access-03 - Section 1 Ray Bellis said: "However if the authentication happens at much lower levels then (IMHO) it = will be _very_ difficult to support unauthenticated access. " Why? Existing authentication mechanisms (such as EAP-TLS, described in RF= C 5216) already support client unauthenticated access. All that is necessa= ry is for the client to send an emergency NAI to signal the need for emerge= ncy access. The server will still send its certificate which the client sh= ould verify. The server can either not request the client certificate base= d on the emergency NAI, or it can ask for it, but the client will not suppl= y it and the server needs to then conclude the authentication by placing th= e client on an emergency VLAN. --_000_8B0A9FCBB9832F43971E38010638454F0F2E4E1CSISPE7MB1commsc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:ns1=3D"http://schemas.microsoft.com/office/2004/12/omml"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} tt {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@Batang"; panose-1:2 3 6 0 0 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} tt {font-family:"Courier New";} span.EmailStyle18 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-AU link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>And, of course, having granted the dev= ice “emergency only access”, the only services the network needs to permit the devic= e access to are the LIS, LoST, and the PSAP URI applicable to the point of connect.<= o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Unless of course you’re also goi= ng to let it go off to some arbitrary third party VSP that has no relationship with the network just so that VSP can proxy the emergency call. Then you’ve bo= ught yourself a whole world of pain and uncertainty…<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Cheers,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Martin <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa= mily:Tahoma'> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Bernard Aboba<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, 9 November 200= 9 3:47 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Ray.Bellis@nominet.org.u= k; 'Henning Schulzrinne'<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> 'ECRIT'<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Ecrit] Fwd: Co= mments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1</span></fo= nt><span lang=3DEN-US><o:p></o:p></span></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><b><font size=3D2 color=3D"#1f497d" face=3DTahoma><spa= n lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;color:#1F497D;fon= t-weight: bold'>Ray Bellis said:<o:p></o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D2 color=3D"#1f497d" face=3DTahoma><spa= n lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;color:#1F497D;fon= t-weight: bold'><o:p> </o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D2 color=3D"#1f497d" face=3DTahoma><spa= n lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;color:#1F497D;fon= t-weight: bold'>“</span></font></b><tt><font size=3D2 face=3D"Courier New"><spa= n lang=3DEN-US style=3D'font-size:10.0pt'>However if the authentication happens at much lo= wer levels then (IMHO) it will be _very_ difficult to support unauthenticated access.</span></font></tt><span lang=3DEN-US> <font color=3D"#1f497d"><span style=3D'color:#1F497D'>“<o:p></o:p></span></font></span></p> <p class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times New Rom= an"><span lang=3DEN-US style=3D'font-size:12.0pt;color:#1F497D'><o:p> </o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times New Rom= an"><span lang=3DEN-US style=3D'font-size:12.0pt;color:#1F497D'>Why?   Exis= ting authentication mechanisms (such as EAP-TLS, described in RFC 5216) already support client unauthenticated access.  All that is necessary is for t= he client to send an emergency NAI to signal the need for emergency access.&nb= sp; The server will still send its certificate which the client should verify.  The server can either not request the client certificate base= d on the emergency NAI, or it can ask for it, but the client will not supply it = and the server needs to then conclude the authentication by placing the client = on an emergency VLAN. </span></font><span lang=3DEN-US><o:p></o:p></span></p> </div> </body> </html> --_000_8B0A9FCBB9832F43971E38010638454F0F2E4E1CSISPE7MB1commsc_-- From Ray.Bellis@nominet.org.uk Sun Nov 8 21:02:41 2009 Return-Path: <Ray.Bellis@nominet.org.uk> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8B228C16A for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rowFNXEfFX5p for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:02:40 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 57B6128C15E for <ecrit@ietf.org>; Sun, 8 Nov 2009 21:02:37 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=h4iA/VkmBorhXEEza/nuS0pTIjSee0vFTJscrHVZpCtnmBOvMzluPBfh El5aC86JT7ul+IjXN0AqjwIj8ft7mrNeOEOPKk/57aDp3Wshm9oGX+BZC /IZO2bf2m5bg2jm; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257742983; x=1289278983; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Fwd:=20Comments=09on=09draft-schulzrinne-ecrit-unaut henticated-access-03=0D=0A=20-=20Section=201|Date:=20Mon, =209=20Nov=202009=2014:03:00=20+0900|Message-ID:=20<OF90C BDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nomi net.org.uk>|To:=20"Bernard=20Aboba"=20<bernard_aboba@hotm ail.com>|Cc:=20'ECRIT'=20<ecrit@ietf.org>,=0D=0A=09"'Henn ing=20Schulzrinne'"=20<hgs@cs.columbia.edu>|MIME-Version: =201.0|In-Reply-To:=20<BLU137-DS73B3D446E7634C650E81293AC 0@phx.gbl>|References:=20<15F9ABA8-B0D3-4F7F-BD8C-28A6B8A 40A4D@cs.columbia.edu>=09<6E230B52-2340-43F7-9EF0-16912DC 307E8@cs.columbia.edu>=0D=0A=09<OFD44F2219.8D2A5E10-ON802 57669.000DBA41-49257669.000F70FB@nominet.org.uk>=0D=0A=09 <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu>=09 <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E73 7@nominet.org.uk>=20<BLU137-DS73B3D446E7634C650E81293AC0@ phx.gbl>; bh=Gy8QdMKkSdDwc5CGPCoccg6poU71KdG59Newv8EpiNs=; b=Z+3wMyGH9HoItY0XzTl4DKkoeFxJhjyTGNaVc860h7NDGQYuOXI2HASX f4KKqoJl69gA/9j7jxWcnt0nDqejy0jIDgOLSJNO6s1HQVu2mes0aWyxV /smKg16yET2FcTG; X-IronPort-AV: E=Sophos;i="4.44,705,1249254000"; d="scan'208";a="14183393" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 09 Nov 2009 05:03:02 +0000 In-Reply-To: <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> To: "Bernard Aboba" <bernard_aboba@hotmail.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: <OF90CBDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nominet.org.uk> From: Ray.Bellis@nominet.org.uk Date: Mon, 9 Nov 2009 14:03:00 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/11/2009 05:03:02 AM, Serialize complete at 09/11/2009 05:03:02 AM Content-Type: multipart/alternative; boundary="=_alternative 001BBC5C49257669_=" Cc: 'ECRIT' <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 05:02:41 -0000 This is a multipart message in MIME format. --=_alternative 001BBC5C49257669_= Content-Type: text/plain; charset="US-ASCII" > Why? Existing authentication mechanisms (such as EAP-TLS, > described in RFC 5216) already support client unauthenticated > access. All that is necessary is for the client to send an > emergency NAI to signal the need for emergency access. The server > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the > emergency NAI, or it can ask for it, but the client will not supply > it and the server needs to then conclude the authentication by > placing the client on an emergency VLAN. That's fine _if_ your network supports such a mechanism. None of the network technologies I ever ran did. All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this. Ray --=_alternative 001BBC5C49257669_= Content-Type: text/html; charset="US-ASCII" <tt><font size=2>> Why?   Existing authentication mechanisms (such as EAP-TLS, <br> > described in RFC 5216) already support client unauthenticated <br> > access.  All that is necessary is for the client to send an <br> > emergency NAI to signal the need for emergency access.  The server <br> > will still send its certificate which the client should verify.  The<br> > server can either not request the client certificate based on the <br> > emergency NAI, or it can ask for it, but the client will not supply <br> > it and the server needs to then conclude the authentication by <br> > placing the client on an emergency VLAN. <br> </font></tt> <br><tt><font size=2>That's fine _if_ your network supports such a mechanism.</font></tt> <br> <br><tt><font size=2>None of the network technologies I ever ran did.</font></tt> <br> <br><tt><font size=2>All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this.</font></tt> <br> <br><tt><font size=2>Ray</font></tt> <br> --=_alternative 001BBC5C49257669_=-- From dirk.kroeselberg@nsn.com Sun Nov 8 21:31:21 2009 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D395A3A6AE0 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9hAXC4Q2Zeo for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:31:20 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 175323A6AE3 for <ecrit@ietf.org>; Sun, 8 Nov 2009 21:31:19 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA95Vfpi017488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 06:31:41 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA95Vf9B020462; Mon, 9 Nov 2009 06:31:41 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:31:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA60FD.EA24F33B" Date: Mon, 9 Nov 2009 06:31:39 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> In-Reply-To: <OF90CBDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nominet.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclA References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu><OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk><564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk><BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> <OF90CBDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nominet.org.uk> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: <Ray.Bellis@nominet.org.uk>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 09 Nov 2009 05:31:41.0161 (UTC) FILETIME=[EA8D6D90:01CA60FD] Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 05:31:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA60FD.EA24F33B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ray,=20 =20 what you are saying in your earlier e-mail is true for the UK, but not for other countries. Currently there is support for 'SIM-less' calls in cellular networks (enabled based on a per-country policy). You need to support this in some regions like North-America. I would say that obvious candidates include wireless access in regulated spectrum. For fixed-line, this is not a big deal as usually there is no 'unauthenticated' case. =20 Dirk ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Ray.Bellis@nominet.org.uk Sent: Monday, November 09, 2009 6:03 AM To: Bernard Aboba Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =09 =09 > Why? Existing authentication mechanisms (such as EAP-TLS,=20 > described in RFC 5216) already support client unauthenticated=20 > access. All that is necessary is for the client to send an=20 > emergency NAI to signal the need for emergency access. The server=20 > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the=20 > emergency NAI, or it can ask for it, but the client will not supply=20 > it and the server needs to then conclude the authentication by > placing the client on an emergency VLAN.=20 =09 That's fine _if_ your network supports such a mechanism.=20 =09 None of the network technologies I ever ran did.=20 =09 All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this.=20 =09 Ray=20 =09 ------_=_NextPart_001_01CA60FD.EA24F33B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3627" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>Ray,=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>what=20 you are saying in your earlier e-mail is true for the UK, but not for = other=20 countries. Currently there is support for 'SIM-less' calls in cellular = networks=20 (enabled based on a per-country policy). You need to support = this in=20 some regions like North-America. I would say that obvious = candidates=20 include wireless access in regulated spectrum.</FONT></SPAN></DIV> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>For=20 fixed-line, this is not a big deal as usually there is no = 'unauthenticated'=20 case.</FONT></SPAN></DIV> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D662382405-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>Dirk</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] <B>On Behalf Of </B>ext=20 Ray.Bellis@nominet.org.uk<BR><B>Sent:</B> Monday, November 09, 2009 = 6:03=20 AM<BR><B>To:</B> Bernard Aboba<BR><B>Cc:</B> = 'ECRIT'<BR><B>Subject:</B> Re:=20 [Ecrit] Fwd: Comments on = draft-schulzrinne-ecrit-unauthenticated-access-03 -=20 Section 1<BR></FONT><BR></DIV> <DIV></DIV><TT><FONT size=3D2>> Why?   Existing authentication = mechanisms (such as EAP-TLS, <BR>> described in RFC 5216) already = support=20 client unauthenticated <BR>> access.  All that is necessary is = for the=20 client to send an <BR>> emergency NAI to signal the need for = emergency=20 access.  The server <BR>> will still send its certificate = which the=20 client should verify.  The<BR>> server can either not request = the=20 client certificate based on the <BR>> emergency NAI, or it can ask = for it,=20 but the client will not supply <BR>> it and the server needs to = then=20 conclude the authentication by <BR>> placing the client on an = emergency=20 VLAN. <BR></FONT></TT><BR><TT><FONT size=3D2>That's fine _if_ your = network=20 supports such a mechanism.</FONT></TT> <BR><BR><TT><FONT size=3D2>None = of the=20 network technologies I ever ran did.</FONT></TT> <BR><BR><TT><FONT = size=3D2>All=20 I'm saying is the draft needs to be much clearer (IMHO) about what = sorts of=20 access network technologies _might_ be able to support = this.</FONT></TT>=20 <BR><BR><TT><FONT size=3D2>Ray</FONT></TT> = <BR></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CA60FD.EA24F33B-- From dirk.kroeselberg@nsn.com Sun Nov 8 21:40:06 2009 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4D13A6820 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpdk0m8H-ueR for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:40:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 206F03A68C4 for <ecrit@ietf.org>; Sun, 8 Nov 2009 21:40:00 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA95eEvj029826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 06:40:14 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA95eEbA018634; Mon, 9 Nov 2009 06:40:14 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:40:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA60FF.1C165570" Date: Mon, 9 Nov 2009 06:40:12 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701F3279B@DEMUEXC030.nsn-intra.net> In-Reply-To: <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Commentson draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg8o0nLjnjoq4rTzirtDkmY4C3TQABJzRgAAHl83A= References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu> <OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk> <564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu><OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk> <BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Bernard Aboba" <bernard_aboba@hotmail.com>, <Ray.Bellis@nominet.org.uk>, "Henning Schulzrinne" <hgs@cs.columbia.edu> X-OriginalArrivalTime: 09 Nov 2009 05:40:14.0554 (UTC) FILETIME=[1C8EFBA0:01CA60FF] Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Commentson draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 05:40:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA60FF.1C165570 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable right, this is described as one of the possible options in the new section 6 in the unauthenticated draft. It probably needs some refinement, so please take a look and let us know what should be added or modified. =20 Dirk ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: Monday, November 09, 2009 5:47 AM To: Ray.Bellis@nominet.org.uk; 'Henning Schulzrinne' Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Commentson draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =09 =09 Ray Bellis said: =20 "However if the authentication happens at much lower levels then (IMHO) it will be _very_ difficult to support unauthenticated access. " =20 Why? Existing authentication mechanisms (such as EAP-TLS, described in RFC 5216) already support client unauthenticated access. All that is necessary is for the client to send an emergency NAI to signal the need for emergency access. The server will still send its certificate which the client should verify. The server can either not request the client certificate based on the emergency NAI, or it can ask for it, but the client will not supply it and the server needs to then conclude the authentication by placing the client on an emergency VLAN.=20 ------_=_NextPart_001_01CA60FF.1C165570 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:m =3D=20 "http://schemas.microsoft.com/office/2004/12/omml"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3627" name=3DGENERATOR> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } TT { FONT-FAMILY: "Courier New"; mso-style-priority: 99 } SPAN.EmailStyle18 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal-reply } .MsoChpDefault { mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV><SPAN class=3D321423705-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>right,=20 this is described as one of the possible options in the new section 6 in = the=20 unauthenticated draft. It probably needs some refinement, so please take = a look=20 and let us know what should be added or modified.</FONT></SPAN></DIV> <DIV><SPAN class=3D321423705-09112009><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D321423705-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>Dirk</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] <B>On Behalf Of </B>ext Bernard=20 Aboba<BR><B>Sent:</B> Monday, November 09, 2009 5:47 AM<BR><B>To:</B>=20 Ray.Bellis@nominet.org.uk; 'Henning Schulzrinne'<BR><B>Cc:</B>=20 'ECRIT'<BR><B>Subject:</B> Re: [Ecrit] Fwd: Commentson=20 draft-schulzrinne-ecrit-unauthenticated-access-03 - Section=20 1<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #1f497d; FONT-FAMILY: = 'Tahoma','sans-serif'">Ray=20 Bellis said:<o:p></o:p></SPAN></B></P> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #1f497d; FONT-FAMILY: = 'Tahoma','sans-serif'"><o:p> </o:p></SPAN></B></P> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #1f497d; FONT-FAMILY: = 'Tahoma','sans-serif'">“</SPAN></B><TT><SPAN=20 style=3D"FONT-SIZE: 10pt">However if the authentication happens at = much lower=20 levels then (IMHO) it will be _very_ difficult to support = unauthenticated=20 access.</SPAN></TT> <SPAN style=3D"COLOR: = #1f497d">“<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN style=3D"COLOR: = #1f497d"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Why? =   Existing=20 authentication mechanisms (such as EAP-TLS, described in RFC 5216) = already=20 support client unauthenticated access.  All that is necessary is = for the=20 client to send an emergency NAI to signal the need for emergency = access. =20 The server will still send its certificate which the client should=20 verify.  The server can either not request the client certificate = based=20 on the emergency NAI, or it can ask for it, but the client will not = supply it=20 and the server needs to then conclude the authentication by placing = the client=20 on an emergency VLAN. = </SPAN><o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CA60FF.1C165570-- From James.Winterbottom@andrew.com Sun Nov 8 21:52:48 2009 Return-Path: <James.Winterbottom@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF103A68FA for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoGuGbmGQ+LX for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 21:52:47 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 403073A68CB for <ecrit@ietf.org>; Sun, 8 Nov 2009 21:52:47 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:41326 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S68075AbZKIFxN (ORCPT <rfc822;ecrit@ietf.org>); Sun, 8 Nov 2009 23:53:13 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 8 Nov 2009 23:53:13 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 9 Nov 2009 13:52:40 +0800 From: "Winterbottom, James" <James.Winterbottom@andrew.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.org.uk>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Mon, 9 Nov 2009 13:52:38 +0800 Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAAAD2kBA= Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31@SISPE7MB1.commscope.com> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu><OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk><564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk><BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl> <OF90CBDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nominet.org.uk> <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31SISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 05:52:48 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to be clear, we are talking about unauthenticated to the access networ= k. Right? ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of K= roeselberg, Dirk (NSN - DE/Munich) Sent: Monday, 9 November 2009 4:32 PM To: Ray.Bellis@nominet.org.uk; Bernard Aboba Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticat= ed-access-03 - Section 1 Ray, what you are saying in your earlier e-mail is true for the UK, but not for = other countries. Currently there is support for 'SIM-less' calls in cellula= r networks (enabled based on a per-country policy). You need to support thi= s in some regions like North-America. I would say that obvious candidates i= nclude wireless access in regulated spectrum. For fixed-line, this is not a big deal as usually there is no 'unauthentica= ted' case. Dirk ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Ray.Bellis@nominet.org.uk Sent: Monday, November 09, 2009 6:03 AM To: Bernard Aboba Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticat= ed-access-03 - Section 1 > Why? Existing authentication mechanisms (such as EAP-TLS, > described in RFC 5216) already support client unauthenticated > access. All that is necessary is for the client to send an > emergency NAI to signal the need for emergency access. The server > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the > emergency NAI, or it can ask for it, but the client will not supply > it and the server needs to then conclude the authentication by > placing the client on an emergency VLAN. That's fine _if_ your network supports such a mechanism. None of the network technologies I ever ran did. All I'm saying is the draft needs to be much clearer (IMHO) about what sort= s of access network technologies _might_ be able to support this. Ray --_000_5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"countr= y-region"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} tt {font-family:"Courier New";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-AU link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Just to be clear, we are talking about unauthenticated to the access network. Right?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa= mily:Tahoma'> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Kroeselberg, Dirk (NSN - DE/Munich)<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, 9 November 200= 9 4:32 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Ray.Bellis@nominet.org.u= k; Bernard Aboba<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> ECRIT<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Ecrit] Fwd: Co= mments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1</span></fo= nt><span lang=3DEN-US><o:p></o:p></span></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:blue'>Ray, </span></font><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:blue'>what you are saying in your earlier e-= mail is true for the <st1:country-region w:st=3D"on"><st1:place w:st=3D"on">UK</= st1:place></st1:country-region>, but not for other countries. Currently there is support for 'SIM-less' call= s in cellular networks (enabled based on a per-country policy). You need to support this in some regions like North-America. I would say that obvious candidates include wireless access in regulated spectrum.</span></f= ont><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:blue'>For fixed-line, this is not a big deal= as usually there is no 'unauthenticated' case.</span></font><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:blue'>Dirk</span></font><o:p></o:p></p> </div> <blockquote style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0= cm 0cm 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span lang=3DDE style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> </span></font></div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face= =3DTahoma><span lang=3DDE style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>Fr= om:</span></font></b><font size=3D2 face=3DTahoma><span lang=3DDE style=3D'font-size:10.0pt;font-famil= y:Tahoma'> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>ext Ray.Bellis@nominet.o= rg.uk<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, November 09, 2= 009 6:03 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Bernard Aboba<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> 'ECRIT'<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Ecrit] Fwd: Co= mments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1</span></fo= nt><span lang=3DDE><o:p></o:p></span></p> <p class=3DMsoNormal><tt><font size=3D2 face=3D"Courier New"><span style=3D= 'font-size: 10.0pt'>> Why?   Existing authentication mechanisms (such as EAP-TL= S, </span></font></tt><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"= Courier New"'><br> <tt><font face=3D"Courier New">> described in RFC 5216) already support = client unauthenticated </font></tt><br> <tt><font face=3D"Courier New">> access.  All that is necessary is = for the client to send an </font></tt><br> <tt><font face=3D"Courier New">> emergency NAI to signal the need for em= ergency access.  The server </font></tt><br> <tt><font face=3D"Courier New">> will still send its certificate which t= he client should verify.  The</font></tt><br> <tt><font face=3D"Courier New">> server can either not request the clien= t certificate based on the </font></tt><br> <tt><font face=3D"Courier New">> emergency NAI, or it can ask for it, bu= t the client will not supply </font></tt><br> <tt><font face=3D"Courier New">> it and the server needs to then conclud= e the authentication by </font></tt><br> <tt><font face=3D"Courier New">> placing the client on an emergency VLAN= . </font></tt><br> </span></font><br> <tt><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Th= at's fine _if_ your network supports such a mechanism.</span></font></tt> <br> <br> <tt><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>No= ne of the network technologies I ever ran did.</span></font></tt> <br> <br> <tt><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Al= l I'm saying is the draft needs to be much clearer (IMHO) about what sorts of acc= ess network technologies _might_ be able to support this.</span></font></tt> <b= r> <br> <tt><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Ra= y</span></font></tt> <o:p></o:p></p> </blockquote> </div> </div> </body> </html> --_000_5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31SISPE7MB1co_-- From MILANPA@nortel.com Sun Nov 8 22:12:51 2009 Return-Path: <MILANPA@nortel.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4944D3A6974 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 22:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-90IDfLZduw for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 22:12:49 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5F1063A69D0 for <ecrit@ietf.org>; Sun, 8 Nov 2009 22:12:49 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nA96D6H23942; Mon, 9 Nov 2009 06:13:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 06:13:02 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900B34C344@zharhxm1.corp.nortel.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092E5E40@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New Version Notificationfor draft-patel-ecrit-sos-parameter-07 Thread-Index: AcpgA00uz26Tfj7RS+WQ2WAdnw/ljwA8VYnQAAOgyfA= References: <0913B6CD18F370498CD65864CF254E900B1CA59D@zharhxm1.corp.nortel.com><47ED2AE6-6BD2-40AD-9E9F-B97A60538F4B@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2092E5E40@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Milan Patel" <milanpa@nortel.com> To: "Cullen Jennings" <fluffy@cisco.com>, "ECRIT" <ecrit@ietf.org> Cc: Hannes Tschofenig <hannes.tschofenig@nsn.com> Subject: Re: [Ecrit] New Version Notificationfor draft-patel-ecrit-sos-parameter-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 06:12:51 -0000 Hi Cullen, Keith,=20 Note, this discussion has occurred before in the past and we considered that that option tags were not necessary.=20 My understanding (and may be the draft is misleading but I don't think so) is that the UA doesn't need to know that the network supports the extension. It adds the "reg-type" in the REGISTER and if supported by the registrar, the registrar will successfully register even in the case the identities are barred, for example. In the case the registrar does not understand the parameter, there is a chance the registration fails, but in the case it is successful, the same 200 is returned to the UA.=20 The UA uses this contact (returned in the 200 to the RGISTER) in the emergency INVITE, but from a UA point of view, there is not special reason for the UA to interpret the value. Legacy registrars would indeed just copy the URI parameter to the 200 (OK) so the draft needs updating for that. Cheers, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 09 November 2009 04:27 To: Cullen Jennings; ECRIT Cc: Hannes Tschofenig Subject: Re: [Ecrit] New Version Notificationfor draft-patel-ecrit-sos-parameter-07 So just to be clear here. You are presumably proposing an option tag in addition to the new URI parameter. Use of the option tag without the parameter would merely confirm that the extension was supported. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Cullen Jennings > Sent: Friday, November 06, 2009 11:05 PM > To: ECRIT > Cc: Hannes Tschofenig > Subject: Re: [Ecrit] New Version Notification for=20 > draft-patel-ecrit-sos-parameter-07 >=20 >=20 > It was pointed out to me that some registrars that do not=20 > support the emergency registration will accept a contact with=20 > the sos parameter and will also return it in the 200. They=20 > just copy the data. Because of this, I don't think that=20 > detecting the parameter in the 200 is a sufficient way for=20 > the UA to know the registrar supports this mechanism. Due to=20 > it's importance for emergency calls, this seems like a real problem. >=20 > My recommended fix to this would be to add a=20 > required/supported option tag. I realize this is not great=20 > news to many of the folks involved but from what I have=20 > heard, this does sounds like a problem. Glad to hear any=20 > ideas on how to get a solutions published quickly that meets=20 > 3GPPs requirements. >=20 > Cullen <with my AD hat on> >=20 >=20 > On Oct 27, 2009, at 7:14 , Milan Patel wrote: >=20 > > Hi Cullen, > > > > I have submitted a new version of draft-patel-ecrit-sos-parameter > > > > Latest changes are: > > - clarification of use > > - change of URI parameter name to "reg-type" which can have a value > > - specifically for 3GPP's IMS emergency services solution,=20 > "reg-type" > > takes the value "sos". > > > > - the URI parameter is extensible to allow other values to=20 > be used in=20 > > the future for other use cases where the registration type=20 > needs to be=20 > > explicitly identified to the registrar. > > > > I hope this helps in addressing the concerns that you and=20 > others had=20 > > about the previous version. > > Due to the 3GPP release 7 dependency on this draft, I hope we can=20 > > reach consensus on this draft as soon as possible. > > > > Best regards, > > Milan > > > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 26 October 2009 22:04 > > To: Patel, Milan (MOP:EP10) > > Subject: New Version Notification for draft-patel-ecrit-sos- > > parameter-07 > > > > > > > > A new version of I-D,=20 > draft-patel-ecrit-sos-parameter-07.txt has been=20 > > successfuly submitted by Milan Patel and posted to the IETF=20 > > repository. > > > > Filename: draft-patel-ecrit-sos-parameter > > Revision: 07 > > Title: SOS Uniform Resource Identifier (URI)=20 > Parameter for > > Marking of Session Initiation Protocol (SIP) Requests related to=20 > > Emergency Services > > Creation_date: 2009-10-26 > > WG ID: Independent Submission > > Number_of_pages: 8 > > > > Abstract: > > This document defines a new Session Initiation Protocol=20 > (SIP) Uniform=20 > > Resource Identifier (URI) parameter intended for marking SIP=20 > > registration requests related to emergency services. The URI=20 > > parameter is extensible to allow future values to be defined if=20 > > required by other use cases that require specific SIP=20 > registrations to=20 > > be distinctly identified. The usage of this new URI parameter=20 > > complements the usage of the Service Uniform Resource Name=20 > (URN) and=20 > > is not intended to replace it. > > > > > > > > > > The IETF Secretariat. > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From dirk.kroeselberg@nsn.com Sun Nov 8 22:47:35 2009 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7484F3A6AE3 for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 22:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOdjRsNk4tZb for <ecrit@core3.amsl.com>; Sun, 8 Nov 2009 22:47:34 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 67BA828C0DF for <ecrit@ietf.org>; Sun, 8 Nov 2009 22:47:33 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA96llSE020374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 07:47:47 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA96ljZQ031448; Mon, 9 Nov 2009 07:47:47 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:47:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6108.8B553484" Date: Mon, 9 Nov 2009 07:47:43 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701F327BB@DEMUEXC030.nsn-intra.net> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Comments ondraft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAAAD2kBAAAeQyIA== References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu><6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu><OFD44F2219.8D2A5E10-ON80257669.000DBA41-49257669.000F70FB@nominet.org.uk><564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu><OF12C6D6D0.0A6DC1BC-ON80257669.0016A39F-49257669.0016E737@nominet.org.uk><BLU137-DS73B3D446E7634C650E81293AC0@phx.gbl><OF90CBDE2A.36999036-ON80257669.001B8469-49257669.001BBC5E@nominet.org.uk> <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Winterbottom, James" <James.Winterbottom@andrew.com>, <Ray.Bellis@nominet.org.uk>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 09 Nov 2009 06:47:46.0810 (UTC) FILETIME=[8BE42DA0:01CA6108] Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments ondraft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 06:47:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6108.8B553484 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable yes (at least for my part). =20 Dirk ________________________________ From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Monday, November 09, 2009 6:53 AM To: Kroeselberg, Dirk (NSN - DE/Munich); Ray.Bellis@nominet.org.uk; Bernard Aboba Cc: ECRIT Subject: RE: [Ecrit] Fwd: Comments ondraft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =09 =09 Just to be clear, we are talking about unauthenticated to the access network. Right? =20 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) Sent: Monday, 9 November 2009 4:32 PM To: Ray.Bellis@nominet.org.uk; Bernard Aboba Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =20 Ray,=20 =20 what you are saying in your earlier e-mail is true for the UK, but not for other countries. Currently there is support for 'SIM-less' calls in cellular networks (enabled based on a per-country policy). You need to support this in some regions like North-America. I would say that obvious candidates include wireless access in regulated spectrum. For fixed-line, this is not a big deal as usually there is no 'unauthenticated' case. =20 Dirk =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Ray.Bellis@nominet.org.uk Sent: Monday, November 09, 2009 6:03 AM To: Bernard Aboba Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 > Why? Existing authentication mechanisms (such as EAP-TLS,=20 > described in RFC 5216) already support client unauthenticated=20 > access. All that is necessary is for the client to send an=20 > emergency NAI to signal the need for emergency access. The server=20 > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the=20 > emergency NAI, or it can ask for it, but the client will not supply=20 > it and the server needs to then conclude the authentication by=20 > placing the client on an emergency VLAN.=20 =09 That's fine _if_ your network supports such a mechanism. =09 None of the network technologies I ever ran did.=20 =09 All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this.=20 =09 Ray=20 ------_=_NextPart_001_01CA6108.8B553484 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3627" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--><o:SmartTagType name=3D"country-region"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><!--[if !mso]> <STYLE>st1\:* { BEHAVIOR: url(#default#ieooui) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt = 90.0pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } TT { FONT-FAMILY: "Courier New" } SPAN.EmailStyle18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-AU vLink=3Dpurple link=3Dblue> <DIV><SPAN class=3D687224606-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>yes=20 (at least for my part).</FONT></SPAN></DIV> <DIV><SPAN class=3D687224606-09112009><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D687224606-09112009><FONT face=3DArial color=3D#0000ff = size=3D2>Dirk</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ext Winterbottom, James=20 [mailto:James.Winterbottom@andrew.com] <BR><B>Sent:</B> Monday, = November 09,=20 2009 6:53 AM<BR><B>To:</B> Kroeselberg, Dirk (NSN - DE/Munich);=20 Ray.Bellis@nominet.org.uk; Bernard Aboba<BR><B>Cc:</B>=20 ECRIT<BR><B>Subject:</B> RE: [Ecrit] Fwd: Comments=20 ondraft-schulzrinne-ecrit-unauthenticated-access-03 - Section=20 1<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Just to be = clear, we=20 are talking about unauthenticated to the access network.=20 Right?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue = 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none"> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US = style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: = bold">On Behalf=20 Of </SPAN></B>Kroeselberg, Dirk (NSN - DE/Munich)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, 9 November 2009 = 4:32=20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20 Ray.Bellis@nominet.org.uk; Bernard Aboba<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> ECRIT<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Ecrit] Fwd: = Comments on=20 draft-schulzrinne-ecrit-unauthenticated-access-03 - Section=20 1</SPAN></FONT><SPAN lang=3DEN-US><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Ray,=20 </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">what you = are saying=20 in your earlier e-mail is true for the <st1:country-region=20 w:st=3D"on"><st1:place = w:st=3D"on">UK</st1:place></st1:country-region>, but not=20 for other countries. Currently there is support for 'SIM-less' calls = in=20 cellular networks (enabled based on a per-country policy). You = need to=20 support this in some regions like North-America. I would say = that=20 obvious candidates include wireless access in regulated=20 spectrum.</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">For = fixed-line, this=20 is not a big deal as usually there is no 'unauthenticated'=20 case.</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial">Dirk</SPAN></FONT><o:p></o:p></P></DIV> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt = 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: = medium none"> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DDE = style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT = face=3DTahoma=20 size=3D2><SPAN lang=3DDE=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DDE=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: = bold">On Behalf=20 Of </SPAN></B>ext Ray.Bellis@nominet.org.uk<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, November 09, = 2009 6:03=20 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Bernard=20 Aboba<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20 'ECRIT'<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> = Re:=20 [Ecrit] Fwd: Comments on = draft-schulzrinne-ecrit-unauthenticated-access-03 -=20 Section 1</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P> <P class=3DMsoNormal><TT><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> Why?   Existing authentication = mechanisms=20 (such as EAP-TLS, </SPAN></FONT></TT><FONT face=3D"Courier New" = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR><TT><FONT=20 face=3D"Courier New">> described in RFC 5216) already support = client=20 unauthenticated </FONT></TT><BR><TT><FONT face=3D"Courier New">> = access.=20  All that is necessary is for the client to send an=20 </FONT></TT><BR><TT><FONT face=3D"Courier New">> emergency NAI to = signal=20 the need for emergency access.  The server = </FONT></TT><BR><TT><FONT=20 face=3D"Courier New">> will still send its certificate which the = client=20 should verify.  The</FONT></TT><BR><TT><FONT face=3D"Courier = New">>=20 server can either not request the client certificate based on the=20 </FONT></TT><BR><TT><FONT face=3D"Courier New">> emergency NAI, = or it can=20 ask for it, but the client will not supply </FONT></TT><BR><TT><FONT = face=3D"Courier New">> it and the server needs to then conclude = the=20 authentication by </FONT></TT><BR><TT><FONT face=3D"Courier = New">> placing=20 the client on an emergency VLAN. = </FONT></TT><BR></SPAN></FONT><BR><TT><FONT=20 face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">That's = fine _if_=20 your network supports such a mechanism.</SPAN></FONT></TT> = <BR><BR><TT><FONT=20 face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">None = of the network=20 technologies I ever ran did.</SPAN></FONT></TT> <BR><BR><TT><FONT=20 face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">All = I'm saying is=20 the draft needs to be much clearer (IMHO) about what sorts of access = network=20 technologies _might_ be able to support this.</SPAN></FONT></TT>=20 <BR><BR><TT><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">Ray</SPAN></FONT></TT>=20 <o:p></o:p></P></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CA6108.8B553484-- From root@core3.amsl.com Mon Nov 9 01:30:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 49DE23A692B; Mon, 9 Nov 2009 01:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109093002.49DE23A692B@core3.amsl.com> Date: Mon, 9 Nov 2009 01:30:02 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 09:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary Author(s) : K. Wolf Filename : draft-ietf-ecrit-lost-servicelistboundary-01.txt Pages : 13 Date : 2009-11-09 LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary to assist the client to not miss a change in available services when moving. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboundary-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-servicelistboundary-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-09012552.I-D@ietf.org> --NextPart-- From khwolf1@gmail.com Mon Nov 9 01:33:47 2009 Return-Path: <khwolf1@gmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52EC3A68FF for <ecrit@core3.amsl.com>; Mon, 9 Nov 2009 01:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-w-TYPomGtO for <ecrit@core3.amsl.com>; Mon, 9 Nov 2009 01:33:47 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id F409B3A6783 for <ecrit@ietf.org>; Mon, 9 Nov 2009 01:33:46 -0800 (PST) Received: by pwi6 with SMTP id 6so231459pwi.29 for <ecrit@ietf.org>; Mon, 09 Nov 2009 01:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=M8AQAVOgpYDlDQyWmYdGzWY045tZM4QgFk1/WtwqFjM=; b=WgknGupTwcReTreLU9l3vmzBlqCmbUUmuKt6BDCb/9lvAOBSSEs3Iz7kZn4voQXhGV HxyF6KN1VyEjtlNhClIhiWoeiqFUPpwJiEWyHVkdY+fRkHbmpY0vj+ZjMxpVyr+XsUrA WEXBV+wYfEwbt5mh4LoevrwPz/a42eQf2OoBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=B82ixlXfrYuiabW0b9T8miq7YscPAmz0yDuf+g6qob104+cC8Wsbz6Q+d9OXSGyg4C RLE8ez9aHXFRKxxH+KLpzInmU7mAyj0Ke4YTMoVLDij3nck5lT/VCHjrHomBhIx3/jW6 l6fgV525fp1zWd+NyXgWqZjKZB9ZYTdBpP5i0= MIME-Version: 1.0 Received: by 10.140.132.18 with SMTP id f18mr118416rvd.173.1257759250756; Mon, 09 Nov 2009 01:34:10 -0800 (PST) In-Reply-To: <20091109093002.49DE23A692B@core3.amsl.com> References: <20091109093002.49DE23A692B@core3.amsl.com> Date: Mon, 9 Nov 2009 10:34:10 +0100 Message-ID: <f77644530911090134k1c8e11e1o7b5f33d0ba7af710@mail.gmail.com> From: Karl Heinz Wolf <khwolf1@gmail.com> To: ECRIT <ecrit@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 09:33:48 -0000 I just posed a new version of the draft now including the IANA consideratio= ns. Comments and feedback welcome. karl heinz On Mon, Nov 9, 2009 at 10:30 AM, <Internet-Drafts@ietf.org> wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Location-to-Service Translatio= n Protocol (LoST) Extension: ServiceListBoundary > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : K. Wolf > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ecrit-lost-servicelis= tboundary-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-11-09 > > LoST maps service identifiers and location information to service > contact URIs. =A0If a LoST client wants to discover available services > for a particular location, it will perform a <listServicesByLocation> > query to the LoST server. =A0However, the response from the LoST server > does not provide information about the geographical region for which > the returned service list is valid. =A0Therefore, this document > proposes a ServiceListBoundary to assist the client to not miss a > change in available services when moving. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. =A0Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. =A0It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 13, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. =A0All rights reserved. > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. =A0Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. =A0Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboun= dary-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From mlinsner@cisco.com Mon Nov 9 05:15:15 2009 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE163A6B41 for <ecrit@core3.amsl.com>; Mon, 9 Nov 2009 05:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.671 X-Spam-Level: X-Spam-Status: No, score=-5.671 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB3dbZbuHzfs for <ecrit@core3.amsl.com>; Mon, 9 Nov 2009 05:15:14 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3920B3A6B03 for <ecrit@ietf.org>; Mon, 9 Nov 2009 05:15:14 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAKKk90pAZnwN/2dsb2JhbACCIy6XcasSllOCR4F3BA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="67076329" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 13:15:39 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9DFdbZ001505; Mon, 9 Nov 2009 13:15:39 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:15:39 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:15:38 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 09 Nov 2009 08:15:35 -0500 From: Marc Linsner <mlinsner@cisco.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>, <Ray.Bellis@nominet.org.uk>, Bernard Aboba <bernard_aboba@hotmail.com> Message-ID: <C71D8027.1D381%mlinsner@cisco.com> Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAABByh30= In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340599338_63415" X-OriginalArrivalTime: 09 Nov 2009 13:15:39.0146 (UTC) FILETIME=[BB48D6A0:01CA613E] Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Nov 2009 13:15:15 -0000 > 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. --B_3340599338_63415 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dirk, Are there regulations that call for unauthenticated clients to have emergency access in the Internet realm? Or is this an assumption of something in the future? -Marc- On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> wrote: > Ray, > > what you are saying in your earlier e-mail is true for the UK, but not for > other countries. Currently there is support for 'SIM-less' calls in cellular > networks (enabled based on a per-country policy). You need to support this in > some regions like North-America. I would say that obvious candidates include > wireless access in regulated spectrum. > For fixed-line, this is not a big deal as usually there is no > 'unauthenticated' case. > > Dirk > >> >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> ext Ray.Bellis@nominet.org.uk >> Sent: Monday, November 09, 2009 6:03 AM >> To: Bernard Aboba >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Fwd: Comments on >> draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 >> >> >>> > Why? Existing authentication mechanisms (such as EAP-TLS, >>> > described in RFC 5216) already support client unauthenticated >>> > access. All that is necessary is for the client to send an >>> > emergency NAI to signal the need for emergency access. The server >>> > will still send its certificate which the client should verify. The >>> > server can either not request the client certificate based on the >>> > emergency NAI, or it can ask for it, but the client will not supply >>> > it and the server needs to then conclude the authentication by >>> > placing the client on an emergency VLAN. >> >> That's fine _if_ your network supports such a mechanism. >> >> None of the network technologies I ever ran did. >> >> All I'm saying is the draft needs to be much clearer (IMHO) about what sorts >> of access network technologies _might_ be able to support this. >> >> Ray > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --B_3340599338_63415 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated= -access-03 - Section 1 Dirk,

Are there regulations that call for unauthenticated clients to have emergen= cy access in the Internet realm?  Or is this an assumption of something= in the future?

-Marc-


On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> wrote:

Ray,

what you are saying in your= earlier e-mail is true for the UK, but not for other countries. Currently t= here is support for 'SIM-less' calls in cellular networks (enabled based on = a per-country policy). You need to support this in some regions like North-A= merica. I would say that obvious candidates include wireless access in regul= ated spectrum.
For fixed-line, this is not a big deal as usually there is no 'unauthentica= ted' case.
Dirk


 
From: ecrit-bounc= es@ietf.org  [mailto:ecrit-= bounces@ietf.org] On Behalf Of ext  Ray.Bellis@nominet.org.uk
Sent: Monday, November 09, 2009 6:03  AM
To: Bernard Aboba
Cc: 'ECRIT'
Subject: Re:  [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-= unauthenticated-access-03 -  Section 1

 
> Why?   Ex= isting authentication  mechanisms (such as EAP-TLS,
> described in RFC 5216) already support  client unauthenticated > access.  All that is necessary is for the  client to send an=
> emergency NAI to signal the need for emergency  access.  The= server
> will still send its certificate which the  client should verify. =  The
> server can either not request the  client certificate based on th= e
> emergency NAI, or it can ask for it,  but the client will not sup= ply
> it and the server needs to then  conclude the authentication by <= BR> > placing the client on an emergency  VLAN.

That's fine _if_ your ne= twork  supports such a mechanism.

None of the  networ= k technologies I ever ran did.

All  I'm saying is = the draft needs to be much clearer (IMHO) about what sorts of  access n= etwork technologies _might_ be able to support this.  

Ray

___________= ____________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit
--B_3340599338_63415-- From hgs@cs.columbia.edu Mon Nov 9 05:26:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE783A68C3 for ; Mon, 9 Nov 2009 05:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.578 X-Spam-Level: X-Spam-Status: No, score=-4.578 tagged_above=-999 required=5 tests=[AWL=-1.979, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQzpA8CydDhg for ; Mon, 9 Nov 2009 05:26:55 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id B779F3A6860 for ; Mon, 9 Nov 2009 05:26:55 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA9DRI0o020272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2009 08:27:18 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: Date: Mon, 9 Nov 2009 08:27:18 -0500 Content-Transfer-Encoding: 7bit Message-Id: <115728BF-E648-481F-9250-22CBF6F6CA32@cs.columbia.edu> References: To: Marc Linsner X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Cc: Ray.Bellis@nominet.org.uk, ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:26:56 -0000 Given that there are currently likely no regulations for Internet emergency calling (beyond the "must provide equivalent service ones"), I suspect that asking this question is not too helpful. I would consider this anticipating and exploring the issue - namely, whether it is feasible to do this if so desired. We have the moral equivalent, such as US landlines that have been shut off for non-payment, but can still be used to place emergency calls, in addition to payphones that provide free emergency calls. If I were a hotel or airport operator, I'd want to provide such functionality - after all, I'd kind of like the local fire and police department to know about the smoke or suspicious package that a visitor is seeing. Henning On Nov 9, 2009, at 8:15 AM, Marc Linsner wrote: > Dirk, > > Are there regulations that call for unauthenticated clients to have > emergency access in the Internet realm? Or is this an assumption of > something in the future? > > -Marc- > > > On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" > wrote: > >> Ray, >> >> what you are saying in your earlier e-mail is true for the UK, but >> not for other countries. Currently there is support for 'SIM-less' >> calls in cellular networks (enabled based on a per-country policy). >> You need to support this in some regions like North-America. I >> would say that obvious candidates include wireless access in >> regulated spectrum. >> For fixed-line, this is not a big deal as usually there is no >> 'unauthenticated' case. >> >> Dirk >> >>> >>> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of ext Ray.Bellis@nominet.org.uk >>> Sent: Monday, November 09, 2009 6:03 AM >>> To: Bernard Aboba >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit- >>> unauthenticated-access-03 - Section 1 >>> >>> >>> > Why? Existing authentication mechanisms (such as EAP-TLS, >>> > described in RFC 5216) already support client unauthenticated >>> > access. All that is necessary is for the client to send an >>> > emergency NAI to signal the need for emergency access. The >>> server >>> > will still send its certificate which the client should >>> verify. The >>> > server can either not request the client certificate based on the >>> > emergency NAI, or it can ask for it, but the client will not >>> supply >>> > it and the server needs to then conclude the authentication by >>> > placing the client on an emergency VLAN. >>> >>> That's fine _if_ your network supports such a mechanism. >>> >>> None of the network technologies I ever ran did. >>> >>> All I'm saying is the draft needs to be much clearer (IMHO) about >>> what sorts of access network technologies _might_ be able to >>> support this. >>> >>> Ray >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Mon Nov 9 05:27:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FE23A6894 for ; Mon, 9 Nov 2009 05:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[AWL=-1.731, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdRNC102MiPN for ; Mon, 9 Nov 2009 05:27:44 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id CD3403A6860 for ; Mon, 9 Nov 2009 05:27:44 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA9DRI0p020272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2009 08:28:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31@SISPE7MB1.commscope.com> Date: Mon, 9 Nov 2009 08:28:08 -0500 Content-Transfer-Encoding: 7bit Message-Id: <57EDC028-6586-4AD4-BDFE-40D3871B5587@cs.columbia.edu> References: <15F9ABA8-B0D3-4F7F-BD8C-28A6B8A40A4D@cs.columbia.edu> <6E230B52-2340-43F7-9EF0-16912DC307E8@cs.columbia.edu><564BBE0C-AEBD-428F-9597-C56F3934678A@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA2C31@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Cc: "Ray.Bellis@nominet.org.uk" , ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:27:45 -0000 On Nov 9, 2009, at 12:52 AM, Winterbottom, James wrote: > Just to be clear, we are talking about unauthenticated to the access > network. Right? > Yes, although the document, predating "direct", also mentions the other cases. From br@brianrosen.net Mon Nov 9 05:33:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004F43A6B5C for ; Mon, 9 Nov 2009 05:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KFnP7XAlPlY for ; Mon, 9 Nov 2009 05:33:33 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 397F728B23E for ; Mon, 9 Nov 2009 05:33:33 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7UNQ-0001sr-Dh; Mon, 09 Nov 2009 07:33:48 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 09 Nov 2009 08:33:50 -0400 From: Brian Rosen To: "Kroeselberg, Dirk (NSN - DE/Munich)" , , Bernard Aboba Message-ID: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAABEVsgw= In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340600434_56721713" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:33:37 -0000 > 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. --B_3340600434_56721713 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Although I would note that it=B9s not yet clear how the U.S. Regulator will treat these arrangements. There is significant pressure from the emergenc= y call authorities to NOT support unauthenticated access from broadband networks. However, there are some jurisdictions that I expect will require it, and thus there needs to be some documentation of how to do that in such jurisdictions. As long as the device can tell if it is required or not, we=B9ll be okay. As with =ADdirect, I don=B9t want to encourage such use, but if the local jurisdiction requires it, then we have to do something. I prefer this document over =ADdirect. Brian On 11/9/09 1:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" wrote: > Ray,=20 > =20 > what you are saying in your earlier e-mail is true for the UK, but not fo= r > other countries. Currently there is support for 'SIM-less' calls in cellu= lar > networks (enabled based on a per-country policy). You need to support thi= s in > some regions like North-America. I would say that obvious candidates incl= ude > wireless access in regulated spectrum. > For fixed-line, this is not a big deal as usually there is no > 'unauthenticated' case. > =20 > Dirk >=20 >> =20 >> =20 >>=20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of >> ext Ray.Bellis@nominet.org.uk >> Sent: Monday, November 09, 2009 6:03 AM >> To: Bernard Aboba >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Fwd: Comments on >> draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 >>=20 >> =20 >>> > Why? Existing authentication mechanisms (such as EAP-TLS, >>> > described in RFC 5216) already support client unauthenticated >>> > access. All that is necessary is for the client to send an >>> > emergency NAI to signal the need for emergency access. The server >>> > will still send its certificate which the client should verify. The >>> > server can either not request the client certificate based on the >>> > emergency NAI, or it can ask for it, but the client will not supply >>> > it and the server needs to then conclude the authentication by >>> > placing the client on an emergency VLAN. >>=20 >> That's fine _if_ your network supports such a mechanism. >>=20 >> None of the network technologies I ever ran did. >>=20 >> All I'm saying is the draft needs to be much clearer (IMHO) about what = sorts >> of access network technologies _might_ be able to support this. >>=20 >> Ray=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --B_3340600434_56721713 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated= -access-03 - Section 1 Although I would note that it’s not yet clear how the U.S. Regulator= will treat these arrangements.   There is significant pressure fr= om the emergency call authorities to NOT support unauthenticated access from= broadband networks.

However, there are some jurisdictions that I expect will require it, and th= us there needs to be some documentation of how to do that in such jurisdicti= ons.  As long as the device can tell if it is required or not, we’= ;ll be okay.  As with –direct, I don’t want to encourage su= ch use, but if the local jurisdiction requires it, then we have to do someth= ing.  I prefer this document over –direct.

Brian


On 11/9/09 1:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> wrote:

Ray,

what you are saying in your= earlier e-mail is true for the UK, but not for other countries. Currently t= here is support for 'SIM-less' calls in cellular networks (enabled based on = a per-country policy). You need to support this in some regions like North-A= merica. I would say that obvious candidates include wireless access in regul= ated spectrum.
For fixed-line, this is not a big deal as usually there is no 'unauthentica= ted' case.
Dirk


 
From: ecrit-bounc= es@ietf.org  [mailto:ecrit-= bounces@ietf.org] On Behalf Of ext  Ray.Bellis@nominet.org.uk
Sent: Monday, November 09, 2009 6:03  AM
To: Bernard Aboba
Cc: 'ECRIT'
Subject: Re:  [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-= unauthenticated-access-03 -  Section 1

 
> Why?   Ex= isting authentication  mechanisms (such as EAP-TLS,
> described in RFC 5216) already support  client unauthenticated > access.  All that is necessary is for the  client to send an=
> emergency NAI to signal the need for emergency  access.  The= server
> will still send its certificate which the  client should verify. =  The
> server can either not request the  client certificate based on th= e
> emergency NAI, or it can ask for it,  but the client will not sup= ply
> it and the server needs to then  conclude the authentication by <= BR> > placing the client on an emergency  VLAN.

That's fine _if_ your ne= twork  supports such a mechanism.

None of the  networ= k technologies I ever ran did.

All  I'm saying is = the draft needs to be much clearer (IMHO) about what sorts of  access n= etwork technologies _might_ be able to support this.  

Ray

___________= ____________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit
--B_3340600434_56721713-- From mlinsner@cisco.com Mon Nov 9 05:34:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65E53A67F0 for ; Mon, 9 Nov 2009 05:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC1TRTm6yjfW for ; Mon, 9 Nov 2009 05:34:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B53263A6B56 for ; Mon, 9 Nov 2009 05:34:35 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFOp90pAZnwM/2dsb2JhbADFbZZVgkEGgXcEjAsp X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="67080135" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 13:35:01 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9DZ1FA017118; Mon, 9 Nov 2009 13:35:01 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:35:01 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:35:00 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 09 Nov 2009 08:34:59 -0500 From: Marc Linsner To: Henning Schulzrinne Message-ID: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: AcphQW6cK0uFZdmiwE6ANzRqFMANPg== In-Reply-To: <115728BF-E648-481F-9250-22CBF6F6CA32@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 13:35:01.0059 (UTC) FILETIME=[6FD6B130:01CA6141] Cc: Ray.Bellis@nominet.org.uk, ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:34:47 -0000 Hence, I want the motivation for the work to NOT include 'regulation'. As you describe, the functionality should stand on it's own merits. -Marc- On 11/9/09 8:27 AM, "Henning Schulzrinne" wrote: > Given that there are currently likely no regulations for Internet > emergency calling (beyond the "must provide equivalent service ones"), > I suspect that asking this question is not too helpful. I would > consider this anticipating and exploring the issue - namely, whether > it is feasible to do this if so desired. We have the moral equivalent, > such as US landlines that have been shut off for non-payment, but can > still be used to place emergency calls, in addition to payphones that > provide free emergency calls. > > If I were a hotel or airport operator, I'd want to provide such > functionality - after all, I'd kind of like the local fire and police > department to know about the smoke or suspicious package that a > visitor is seeing. > > Henning > > On Nov 9, 2009, at 8:15 AM, Marc Linsner wrote: > >> Dirk, >> >> Are there regulations that call for unauthenticated clients to have >> emergency access in the Internet realm? Or is this an assumption of >> something in the future? >> >> -Marc- >> >> >> On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" >> >> wrote: >> >>> Ray, >>> >>> what you are saying in your earlier e-mail is true for the UK, but >>> not for other countries. Currently there is support for 'SIM-less' >>> calls in cellular networks (enabled based on a per-country policy). >>> You need to support this in some regions like North-America. I >>> would say that obvious candidates include wireless access in >>> regulated spectrum. >>> For fixed-line, this is not a big deal as usually there is no >>> 'unauthenticated' case. >>> >>> Dirk >>> >>>> >>>> >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of ext Ray.Bellis@nominet.org.uk >>>> Sent: Monday, November 09, 2009 6:03 AM >>>> To: Bernard Aboba >>>> Cc: 'ECRIT' >>>> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit- >>>> unauthenticated-access-03 - Section 1 >>>> >>>> >>>>> Why? Existing authentication mechanisms (such as EAP-TLS, >>>>> described in RFC 5216) already support client unauthenticated >>>>> access. All that is necessary is for the client to send an >>>>> emergency NAI to signal the need for emergency access. The >>>> server >>>>> will still send its certificate which the client should >>>> verify. The >>>>> server can either not request the client certificate based on the >>>>> emergency NAI, or it can ask for it, but the client will not >>>> supply >>>>> it and the server needs to then conclude the authentication by >>>>> placing the client on an emergency VLAN. >>>> >>>> That's fine _if_ your network supports such a mechanism. >>>> >>>> None of the network technologies I ever ran did. >>>> >>>> All I'm saying is the draft needs to be much clearer (IMHO) about >>>> what sorts of access network technologies _might_ be able to >>>> support this. >>>> >>>> Ray >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From Ray.Bellis@nominet.org.uk Mon Nov 9 06:09:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB9D28B23E for ; Mon, 9 Nov 2009 06:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByUuoX9Dv6Qs for ; Mon, 9 Nov 2009 06:09:53 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 2EBF73A67E5 for ; Mon, 9 Nov 2009 06:09:53 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=OyGzq+II3z0TOoPlICW7M5FOZNMzZWBu2NQdks4vMqOV5FYsItw2gsK0 CtfLTNpu4wmX7aVn5DSssIBJ3ItYBLg4iPfRPR60WWjfIC/NOHrRyOZk/ F1rON160344a1/m; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257775820; x=1289311820; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Fwd:=20Comments=20on=20draft-schulzrinne-ecrit-unaut henticated-access-03=0D=0A=20-=20Section=201|Date:=20Mon, =209=20Nov=202009=2023:10:17=20+0900|Message-ID:=20|To:=20Brian=20Rosen=20|Cc: =20ECRIT=20|MIME-Version:=201.0 |In-Reply-To:=20 |References:=20<8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@ DEMUEXC030.nsn-intra.net>=20; bh=AAQsEtYlsloPgl2tseysIPVtUg8u/fe021B9NnWCUCk=; b=YchiKXdpjxQfySHQOUQc8ILJj/DGwrPak9LGaU5rz5xwqda8ZyLJ63Ub PPKMzIRe2gOQOBc3H6Ko4XodjVhamlxjLo/uJS5obexjUOZiyAGFasirQ sGEMs+O9dFT1/g9; X-IronPort-AV: E=Sophos;i="4.44,708,1249254000"; d="scan'208";a="19235198" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 09 Nov 2009 14:10:18 +0000 In-Reply-To: References: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> To: Brian Rosen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 9 Nov 2009 23:10:17 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/11/2009 02:10:18 PM, Serialize complete at 09/11/2009 02:10:18 PM Content-Type: multipart/alternative; boundary="=_alternative 004DD72749257669_=" Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:09:54 -0000 This is a multipart message in MIME format. --=_alternative 004DD72749257669_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBBbHRob3VnaCBJIHdvdWxkIG5vdGUgdGhhdCBpdOKAmXMgbm90IHlldCBjbGVhciBob3cgdGhl IFUuUy4gUmVndWxhdG9yDQo+IHdpbGwgdHJlYXQgdGhlc2UgYXJyYW5nZW1lbnRzLiAgIFRoZXJl IGlzIHNpZ25pZmljYW50IHByZXNzdXJlIGZyb20gDQo+IHRoZSBlbWVyZ2VuY3kgY2FsbCBhdXRo b3JpdGllcyB0byBOT1Qgc3VwcG9ydCB1bmF1dGhlbnRpY2F0ZWQgYWNjZXNzDQo+IGZyb20gYnJv YWRiYW5kIG5ldHdvcmtzLg0KDQpHaXZlbiB0aGUgb2JqZWN0aW9ucyB0byBFQ1JJVC1kaXJlY3Qg YW5kIHRoZSBjb21wYXJpc29uIHdpdGggU0lNbGVzcyANCnBob25lcywgdGhhdCBkb2VzIG5vdCBz dXJwcmlzZSBtZS4NCiANCj4gSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUganVyaXNkaWN0aW9ucyB0 aGF0IEkgZXhwZWN0IHdpbGwgcmVxdWlyZSBpdCwNCj4gYW5kIHRodXMgdGhlcmUgbmVlZHMgdG8g YmUgc29tZSBkb2N1bWVudGF0aW9uIG9mIGhvdyB0byBkbyB0aGF0IGluIA0KPiBzdWNoIGp1cmlz ZGljdGlvbnMuIA0KDQpJJ2QgYXNrIHRoZSBzYW1lIGFzIEkgYXNrZWQgSGVubmluZyAtIHdoYXQg c29ydCBvZiBicm9hZGJhbmQgbmV0d29ya3MgZG8gDQp5b3UgbWVhbj8NCg0KUGVyIG15IHByZXZp b3VzIG1lc3NhZ2UsIHRoaXMgbWF5IG1ha2Ugc2Vuc2UgZm9yIHdpcmVsZXNzLCBidXQgaXQgZG9l c24ndCANCnNlZW0gdG8gbWFrZSBhbnkgc2Vuc2UgZm9yIHdpcmVkIGFjY2VzcywgYXQgbGVhc3Qg bm90IGZvciB0aGUgTkFBIGNhc2UuDQoNClJheQ0KDQo= --=_alternative 004DD72749257669_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEFsdGhvdWdoIEkgd291bGQgbm90ZSB0aGF0IGl0 4oCZcyBub3QgeWV0IGNsZWFyIGhvdyB0aGUgVS5TLiBSZWd1bGF0b3I8YnI+DQomZ3Q7IHdpbGwg dHJlYXQgdGhlc2UgYXJyYW5nZW1lbnRzLiAmbmJzcDsgVGhlcmUgaXMgc2lnbmlmaWNhbnQgcHJl c3N1cmUNCmZyb20gPGJyPg0KJmd0OyB0aGUgZW1lcmdlbmN5IGNhbGwgYXV0aG9yaXRpZXMgdG8g Tk9UIHN1cHBvcnQgdW5hdXRoZW50aWNhdGVkIGFjY2Vzczxicj4NCiZndDsgZnJvbSBicm9hZGJh bmQgbmV0d29ya3MuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5HaXZl biB0aGUgb2JqZWN0aW9ucyB0byBFQ1JJVC1kaXJlY3QgYW5kIHRoZSBjb21wYXJpc29uDQp3aXRo IFNJTWxlc3MgcGhvbmVzLCB0aGF0IGRvZXMgbm90IHN1cnByaXNlIG1lLjxicj4NCiA8YnI+DQom Z3Q7IEhvd2V2ZXIsIHRoZXJlIGFyZSBzb21lIGp1cmlzZGljdGlvbnMgdGhhdCBJIGV4cGVjdCB3 aWxsIHJlcXVpcmUgaXQsPGJyPg0KJmd0OyBhbmQgdGh1cyB0aGVyZSBuZWVkcyB0byBiZSBzb21l IGRvY3VtZW50YXRpb24gb2YgaG93IHRvIGRvIHRoYXQgaW4NCjxicj4NCiZndDsgc3VjaCBqdXJp c2RpY3Rpb25zLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkknZCBh c2sgdGhlIHNhbWUgYXMgSSBhc2tlZCBIZW5uaW5nIC0gd2hhdCBzb3J0IG9mDQpicm9hZGJhbmQg bmV0d29ya3MgZG8geW91IG1lYW4/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5QZXIgbXkgcHJldmlvdXMgbWVzc2FnZSwgdGhpcyBtYXkgbWFrZSBzZW5zZSBmb3Igd2ly ZWxlc3MsDQpidXQgaXQgZG9lc24ndCBzZWVtIHRvIG1ha2UgYW55IHNlbnNlIGZvciB3aXJlZCBh Y2Nlc3MsIGF0IGxlYXN0IG5vdCBmb3INCnRoZSBOQUEgY2FzZS48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJheTwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 004DD72749257669_=-- From dirk.kroeselberg@nsn.com Mon Nov 9 06:11:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D833A6784 for ; Mon, 9 Nov 2009 06:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgEUZ8kfM3DH for ; Mon, 9 Nov 2009 06:11:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 524CE3A67E5 for ; Mon, 9 Nov 2009 06:11:18 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA9EB5TI023008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 15:11:05 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA9EAmdD012752; Mon, 9 Nov 2009 15:11:05 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:34:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6141.6213364B" Date: Mon, 9 Nov 2009 14:34:34 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32C3F@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAABByh30AAEDo8A== References: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Marc Linsner" , , "Bernard Aboba" X-OriginalArrivalTime: 09 Nov 2009 13:34:38.0540 (UTC) FILETIME=[626A90C0:01CA6141] Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:11:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6141.6213364B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Marc,=20 =20 my understanding is that today this is mainly in place for the existing cellular networks, and the "I would say that obvous candidates include wireless access in regulated spectrum" part below is an assumption. But I may not be fully up-to-date regarding the latest status e.g. in the U.S. or Canda... =20 Thanks, Dirk ________________________________ From: ext Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Monday, November 09, 2009 2:16 PM To: Kroeselberg, Dirk (NSN - DE/Munich); Ray.Bellis@nominet.org.uk; Bernard Aboba Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =09 =09 Dirk, =09 Are there regulations that call for unauthenticated clients to have emergency access in the Internet realm? Or is this an assumption of something in the future? =09 -Marc- =09 =09 On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" wrote: =09 =09 Ray,=20 =09 what you are saying in your earlier e-mail is true for the UK, but not for other countries. Currently there is support for 'SIM-less' calls in cellular networks (enabled based on a per-country policy). You need to support this in some regions like North-America. I would say that obvious candidates include wireless access in regulated spectrum. For fixed-line, this is not a big deal as usually there is no 'unauthenticated' case. =09 Dirk =09 =09 =09 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Ray.Bellis@nominet.org.uk Sent: Monday, November 09, 2009 6:03 AM To: Bernard Aboba Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 =09 =20 > Why? Existing authentication mechanisms (such as EAP-TLS,=20 > described in RFC 5216) already support client unauthenticated=20 > access. All that is necessary is for the client to send an=20 > emergency NAI to signal the need for emergency access. The server=20 > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the=20 > emergency NAI, or it can ask for it, but the client will not supply=20 > it and the server needs to then conclude the authentication by=20 > placing the client on an emergency VLAN.=20 =09 That's fine _if_ your network supports such a mechanism.=20 =09 None of the network technologies I ever ran did.=20 =09 All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this. =20 =09 Ray=20 =09 =09 =09 ________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =09 ------_=_NextPart_001_01CA6141.6213364B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Fwd: Comments on = draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1
Marc,=20
 
my=20 understanding is that today this is mainly in place for the existing = cellular=20 networks, and the "I would say that obvous candidates include wireless = access in=20 regulated spectrum" part below is an assumption. But I may not be fully=20 up-to-date regarding the latest status e.g. in the U.S. or=20 Canda...
 
Thanks,
Dirk

From: ext Marc Linsner=20 [mailto:mlinsner@cisco.com]
Sent: Monday, November 09, 2009 = 2:16=20 PM
To: Kroeselberg, Dirk (NSN - DE/Munich);=20 Ray.Bellis@nominet.org.uk; Bernard Aboba
Cc:=20 ECRIT
Subject: Re: [Ecrit] Fwd: Comments on=20 draft-schulzrinne-ecrit-unauthenticated-access-03 - Section=20 1

Dirk,

Are there regulations that call = for=20 unauthenticated clients to have emergency access in the Internet = realm?=20  Or is this an assumption of something in the=20 future?

-Marc-


On 11/9/09 12:31 AM, "Kroeselberg, = Dirk (NSN=20 - DE/Munich)" <dirk.kroeselberg@nsn.com>=20 wrote:
Ray,

what you are saying in your = earlier e-mail is=20 true for the UK, but not for other countries. Currently there is = support for=20 'SIM-less' calls in cellular networks (enabled based on a = per-country=20 policy). You need to support this in some regions like = North-America. I=20 would say that obvious candidates include wireless access in = regulated=20 spectrum.
For fixed-line, this is not a big deal as usually there = is no=20 'unauthenticated' case.

Dirk

 
From: ecrit-bounces@ietf.org =  [mailto:ecrit-bounces@ietf.org]= =20 On Behalf Of ext  Ray.Bellis@nominet.org.uk
Se= nt:=20 Monday, November 09, 2009 6:03  AM
To: Bernard=20 Aboba
Cc: 'ECRIT'
Subject: Re:  [Ecrit] = Fwd:=20 Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 -=20  Section 1

 
> Why? =   Existing=20 authentication  mechanisms (such as EAP-TLS,
> = described in=20 RFC 5216) already support  client unauthenticated
> = access.=20  All that is necessary is for the  client to send an =
>=20 emergency NAI to signal the need for emergency  access. =  The=20 server
> will still send its certificate which the =  client=20 should verify.  The
> server can either not request the =  client certificate based on the
> emergency NAI, or = it can=20 ask for it,  but the client will not supply
> it and = the=20 server needs to then  conclude the authentication by
> = placing=20 the client on an emergency  VLAN.

That's fine _if_ your = network=20  supports such a mechanism.

None of the  network=20 technologies I ever ran did.

All  I'm saying is = the draft=20 needs to be much clearer (IMHO) about what sorts of  access = network=20 technologies _might_ be able to support this. =  

Ray=20

_______________________________________________
Ecrit=20 mailing list
Ecrit@ietf.org
https://www.ietf.org= /mailman/listinfo/ecrit
------_=_NextPart_001_01CA6141.6213364B-- From dirk.kroeselberg@nsn.com Mon Nov 9 06:18:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599B928B23E for ; Mon, 9 Nov 2009 06:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4nx3GVtPd4m for ; Mon, 9 Nov 2009 06:18:51 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id A35BB28C110 for ; Mon, 9 Nov 2009 06:18:50 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA9EJ2GH006256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 15:19:02 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA9EJ15s015110; Mon, 9 Nov 2009 15:19:01 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:50:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 14:50:18 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32C74@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: AcphQW6cK0uFZdmiwE6ANzRqFMANPgAAEY9Q References: <115728BF-E648-481F-9250-22CBF6F6CA32@cs.columbia.edu> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Marc Linsner" , "Henning Schulzrinne" X-OriginalArrivalTime: 09 Nov 2009 13:50:25.0055 (UTC) FILETIME=[96954AF0:01CA6143] Cc: Ray.Bellis@nominet.org.uk, ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:18:52 -0000 Marc,=20 I think I agree with this in so far that it is not the job of any standards organization to decide or figure out where to use such feature. A standard in this area can only offer building blocks or capture some recommendations. Where these will actually be used later on is a different story. But at least it does not look like we can safely assume that noone will require such functionality. Dirk=20 > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Monday, November 09, 2009 2:35 PM > To: Henning Schulzrinne > Cc: Kroeselberg, Dirk (NSN - DE/Munich);=20 > Ray.Bellis@nominet.org.uk; Bernard Aboba; ECRIT > Subject: Re: [Ecrit] Fwd: Comments on=20 > draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 >=20 > Hence, I want the motivation for the work to NOT include=20 > 'regulation'. As > you describe, the functionality should stand on it's own merits. >=20 > -Marc- >=20 >=20 > On 11/9/09 8:27 AM, "Henning Schulzrinne" wrote: >=20 > > Given that there are currently likely no regulations for Internet > > emergency calling (beyond the "must provide equivalent=20 > service ones"), > > I suspect that asking this question is not too helpful. I would > > consider this anticipating and exploring the issue - namely, whether > > it is feasible to do this if so desired. We have the moral=20 > equivalent, > > such as US landlines that have been shut off for=20 > non-payment, but can > > still be used to place emergency calls, in addition to=20 > payphones that > > provide free emergency calls. > >=20 > > If I were a hotel or airport operator, I'd want to provide such > > functionality - after all, I'd kind of like the local fire=20 > and police > > department to know about the smoke or suspicious package that a > > visitor is seeing. > >=20 > > Henning > >=20 > > On Nov 9, 2009, at 8:15 AM, Marc Linsner wrote: > >=20 > >> Dirk, > >>=20 > >> Are there regulations that call for unauthenticated clients to have > >> emergency access in the Internet realm? Or is this an=20 > assumption of > >> something in the future? > >>=20 > >> -Marc- > >>=20 > >>=20 > >> On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" > >> >>> wrote: > >>=20 > >>> Ray, > >>>=20 > >>> what you are saying in your earlier e-mail is true for the UK, but > >>> not for other countries. Currently there is support for 'SIM-less' > >>> calls in cellular networks (enabled based on a=20 > per-country policy). > >>> You need to support this in some regions like North-America. I > >>> would say that obvious candidates include wireless access in > >>> regulated spectrum. > >>> For fixed-line, this is not a big deal as usually there is no > >>> 'unauthenticated' case. > >>>=20 > >>> Dirk > >>>=20 > >>>>=20 > >>>>=20 > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf Of ext Ray.Bellis@nominet.org.uk > >>>> Sent: Monday, November 09, 2009 6:03 AM > >>>> To: Bernard Aboba > >>>> Cc: 'ECRIT' > >>>> Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit- > >>>> unauthenticated-access-03 - Section 1 > >>>>=20 > >>>>=20 > >>>>> Why? Existing authentication mechanisms (such as EAP-TLS, > >>>>> described in RFC 5216) already support client unauthenticated > >>>>> access. All that is necessary is for the client to send an > >>>>> emergency NAI to signal the need for emergency access. The > >>>> server > >>>>> will still send its certificate which the client should > >>>> verify. The > >>>>> server can either not request the client certificate=20 > based on the > >>>>> emergency NAI, or it can ask for it, but the client will not > >>>> supply > >>>>> it and the server needs to then conclude the authentication by > >>>>> placing the client on an emergency VLAN. > >>>>=20 > >>>> That's fine _if_ your network supports such a mechanism. > >>>>=20 > >>>> None of the network technologies I ever ran did. > >>>>=20 > >>>> All I'm saying is the draft needs to be much clearer=20 > (IMHO) about > >>>> what sorts of access network technologies _might_ be able to > >>>> support this. > >>>>=20 > >>>> Ray > >>>=20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 >=20 From br@brianrosen.net Mon Nov 9 06:46:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0F33A692E for ; Mon, 9 Nov 2009 06:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-kfkiSVyzRb for ; Mon, 9 Nov 2009 06:46:03 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D125E3A63C9 for ; Mon, 9 Nov 2009 06:46:02 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7VVd-0006sy-CI; Mon, 09 Nov 2009 08:46:21 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 09 Nov 2009 09:46:24 -0400 From: Brian Rosen To: Message-ID: Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: AcphS2iroNTEO5QHXkiWndyImXHYSg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340604788_56970095" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:46:07 -0000 > 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. --B_3340604788_56970095 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Frankly, I don=B9t really know how this will work, but I=B9ve had someone explain to me that they believe their regulator will require ALL broadband networks to support access to make emergency calls. If there is an L2 path= , then access is allowed for emergency calls, similar to if there is a radio connection, access is allowed for emergency calls. I don=B9t think the choic= e of access control mechanism has any bearing on what the regulator requires. Brian On 11/9/09 10:10 AM, "Ray.Bellis@nominet.org.uk" wrote: >=20 >> > Although I would note that it=B9s not yet clear how the U.S. Regulator >> > will treat these arrangements. There is significant pressure from >> > the emergency call authorities to NOT support unauthenticated access >> > from broadband networks. >=20 > Given the objections to ECRIT-direct and the comparison with SIMless phon= es, > that does not surprise me. > =20 >> > However, there are some jurisdictions that I expect will require it, >> > and thus there needs to be some documentation of how to do that in >> > such jurisdictions. >=20 > I'd ask the same as I asked Henning - what sort of broadband networks do = you > mean?=20 >=20 > Per my previous message, this may make sense for wireless, but it doesn't= seem > to make any sense for wired access, at least not for the NAA case. >=20 > Ray=20 >=20 --B_3340604788_56970095 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated= -access-03 - Section 1 Frankly, I don’t really know how this will work, but I’ve had = someone explain to me that they believe their regulator will require ALL bro= adband networks to support access to make emergency calls.  If there is= an L2 path, then access is allowed for emergency calls, similar to if there= is a radio connection, access is allowed for emergency calls.  I don&#= 8217;t think the choice of access control mechanism has any bearing on what = the regulator requires.

Brian


On 11/9/09 10:10 AM, "Ray.Bellis@n= ominet.org.uk" <Ray.Bellis@n= ominet.org.uk> wrote:


> Although I would note that it’s not yet clear how the U.S. Regul= ator
> will treat these arrangements.   There is significant pressu= re from
> the emergency call authorities to NOT support unauthenticated access > from broadband networks.

Given the objections to = ECRIT-direct and the comparison with SIMless phones, that does not surprise = me.
 
> However, there are some jurisdictions that I expect will require it, > and thus there needs to be some documentation of how to do that in > such jurisdictions.

I'd ask the same as I as= ked Henning - what sort of broadband networks do you mean?

Per my previous message,= this may make sense for wireless, but it doesn't seem to make any sense for= wired access, at least not for the NAA case.

Ray

--B_3340604788_56970095-- From hgs@cs.columbia.edu Mon Nov 9 06:46:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC653A6A05 for ; Mon, 9 Nov 2009 06:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV6siXSfP8Tr for ; Mon, 9 Nov 2009 06:46:32 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 768853A63C9 for ; Mon, 9 Nov 2009 06:46:32 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA9EkngO012301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2009 09:46:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: Date: Mon, 9 Nov 2009 09:46:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:46:33 -0000 > > Per my previous message, this may make sense for wireless, but it > doesn't seem to make any sense for wired access, at least not for > the NAA case. In some cases, this may make sense for wired (Ethernet) networks. My understanding is that it is becoming more common that corporate networks require network access authentication for their wired networks, to avoid the obvious security problem that a visitor can just leave behind a little box that plugs into the nearest unused Ethernet jack. On a college campus I visited recently, both the wired and wireless network required the same (web-based) access authentication for students and visitors. (To my disappointment - I had hoped that my retractable Ethernet cable would help me out to get Internet access...) Henning From Martin.Dawson@andrew.com Mon Nov 9 08:04:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C9D3A67E2 for ; Mon, 9 Nov 2009 08:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-oAgF8GQPA5 for ; Mon, 9 Nov 2009 08:04:30 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 813D63A67C1 for ; Mon, 9 Nov 2009 08:04:30 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:53830 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5048345AbZKIQEz (ORCPT ); Mon, 9 Nov 2009 10:04:55 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 9 Nov 2009 10:04:55 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 10 Nov 2009 00:04:52 +0800 From: "Dawson, Martin" To: Brian Rosen , "Kroeselberg, Dirk (NSN - DE/Munich)" , "Ray.Bellis@nominet.org.uk" , Bernard Aboba Date: Tue, 10 Nov 2009 00:04:50 +0800 Thread-Topic: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Acpg+keOYREFx0uEREymzMACNqJvPQAAqclAABEVsgwABD100A== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4F93@SISPE7MB1.commscope.com> References: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F0F2E4F93SISPE7MB1commsc_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:04:40 -0000 --_000_8B0A9FCBB9832F43971E38010638454F0F2E4F93SISPE7MB1commsc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Your last comment indicates some actual or affected confusion about direct.= .. which was also indicated in previous sensational comparisons to "SIMless= " scenarios. The question of whether the call goes directly from UA to ESRP is orthogona= l to the question of (un)authenticated network access. The access can preve= nt an emergency call for an unauthenticated device regardless of whether th= e call is being made via a VSP or whether it goes directly. It is non sensi= ble to compare the two documents in this way. Having said that, where some jurisdiction demands that networks permit emer= gency calls regardless of "authentication" then the direct model certainly = makes it easier for the network to apply appropriate controls - i.e. the ne= twork doesn't have to somehow take the device's word for it that it really = is using that foreign VSP to make an emergency call... "honest guv'" On the topic of the thread: There are two main reasons networks do authentication - security, particula= rly for enterprise networks - and commercial; i.e. for billing purposes. Th= e nature of authentication, and in particular whether it occurs at layer tw= o or not, will govern how difficult it is to support "unauthenticated" emer= gency calling. If authentication occurs on layer 3, then unauthenticated em= ergency access is more straightforward: Consider the typical hot spot. Access is uncontrolled right up to layer 3; = the access points are unsecured, an IP address is issued. At that point the= user is typically portal locked, HTTP only, to the access point web site. = Some portals allow limited web browsing to specific destinations. It is rea= sonably straightforward to add access to the LIS, LoST, and SIP to the PSAP= URI to the portal white list. Then users can tunnel the emergency procedur= es through that access without completing authentication. No other general = Internet access is granted or required. Where an emergency context has to be established at layer 2, then I don't r= eally see any alternative to the layer two technology supporting specific s= ignalling to establish that context in order that the device can be bootstr= apped up to layer 3. Once that is done, the same limited access is possible= as in the hot spot scenario above. 3GPP has described how UE establish an = emergency context in their RANs; I believe there is movement in the IEEE to= do something like this for 802. No idea what the DSL or cable forums are t= hinking. As discussed, the imperative for any form of access network to do this must= ultimately be the subject of local regulation. It's definitely worthwhile = documenting what we can to help those jurisdictions decide whether it's wor= thwhile. I'm not sure that the IETF can say anything other than what happen= s from IP up however. Again - it's a different topic to the one covered in = the ECRIT direct draft. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= rian Rosen Sent: Monday, 9 November 2009 11:34 PM To: Kroeselberg, Dirk (NSN - DE/Munich); Ray.Bellis@nominet.org.uk; Bernard= Aboba Cc: ECRIT Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticat= ed-access-03 - Section 1 Although I would note that it's not yet clear how the U.S. Regulator will t= reat these arrangements. There is significant pressure from the emergency= call authorities to NOT support unauthenticated access from broadband netw= orks. However, there are some jurisdictions that I expect will require it, and th= us there needs to be some documentation of how to do that in such jurisdict= ions. As long as the device can tell if it is required or not, we'll be ok= ay. As with -direct, I don't want to encourage such use, but if the local = jurisdiction requires it, then we have to do something. I prefer this docu= ment over -direct. Brian On 11/9/09 1:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" wrote: Ray, what you are saying in your earlier e-mail is true for the UK, but not for = other countries. Currently there is support for 'SIM-less' calls in cellula= r networks (enabled based on a per-country policy). You need to support thi= s in some regions like North-America. I would say that obvious candidates i= nclude wireless access in regulated spectrum. For fixed-line, this is not a big deal as usually there is no 'unauthentica= ted' case. Dirk ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = ext Ray.Bellis@nominet.org.uk Sent: Monday, November 09, 2009 6:03 AM To: Bernard Aboba Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthentica= ted-access-03 - Section 1 > Why? Existing authentication mechanisms (such as EAP-TLS, > described in RFC 5216) already support client unauthenticated > access. All that is necessary is for the client to send an > emergency NAI to signal the need for emergency access. The server > will still send its certificate which the client should verify. The > server can either not request the client certificate based on the > emergency NAI, or it can ask for it, but the client will not supply > it and the server needs to then conclude the authentication by > placing the client on an emergency VLAN. That's fine _if_ your network supports such a mechanism. None of the network technologies I ever ran did. All I'm saying is the draft needs to be much clearer (IMHO) about what sor= ts of access network technologies _might_ be able to support this. Ray ________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_8B0A9FCBB9832F43971E38010638454F0F2E4F93SISPE7MB1commsc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

Hi Brian,

 

Your last comment indicates some actua= l or affected confusion about direct… which was also indicated in previous= sensational comparisons to “SIMless” scenarios.

 

The question of whether the call goes directly from UA to ESRP is orthogonal to the question of (un)authenticated network access. The access can prevent an emergency call for an unauthentic= ated device regardless of whether the call is being made via a VSP or whether it goes directly. It is non sensible to compare the two documents in this way.=

 

Having said that, where some jurisdict= ion demands that networks permit emergency calls regardless of “authentic= ation” then the direct model certainly makes it easier for the network to apply appropriate controls – i.e. the network doesn’t have to somehow take the device’s word for it that it really is using that foreign VS= P to make an emergency call… “honest guv’”

 

On the topic of the thread:=

 

There are two main reasons networks do authentication – security, particularly for enterprise networks ̵= 1; and commercial; i.e. for billing purposes. The nature of authentication, an= d in particular whether it occurs at layer two or not, will govern how difficult= it is to support “unauthenticated” emergency calling. If authentication occurs on layer 3, then unauthenticated emergency access is = more straightforward:

 

Consider the typical hot spot. Access = is uncontrolled right up to layer 3; the access points are unsecured, an IP address is issued. At that point the user is typically portal locked, HTTP only, to the access point web site. Some portals allow limited web browsing= to specific destinations. It is reasonably straightforward to add access to th= e LIS, LoST, and SIP to the PSAP URI to the portal white list. Then users can tunn= el the emergency procedures through that access without completing authenticat= ion. No other general Internet access is granted or required.<= /font>

 

Where an emergency context has to be established at layer 2, then I don’t really see any alternative to th= e layer two technology supporting specific signalling to establish that conte= xt in order that the device can be bootstrapped up to layer 3. Once that is do= ne, the same limited access is possible as in the hot spot scenario above. 3GPP= has described how UE establish an emergency context in their RANs; I believe th= ere is movement in the IEEE to do something like this for 802. No idea what the= DSL or cable forums are thinking.

 

As discussed, the imperative for any f= orm of access network to do this must ultimately be the subject of local regulation. It’s definitely worthwhile documenting what we can to hel= p those jurisdictions decide whether it’s worthwhile. I’m not sur= e that the IETF can say anything other than what happens from IP up however. = Again – it’s a different topic to the one covered in the ECRIT direct draft.

 

Cheers,

Martin

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, 9 November 200= 9 11:34 PM
To: Kroeselberg, Dirk (NSN - DE/Munich); Ray.Bellis@nominet.org.uk; Bernard Aboba
Cc: ECRIT
Subject: Re: [Ecrit] Fwd: Co= mments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

 

Although I would note that it’s not yet clear how the U.S. Regulator will treat these arrangemen= ts.   There is significant pressure from the emergency call authoriti= es to NOT support unauthenticated access from broadband networks.

However, there are some jurisdictions that I expect will require it, and th= us there needs to be some documentation of how to do that in such jurisdiction= s.  As long as the device can tell if it is required or not, we’ll = be okay.  As with –direct, I don’t want to encourage such use= , but if the local jurisdiction requires it, then we have to do something.  I prefer this document over –direct.

Brian


On 11/9/09 1:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> wrote:

= Ray,

what you are saying in your earlier e-mail is true for the UK, but not for other countries. Currently there is support for 'SIM-less' call= s in cellular networks (enabled based on a per-country policy). You need to supp= ort this in some regions like North-America. I would say that obvious candidate= s include wireless access in regulated spectrum.
For fixed-line, this is not a big deal as usually there is no 'unauthentica= ted' case.

Dirk


 

From: ecrit-bounces@ietf.org  [mailto:ecrit-bounces@ietf.org] <= b>On Behalf Of ext  Ray.Bellis@nominet.org.uk
Sent: Monday, November 09, 2= 009 6:03  AM
To: Bernard Aboba
Cc: 'ECRIT'
Subject: Re:  [Ecrit] F= wd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 -  Secti= on 1

 
> Why?   Existing authentication  mechanisms (such as EAP-TLS,
> described in RFC 5216) already support  client unauthenticated > access.  All that is necessary is for the  client to send an=
> emergency NAI to signal the need for emergency  access.  The server
> will still send its certificate which the  client should verify.  The
> server can either not request the  client certificate based on th= e
> emergency NAI, or it can ask for it,  but the client will not sup= ply
> it and the server needs to then  conclude the authentication by <= br> > placing the client on an emergency  VLAN.

That's fine _if_ your network  supports such a mechanism.

None of the  network technologies I ever ran did= .

All  I'm saying is the draft needs to be much clearer (IMHO) about what sorts of  access network technologies _might= _ be able to support this.  

Ray

 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit

--_000_8B0A9FCBB9832F43971E38010638454F0F2E4F93SISPE7MB1commsc_-- From byron@psapservice.com Mon Nov 9 08:14:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA503A677D for ; Mon, 9 Nov 2009 08:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0utDefca44cD for ; Mon, 9 Nov 2009 08:14:47 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 702AA3A697B for ; Mon, 9 Nov 2009 08:14:41 -0800 (PST) Received: by bwz23 with SMTP id 23so3568928bwz.29 for ; Mon, 09 Nov 2009 08:15:04 -0800 (PST) Received: by 10.103.80.36 with SMTP id h36mr3234519mul.18.1257783304289; Mon, 09 Nov 2009 08:15:04 -0800 (PST) Received: from leo.in911.net (static-98-108-98-36.sbndin.dsl-w.verizon.net [98.108.98.36]) by mx.google.com with ESMTPS id y6sm11247718mug.40.2009.11.09.08.15.01 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 08:15:03 -0800 (PST) Message-ID: <4AF84003.50705@psapservice.com> Date: Mon, 09 Nov 2009 11:14:59 -0500 From: Byron Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: ecrit@ietf.org References: <115728BF-E648-481F-9250-22CBF6F6CA32@cs.columbia.edu> In-Reply-To: <115728BF-E648-481F-9250-22CBF6F6CA32@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:14:48 -0000 It should be noted that NAA access may not provide the same level of functionality as credentialed access. With respect to US landlines that are shut off for non-payment: At least here in the state of Indiana there is no regulatory requirement of which I am aware. It is a telco "service" that varies with company, policy, and equipment. However, this PSTN "NAA" service, where implemented, may be problematic for several reasons: a) Incorrect routing, as the caller may not have an assigned number in the Class 5 switch, so the call must be "exchange" (trunk) routed b) No ALI data, or ALI data may be "generic" without location information c) The PSAP cannot call back the caller d) Potential for annoynomous / annoyance calls Due to these issues such PSTN calls create special problems for the PSAP (lack of identification/location data)/annoyance calls/out-of-jurisdiction calls), for the service provider (trouble tickets for "misroutes," no ALI, annoyance call tracing, exposure to legal actions) and to the caller (lower quality of emergency service). So some local telcos have ceased to implement this type of service rather than deal with the issues. Never-the-less, for the telcos that do provide this service, a person can still call for help from a "disconnected" phone even though the quality of service is substantially reduced. I do agree this is an interesting issue to consider. Presumably the feasibility of providing NAA service in the Internet world will be greater than in the PSTN world. I just wanted to make the point that this type of service is not universally available in the PSTN network, and that it is problematic in serveral ways. Byron On 11/09/2009 08:27 AM, Henning Schulzrinne wrote: > Given that there are currently likely no regulations for Internet > emergency calling (beyond the "must provide equivalent service ones"), > I suspect that asking this question is not too helpful. I would > consider this anticipating and exploring the issue - namely, whether > it is feasible to do this if so desired. We have the moral equivalent, > such as US landlines that have been shut off for non-payment, but can > still be used to place emergency calls, in addition to payphones that > provide free emergency calls. > > If I were a hotel or airport operator, I'd want to provide such > functionality - after all, I'd kind of like the local fire and police > department to know about the smoke or suspicious package that a > visitor is seeing. > > Henning From bernard_aboba@hotmail.com Mon Nov 9 08:54:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557343A6B05 for ; Mon, 9 Nov 2009 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXvZsiS-9cCn for ; Mon, 9 Nov 2009 08:54:57 -0800 (PST) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by core3.amsl.com (Postfix) with ESMTP id 68C2E3A69B2 for ; Mon, 9 Nov 2009 08:54:57 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:55:23 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Henning Schulzrinne'" , References: <8C51C7A529FC9D49843ACF5AE2FFBF6701F32798@DEMUEXC030.nsn-intra.net> In-Reply-To: Date: Mon, 9 Nov 2009 08:55:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphS6dBX5EYgXB4SQKMa1E0s7NPNAAD4sVQ Content-Language: en-us X-OriginalArrivalTime: 09 Nov 2009 16:55:23.0626 (UTC) FILETIME=[6DD8D4A0:01CA615D] Cc: 'ECRIT' Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:54:58 -0000 Henning said: "In some cases, this may make sense for wired (Ethernet) networks. My understanding is that it is becoming more common that corporate networks require network access authentication for their wired networks, to avoid the obvious security problem that a visitor can just leave behind a little box that plugs into the nearest unused Ethernet jack. On a college campus I visited recently, both the wired and wireless network required the same (web-based) access authentication for students and visitors. (To my disappointment - I had hoped that my retractable Ethernet cable would help me out to get Internet access...)" There are a number of challenges for providing emergency calling on authenticated Ethernet networks. Today these networks are not built to enable rapid logon. If clients are set to expect 802.1X support, then they will send EAPoL-Start packets in an effort to wake up the authenticator. If they don't get an answer, they will not allow network access unless they are set up for "failback", in which case they will then start DHCP and get an address. At that point they may encounter the web portal/DNS spoofing facility which typically returns the A/AAAA RR of the portal in response to all A/AAAA RR queries. Since we are talking about a DNS proxy, it is likely to be non-compliant in a variety of ways (see RFC 5625). Many applications (including some SIP UAs) do not deal well with portal behavior, and will throw up various error messages as certificates fail to verify, registration attempts timeout or fail, etc. Assuming that the user is not too distracted by all the error messages being thrown up, they will need to bring up the browser and attempt to satisfy the demands of the portal on their handset screens. Since the portals are non-standard in their designs, they may need to create login IDs, agree to the terms of use, select roaming partners, etc. before they are allowed enough access to actually attempt an emergency call. Just getting on to an authenticated Ethernet network is a annoying at best in a non-stressful situation. In an emergency, the exercise would be a form of torture. From MILANPA@nortel.com Mon Nov 9 19:21:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6486C3A681B for ; Mon, 9 Nov 2009 19:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmtNDwvnl9HP for ; Mon, 9 Nov 2009 19:21:14 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 821A63A6405 for ; Mon, 9 Nov 2009 19:21:14 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAA3Lbk09076; Tue, 10 Nov 2009 03:21:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA61B4.E057479B" Date: Tue, 10 Nov 2009 03:21:19 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900B38EA6A@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E900B314C2D@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] marking of PSAP call backs Thread-Index: AcpeJCyv6L0It9iDThiC58Grf/F+SwDgugmg References: <0913B6CD18F370498CD65864CF254E900B314C2D@zharhxm1.corp.nortel.com> From: "Milan Patel" To: "ecrit" , Cc: 3GPP_TSG_CT_WG1@LIST.ETSI.ORG Subject: Re: [Ecrit] marking of PSAP call backs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:21:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA61B4.E057479B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Yesterday in 3GPP CT1, we discussed the marking of PSAP call backs based on draft-schulzrinne-ecrit-psap-callback-01. The solution approaches were presented but CT1 did not agree on a way forwards. No preference was indicated for any of the solution approaches defined in the draft, but it was commented that the use of a URI parameter (as per older versions of the "sos" parameter draft) would be a satisfactory mechanism for 3GPP. The security vulnerabilities would still be an issue for further study.=20 =20 A number of companies expressed a preference for a solution defined by the IETF and suggested that 3GPP should consider if a solution defined by the IETF would satisfy the requirements of 3GPP. Uses of any of the solution approaches (or a combination of them) are not precluded and alternative solution approaches would also be considered.=20 =20 During the discussions it was questioned if handling of call backs towards emergency callers with special needs (such as the hard of hearing) need to be considered. At least in 3GPP we define emergency calls using GTT for the hard of hearing. I believe such calls are also considered in the ECRIT Framework/PhoneBCP.=20 =20 Best regards, Milan =20 Milan Patel=20 Carrier Networks Core Standards=20 Nortel=20 milanpa@nortel.com=20 Telephone +44 162 843 2381 / ESN 560 2381=20 Mobile +44 774 053 9261 / ESN 748 9261=20 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Patel, Milan (MOP:EP10) Sent: 05 November 2009 14:28 To: ecrit Subject: [Ecrit] marking of PSAP call backs =20 Hi Folks, =20 For next week's 3GPP CT1 meeting I have submitted a document based on the Internet-Draft for marking PSAP call backs. The intention is to get some feedback from 3GPP on which of the solution approaches, if any, are a good way to progress work in for this feature. Also, the paper intends to get a decision on whether 3GPP see that it is possible to fulfil the requirement of marking PSAP call backs within the 3GPP release 9 timeframe.=20 The Internet-Draft is: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 The 3GPP paper is available at: http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1/TSGC1_62_Beijing/docs /C1-095075.zip =20 I will update you on the discussion that occurs next week. In the mean time if you have any immediate feedback or comments on the paper or the Internet-Draft, I would appreciate them.=20 Best regards, Milan =20 Milan Patel=20 Carrier Networks Core Standards=20 Nortel=20 milanpa@nortel.com=20 Telephone +44 162 843 2381 / ESN 560 2381=20 Mobile +44 774 053 9261 / ESN 748 9261=20 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV =20 ------_=_NextPart_001_01CA61B4.E057479B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Yesterday in 3GPP CT1, we discussed the marking of = PSAP call backs based on draft-schulzrinne-ecrit-psap-callback-01. The solution approaches were presented but CT1 did not agree on a way forwards. No preference was indicated for any of the solution approaches defined in = the draft, but it was commented that the use of a URI parameter (as per = older versions of the "sos" parameter draft) would be a satisfactory mechanism for 3GPP. The security vulnerabilities would still be an issue = for further study.

 

A number of companies expressed a preference for a = solution defined by the IETF and suggested that 3GPP should consider if a = solution defined by the IETF would satisfy the requirements of 3GPP. Uses of any = of the solution approaches (or a combination of them) are not precluded and alternative solution approaches would also be considered. =

 

During the discussions it was questioned if handling = of call backs towards emergency callers with special needs (such as the hard of hearing) need to be considered. At least in 3GPP we define emergency = calls using GTT for the hard of hearing. I believe such calls are also considered in = the ECRIT Framework/PhoneBCP.

 

Best regards,

Milan

 

Milan Patel
Carrier Networks = Core Standards
Nortel
milanpa@nortel.co= m
Telephone +4= 4 162 843 2381 / ESN 560 2381
Mobile +44 774 053 9261 / ESN 748 = 9261 =

For = the Companies listed below, The Institute of Chartered Accountants in = England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to = act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act = 1986.

The = affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as = agents of the Companies only and without personal = liability.

The = Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel = Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel = Networks = (Austri= a) GmbH; Nortel Networks sro; Nortel Networks = Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; = Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel = Networks International Finance & Holding = BV

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Patel, Milan (MOP:EP10)
Sent: 05 November 2009 = 14:28
To: ecrit
Subject: [Ecrit] marking = of PSAP call backs

 

Hi Folks,

 

For next week's 3GPP CT1 meeting I have submitted a document = based on the Internet-Draft for marking PSAP call backs. The intention is to get = some feedback from 3GPP on which of the solution approaches, if any, are a = good way to progress work in for this feature. Also, the paper intends to get a = decision on whether 3GPP see that it is possible to fulfil the requirement of = marking PSAP call backs within the 3GPP release 9 timeframe. =

The Internet-Draft is: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01

The 3GPP paper is available at:

http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1= /TSGC1_62_Beijing/docs/C1-095075.zip

 

I will update you on the discussion that occurs next week. In = the mean time if you have any immediate feedback or comments on the paper or the Internet-Draft, I would appreciate them.

Best regards,

Milan

 

Milan Patel
Carrier Networks Core Standards
Nortel
milanpa@nortel.com
Telephone +44 162 843 2381 / ESN 560 2381
Mobile +44 774 053 9261 / ESN 748 9261 =

For = the Companies listed below, The Institute of Chartered Accountants in = England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to = act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act = 1986.

The = affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as = agents of the Companies only and without personal = liability.

The = Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel = Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel = Networks (Austria) GmbH; Nortel = Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal = SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks = Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding = BV

 

------_=_NextPart_001_01CA61B4.E057479B-- From br@brianrosen.net Tue Nov 10 06:06:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A92828C199 for ; Tue, 10 Nov 2009 06:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXLlc80hxIFr for ; Tue, 10 Nov 2009 06:06:56 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A2B1428C0E0 for ; Tue, 10 Nov 2009 06:06:56 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7rNL-0005TH-Gi; Tue, 10 Nov 2009 08:07:15 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 09:07:17 -0400 From: Brian Rosen To: Milan Patel , ecrit , Message-ID: Thread-Topic: [Ecrit] marking of PSAP call backs Thread-Index: AcpeJCyv6L0It9iDThiC58Grf/F+SwDgugmgABoB1Rc= In-Reply-To: <0913B6CD18F370498CD65864CF254E900B38EA6A@zharhxm1.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 3GPP_TSG_CT_WG1@LIST.ETSI.ORG Subject: Re: [Ecrit] marking of PSAP call backs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:06:58 -0000 Thank you for this. With regard to the last section, we need to consider two cases: A) The caller with special needs places a call using non-voice media directly to the PSAP. There is no 3rd party interpreter in the path. Wit= h respect to call backs, this is a simple case, as all calls would be signale= d the same way, but the SDP content would indicate text and/or video, or some form of IM would be used. Therefore any solution that worked with voice would work. B) The caller with special needs uses an interpreter, either engaged by the user, or perhaps by the PSAP, and a 3 way call ensues. A return call would need to recreate this arrangement, ideally with the same interpreter (if th= e call back occurred soon after the original call). -phonebcp does not discuss this kind of call. We have worked on exactly this arrangement, wit= h the caller engaging a 3rd party interpretation service, in NENA. The U.S. now has assigned telephone numbers to deaf and hard of hearing users who employ video (sign language) or text relay services. When dialed direct by the PSTN, the call reaches an interpreter, who completes an IP call to the deaf/hard of hearing user=B9s device. Similarly, when the deaf o= r hard of hearing user places a direct dialed call from their device, it automatically engages a relay service and places the voice part of the call from the interpreter to the hearing called party via the PSTN. Using a service like that for callback would be simple, but not as good as the original emergency call, which was a 3 way. To place a call back with a 3 way would require somewhat different signaling than described in =ADphonebcp. I don=B9t see this as very difficult, but it is different. I believe this kind of service will be extended to speech to speech relay, captioned voice service, and possibly others. We may have to investigate how other countries are evolving their telecommunications services for special needs individuals. Brian On 11/9/09 11:21 PM, "Milan Patel" wrote: > Hi, > =20 > Yesterday in 3GPP CT1, we discussed the marking of PSAP call backs based = on > draft-schulzrinne-ecrit-psap-callback-01. The solution approaches were > presented but CT1 did not agree on a way forwards. No preference was indi= cated > for any of the solution approaches defined in the draft, but it was comme= nted > that the use of a URI parameter (as per older versions of the "sos" param= eter > draft) would be a satisfactory mechanism for 3GPP. The security > vulnerabilities would still be an issue for further study. > =20 > A number of companies expressed a preference for a solution defined by th= e > IETF and suggested that 3GPP should consider if a solution defined by the= IETF > would satisfy the requirements of 3GPP. Uses of any of the solution appro= aches > (or a combination of them) are not precluded and alternative solution > approaches would also be considered. > =20 > During the discussions it was questioned if handling of call backs toward= s > emergency callers with special needs (such as the hard of hearing) need t= o be > considered. At least in 3GPP we define emergency calls using GTT for the = hard > of hearing. I believe such calls are also considered in the ECRIT > Framework/PhoneBCP. > =20 > Best regards, > Milan > =20 >=20 > Milan Patel=20 > Carrier Networks Core Standards > Nortel=20 > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 > Mobile +44 774 053 9261 / ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered Accountants in > England and Wales authorises A R Bloom, S Harris and C Hill to act as > Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 19= 86 > and the Association of Chartered Certified Accountants authorises A M Hud= son > to act as an Insolvency Practitioner under section 390(2)(a) of the Insol= vency > Act 1986. >=20 > The affairs, business and property of the Companies are being managed by = the > Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act a= s > agents of the Companies only and without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel = GmbH; > Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nort= el > Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; > Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks > Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks > Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel > Networks AB; Nortel Networks International Finance & Holding BV >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Patel, Milan (MOP:EP10) > Sent: 05 November 2009 14:28 > To: ecrit > Subject: [Ecrit] marking of PSAP call backs > =20 > Hi Folks, > =20 > For next week's 3GPP CT1 meeting I have submitted a document based on the > Internet-Draft for marking PSAP call backs. The intention is to get some > feedback from 3GPP on which of the solution approaches, if any, are a goo= d way > to progress work in for this feature. Also, the paper intends to get a > decision on whether 3GPP see that it is possible to fulfil the requiremen= t of > marking PSAP call backs within the 3GPP release 9 timeframe. > The Internet-Draft is: > http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 > The 3GPP paper is available at: > http://www.3gpp.org/ftp/tsg_CT/WG1_mm-cc-sm_ex-CN1/TSGC1_62_Beijing/docs/= C1-09 > 5075.zip > =20 > I will update you on the discussion that occurs next week. In the mean ti= me if > you have any immediate feedback or comments on the paper or the > Internet-Draft, I would appreciate them. > Best regards, > Milan > =20 > Milan Patel=20 > Carrier Networks Core Standards > Nortel=20 > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 > Mobile +44 774 053 9261 / ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered Accountants in > England and Wales authorises A R Bloom, S Harris and C Hill to act as > Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 19= 86 > and the Association of Chartered Certified Accountants authorises A M Hud= son > to act as an Insolvency Practitioner under section 390(2)(a) of the Insol= vency > Act 1986. >=20 > The affairs, business and property of the Companies are being managed by = the > Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act a= s > agents of the Companies only and without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel = GmbH; > Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nort= el > Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; > Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks > Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks > Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel > Networks AB; Nortel Networks International Finance & Holding BV >=20 > =20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Tue Nov 10 09:18:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F093028C130 for ; Tue, 10 Nov 2009 09:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.477 X-Spam-Level: X-Spam-Status: No, score=-5.477 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqBMbaBBcnWg for ; Tue, 10 Nov 2009 09:18:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7A89F3A6B0C for ; Tue, 10 Nov 2009 09:18:51 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAFMv+UpAZnwM/2dsb2JhbACCITCXeYokoWOJGwENBAWOdoJDEQWBZQSMAA X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208,217";a="67271432" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2009 17:19:18 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAHJHOv001099 for ; Tue, 10 Nov 2009 17:19:18 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:19:17 -0500 Received: from [10.116.195.123] ([10.116.195.123]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:19:17 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 12:19:15 -0500 From: Marc Linsner To: ECRIT Message-ID: Thread-Topic: ECRIT WG Webex Event Attendee Info Thread-Index: AcpiKe1srEH5a4wPnE6eZCbPg7Dytg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340700357_387681" X-OriginalArrivalTime: 10 Nov 2009 17:19:17.0241 (UTC) FILETIME=[EEC2DE90:01CA6229] Subject: [Ecrit] ECRIT WG Webex Event Attendee Info X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:18:53 -0000 > 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. --B_3340700357_387681 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Topic: IETF ECRIT WG Meeting Host: Marc Linsner Date and Time: November 11, 2009 9:00 am, Japan Standard Time (Hiroshima, GMT+09:00) Event number: 203 974 390 Event password: ietf ------------------------------------------------------- To join the online event ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/onstage/g.php?d=203974390&t=a&EA=mar c.linsner%40cisco.com&ET=1b1d338249aa9ffba4008e26c2713f2e&ETR=2d02741028dde2 c562c926f271bffb10&RT=MiMxMQ==&p 2. Click "Join Now". ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- Cost Savings Tips and Tricks ------------------------------------------------------- - Whenever possible, call the local number (if there is no charge to you). http://www.cisco.com/web/about/doing_business/conferencing/index.html - When using a U.S. cell phone in the United States, always call the local number, otherwise the company is charged twice (once for the minutes and again for the toll-free number). - When staying in a hotel, dial the local number from your cell phone, have the system call you, or use IP Communicator. ------------------------------------------------------- For assistance ------------------------------------------------------- You can contact Marc Linsner at: mlinsner@cisco.com The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ciscosales.webex.com/ciscosales/onstage/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. --B_3340700357_387681 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ECRIT WG Webex Event Attendee Info

Topic: IETF ECRIT WG Meeting
Host: Marc Linsner
Date and Time:
November 11, 2009 9:00 am, Japan Standard Time (Hiroshima, GMT+09:00)
Event number: 203 974 390
Event password: ietf

-------------------------------------------------------
To join the online event
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/onstage/g.= php?d=3D203974390&t=3Da&EA=3Dmarc.linsner%40cisco.com&ET=3D1b1d338249aa9= ffba4008e26c2713f2e&ETR=3D2d02741028dde2c562c926f271bffb10&RT=3DMiMxMQ=3D=3D= &p
2. Click "Join Now".

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------

1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.= com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
Cost Savings Tips and Tricks
-------------------------------------------------------

- Whenever possible, call the local number (if there is no charge to you). = http://www.cisco.com/web/about/doing_business/conferencing/index.html

- When using a U.S. cell phone in the United States, always call the local = number, otherwise the company is charged twice (once for the minutes and aga= in for the toll-free number).

- When staying in a hotel, dial the local number from your cell phone, have= the system call you, or use IP Communicator.

-------------------------------------------------------
For assistance
-------------------------------------------------------
You can contact Marc Linsner at:
mlinsner@cisco.com

The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meeti= ng, please check whether you have the players installed on your computer by = going to https://ciscosales.webex.com/ciscosales/= onstage/systemdiagnosis.php




http://www.webex.co= m

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session = to be recorded. By joining this session, you automatically consent to such r= ecordings. If you do not consent to the recording, do not join the session. =

--B_3340700357_387681-- From fluffy@cisco.com Tue Nov 10 14:44:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2013A6893 for ; Tue, 10 Nov 2009 14:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znycOAYjUHbZ for ; Tue, 10 Nov 2009 14:44:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6BD4428C140 for ; Tue, 10 Nov 2009 14:44:22 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEN7+UpAaHte/2dsb2JhbADGSYkpCY8Qgj8VgWoEgmA X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="48876997" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 22:44:48 +0000 Received: from tky-vpn-client-231-103.cisco.com (tky-vpn-client-231-103.cisco.com [10.70.231.103]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAMil1H028052; Tue, 10 Nov 2009 22:44:47 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <0913B6CD18F370498CD65864CF254E900B34C344@zharhxm1.corp.nortel.com> Date: Wed, 11 Nov 2009 07:44:47 +0900 Content-Transfer-Encoding: 7bit Message-Id: <89968107-66F2-43D5-8A52-1936BC107AFA@cisco.com> References: <0913B6CD18F370498CD65864CF254E900B1CA59D@zharhxm1.corp.nortel.com><47ED2AE6-6BD2-40AD-9E9F-B97A60538F4B@cisco.com> <0913B6CD18F370498CD65864CF254E900B34C344@zharhxm1.corp.nortel.com> To: Milan Patel X-Mailer: Apple Mail (2.1076) Cc: Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] New Version Notificationfor draft-patel-ecrit-sos-parameter-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:44:47 -0000 So if the register returns a 200, does the UA know that emergecny calls will work? Or could it mean that all calls will simply be meant with the message "sorry this subscriber is out of funds" On Nov 9, 2009, at 15:13 , Milan Patel wrote: > Hi Cullen, Keith, > > Note, this discussion has occurred before in the past and we > considered > that that option tags were not necessary. > > My understanding (and may be the draft is misleading but I don't think > so) is that the UA doesn't need to know that the network supports the > extension. It adds the "reg-type" in the REGISTER and if supported by > the registrar, the registrar will successfully register even in the > case > the identities are barred, for example. In the case the registrar does > not understand the parameter, there is a chance the registration > fails, > but in the case it is successful, the same 200 is returned to the UA. > > The UA uses this contact (returned in the 200 to the RGISTER) in the > emergency INVITE, but from a UA point of view, there is not special > reason for the UA to interpret the value. > > Legacy registrars would indeed just copy the URI parameter to the 200 > (OK) so the draft needs updating for that. > > Cheers, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 > Mobile +44 774 053 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to > act as > Insolvency Practitioners under section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants > authorises A > M Hudson to act as an Insolvency Practitioner under section 390(2) > (a) of > the Insolvency Act 1986. > > The affairs, business and property of the Companies are being > managed by > the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > who > act as agents of the Companies only and without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > Nortel > GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks > SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel > Networks > Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; > Nortel > Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania > SRL; > Nortel Networks AB; Nortel Networks International Finance & Holding BV > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 09 November 2009 04:27 > To: Cullen Jennings; ECRIT > Cc: Hannes Tschofenig > Subject: Re: [Ecrit] New Version Notificationfor > draft-patel-ecrit-sos-parameter-07 > > So just to be clear here. > > You are presumably proposing an option tag in addition to the new URI > parameter. > > Use of the option tag without the parameter would merely confirm that > the extension was supported. > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Cullen Jennings >> Sent: Friday, November 06, 2009 11:05 PM >> To: ECRIT >> Cc: Hannes Tschofenig >> Subject: Re: [Ecrit] New Version Notification for >> draft-patel-ecrit-sos-parameter-07 >> >> >> It was pointed out to me that some registrars that do not >> support the emergency registration will accept a contact with >> the sos parameter and will also return it in the 200. They >> just copy the data. Because of this, I don't think that >> detecting the parameter in the 200 is a sufficient way for >> the UA to know the registrar supports this mechanism. Due to >> it's importance for emergency calls, this seems like a real problem. >> >> My recommended fix to this would be to add a >> required/supported option tag. I realize this is not great >> news to many of the folks involved but from what I have >> heard, this does sounds like a problem. Glad to hear any >> ideas on how to get a solutions published quickly that meets >> 3GPPs requirements. >> >> Cullen >> >> >> On Oct 27, 2009, at 7:14 , Milan Patel wrote: >> >>> Hi Cullen, >>> >>> I have submitted a new version of draft-patel-ecrit-sos-parameter >>> >>> Latest changes are: >>> - clarification of use >>> - change of URI parameter name to "reg-type" which can have a value >>> - specifically for 3GPP's IMS emergency services solution, >> "reg-type" >>> takes the value "sos". >>> >>> - the URI parameter is extensible to allow other values to >> be used in >>> the future for other use cases where the registration type >> needs to be >>> explicitly identified to the registrar. >>> >>> I hope this helps in addressing the concerns that you and >> others had >>> about the previous version. >>> Due to the 3GPP release 7 dependency on this draft, I hope we can >>> reach consensus on this draft as soon as possible. >>> >>> Best regards, >>> Milan >>> >>> >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>> Sent: 26 October 2009 22:04 >>> To: Patel, Milan (MOP:EP10) >>> Subject: New Version Notification for draft-patel-ecrit-sos- >>> parameter-07 >>> >>> >>> >>> A new version of I-D, >> draft-patel-ecrit-sos-parameter-07.txt has been >>> successfuly submitted by Milan Patel and posted to the IETF >>> repository. >>> >>> Filename: draft-patel-ecrit-sos-parameter >>> Revision: 07 >>> Title: SOS Uniform Resource Identifier (URI) >> Parameter for >>> Marking of Session Initiation Protocol (SIP) Requests related to >>> Emergency Services >>> Creation_date: 2009-10-26 >>> WG ID: Independent Submission >>> Number_of_pages: 8 >>> >>> Abstract: >>> This document defines a new Session Initiation Protocol >> (SIP) Uniform >>> Resource Identifier (URI) parameter intended for marking SIP >>> registration requests related to emergency services. The URI >>> parameter is extensible to allow future values to be defined if >>> required by other use cases that require specific SIP >> registrations to >>> be distinctly identified. The usage of this new URI parameter >>> complements the usage of the Service Uniform Resource Name >> (URN) and >>> is not intended to replace it. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fluffy@cisco.com Tue Nov 10 16:17:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD943A6BBC for ; Tue, 10 Nov 2009 16:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lugBDCLYfJSE for ; Tue, 10 Nov 2009 16:17:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9EE293A6BB9 for ; Tue, 10 Nov 2009 16:17:07 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIeR+UpAaHte/2dsb2JhbADGHZhGhD4EgmA X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208";a="48904057" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 00:17:33 +0000 Received: from tky-vpn-client-231-55.cisco.com (tky-vpn-client-231-55.cisco.com [10.70.231.55]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB0HXJq010751 for ; Wed, 11 Nov 2009 00:17:33 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 09:17:33 +0900 Message-Id: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:17:08 -0000 So SIP allows INVITEs with or without an SDP offer. As we all realize, this adds ways to use SIP but it allowed both the fast setup when the offer was in an INVITE and it allowed SIP to gateway to many other protocols where one needed to have an INVITE with no offer. I have received complaints that Phone BCP currently profiles SIP to a subset of it by eliminating the option of an INVITE with no offer. I was wondering if there is a strong reason that this was needed in Phone BCP. Cullen From br@brianrosen.net Tue Nov 10 16:21:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED9E28C23D for ; Tue, 10 Nov 2009 16:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UseM8FUeci5W for ; Tue, 10 Nov 2009 16:21:07 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id EF1AD28C205 for ; Tue, 10 Nov 2009 16:21:06 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N80xd-0007Ei-Cy; Tue, 10 Nov 2009 18:21:21 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 10 Nov 2009 19:21:25 -0500 From: Brian Rosen To: Cullen Jennings , ECRIT Message-ID: Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: AcpiZOdIoE2m+C5bo0eiUNm7k34t3w== In-Reply-To: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:21:07 -0000 It's a mistake. I will fix it. I can roll a new version tomorrow if that would help. Brian On 11/10/09 7:17 PM, "Cullen Jennings" wrote: > > So SIP allows INVITEs with or without an SDP offer. As we all realize, > this adds ways to use SIP but it allowed both the fast setup when the > offer was in an INVITE and it allowed SIP to gateway to many other > protocols where one needed to have an INVITE with no offer. > > I have received complaints that Phone BCP currently profiles SIP to a > subset of it by eliminating the option of an INVITE with no offer. I > was wondering if there is a strong reason that this was needed in > Phone BCP. > > Cullen > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Tue Nov 10 16:22:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650F928C188 for ; Tue, 10 Nov 2009 16:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfm9Heq69W9Q for ; Tue, 10 Nov 2009 16:22:57 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7B67728C0EF for ; Tue, 10 Nov 2009 16:22:57 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:31605 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S69544AbZKKAXZ convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2009 18:23:25 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 18:23:24 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 11 Nov 2009 08:23:22 +0800 From: "Winterbottom, James" To: Cullen Jennings , ECRIT Date: Wed, 11 Nov 2009 08:23:20 +0800 Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: AcpiZI06lVhX5BTdSF+A9Sz7eOE4SAAAHWTA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> In-Reply-To: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:22:58 -0000 Hi Cullen, My thoughts on this stuff are that the more ways that you have of doing it the less chance you have of stuff interoperating. I would prefer to see the absolute minimum set that must be supported in phone BCP. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Wednesday, 11 November 2009 11:18 AM > To: ECRIT > Subject: [Ecrit] Question about phone BCP > > > So SIP allows INVITEs with or without an SDP offer. As we all realize, > this adds ways to use SIP but it allowed both the fast setup when the > offer was in an INVITE and it allowed SIP to gateway to many other > protocols where one needed to have an INVITE with no offer. > > I have received complaints that Phone BCP currently profiles SIP to a > subset of it by eliminating the option of an INVITE with no offer. I > was wondering if there is a strong reason that this was needed in > Phone BCP. > > Cullen > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fluffy@cisco.com Tue Nov 10 16:29:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D6C3A691A for ; Tue, 10 Nov 2009 16:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt3NJlfuFH3W for ; Tue, 10 Nov 2009 16:29:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 11AC93A683D for ; Tue, 10 Nov 2009 16:29:18 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOCT+UpAaHte/2dsb2JhbADGGJhHhD4EgmA X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208";a="48904740" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 00:29:45 +0000 Received: from tky-vpn-client-231-55.cisco.com (tky-vpn-client-231-55.cisco.com [10.70.231.55]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB0ThwZ014916; Wed, 11 Nov 2009 00:29:44 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: Date: Wed, 11 Nov 2009 09:29:43 +0900 Content-Transfer-Encoding: 7bit Message-Id: <4CED09F8-0504-425B-BF8E-57984C313445@cisco.com> References: To: "Brian Rosen" X-Mailer: Apple Mail (2.1076) Cc: ECRIT Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:29:47 -0000 On Nov 11, 2009, at 9:21 , Brian Rosen wrote: > It's a mistake. I will fix it. Thanks - if you can submit a new version before next monday, that would be great. > > I can roll a new version tomorrow if that would help. > > Brian > > > On 11/10/09 7:17 PM, "Cullen Jennings" wrote: > > > > > So SIP allows INVITEs with or without an SDP offer. As we all > realize, > > this adds ways to use SIP but it allowed both the fast setup when > the > > offer was in an INVITE and it allowed SIP to gateway to many other > > protocols where one needed to have an INVITE with no offer. > > > > I have received complaints that Phone BCP currently profiles SIP > to a > > subset of it by eliminating the option of an INVITE with no offer. I > > was wondering if there is a strong reason that this was needed in > > Phone BCP. > > > > Cullen > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > From MILANPA@nortel.com Tue Nov 10 17:28:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82463A69B9 for ; Tue, 10 Nov 2009 17:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hUn++j-lJnK for ; Tue, 10 Nov 2009 17:28:41 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B964C3A69A2 for ; Tue, 10 Nov 2009 17:28:39 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAB1T0u05915 for ; Wed, 11 Nov 2009 01:29:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA626E.586E05D9" Date: Wed, 11 Nov 2009 01:28:57 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900B3C51B4@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-patel-ecrit-sos-parameter Thread-Index: Acpiblaj/qOv/2MtQRKG1/LbfYbTOA== From: "Milan Patel" To: "ecrit" Subject: [Ecrit] draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:28:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA626E.586E05D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 Due to bad audio I didn't catch the conclusion on the draft and way forwards. My understanding is the group are fine with the change to reg-type.=20 =20 The thing I am unclear on is whether the explanations provided by Martin, Hannu and myself resulted in Cullen satisfied that option tags are required. OR do folks still find it useful to include option tags or at least some indicator in the 200 to inform the UA that the network supports the reg-type extension and that emergency registration was successful rather than the lack of support of the extension resulting in normal registration procedures applied.=20 =20 I'd appreciate a quick email with the conclusion in the meeting so I can inform 3GPP (we're in Beijing right now) of the discussion.=20 =20 Best regards, Milan =20 Milan Patel=20 Carrier Networks Core Standards=20 Nortel=20 milanpa@nortel.com=20 Telephone +44 162 843 2381 / ESN 560 2381=20 Mobile +44 774 053 9261 / ESN 748 9261=20 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV =20 ------_=_NextPart_001_01CA626E.586E05D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

Due to bad audio I didn't catch the conclusion on the draft and = way forwards.

My understanding is the group are fine with the change to = reg-type.

 

The thing I am unclear on is whether the explanations provided = by Martin, Hannu and myself resulted in Cullen satisfied that option tags = are required. OR do folks still find it useful to include option tags or at = least some indicator in the 200 to inform the UA that the network supports the reg-type extension and that emergency registration was successful rather = than the lack of support of the extension resulting in normal registration procedures applied.

 

I'd appreciate a quick email with the conclusion in the meeting = so I can inform 3GPP (we're in Beijing right now) of the discussion.

 

Best regards,

Milan

 

Milan Patel
Carrier Networks Core Standards
Nortel
milanpa@nortel.com
Telephone +44 162 843 2381 / ESN 560 2381
Mobile +44 774 053 9261 / ESN 748 9261 =

For = the Companies listed below, The Institute of Chartered Accountants in = England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to = act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act = 1986.

The = affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as = agents of the Companies only and without personal = liability.

The = Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel = Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel = Networks (Austria) = GmbH; = Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks = Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks = Romania SRL; Nortel Networks AB; Nortel Networks International Finance & = Holding BV

 

------_=_NextPart_001_01CA626E.586E05D9-- From bernard_aboba@hotmail.com Tue Nov 10 17:40:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6974E3A677E for ; Tue, 10 Nov 2009 17:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PhDH85Uh43r for ; Tue, 10 Nov 2009 17:40:40 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by core3.amsl.com (Postfix) with ESMTP id EA31D3A6BBB for ; Tue, 10 Nov 2009 17:40:39 -0800 (PST) Received: from BLU137-DS7 ([65.55.116.72]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 17:41:07 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'ECRIT'" Date: Tue, 10 Nov 2009 17:41:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA622D.00F3F9C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpicA6su24Zxn+bQ6KOYF92eTsy4w== Content-Language: en-us X-OriginalArrivalTime: 11 Nov 2009 01:41:07.0175 (UTC) FILETIME=[09AE2F70:01CA6270] Subject: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:40:50 -0000 ------=_NextPart_000_0007_01CA622D.00F3F9C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 6 " signalling allows an IEEE 802.1X to occur without exchanging cryptogrpahic keys" [BA] Not sure what this is saying. In IEEE 802.1X-2004, there is no encryption supported. However, EAP is still run. This can include methods that don't generate keys (e.g. EAP-MD5). But the issue here is client unauthenticated access, not key generation, right? Section 6.1 " In general, link layer emergency indications provide good integration into the actual network access procedure regarding the enabling of means to recognize and prioritize an emergency service request from an end host at a very early stage of the network attachment procedure. However, support in end hosts for such methods cannot be considered to be commonly available. " [BA] I'm not sure what this is referring to. If it's referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA WMM). If it's talking about higher layer emergency service prioritization, that's also independent of the lower layer. So what exactly is a host expected to do at the lower layer to distinguish an emergency call? Section 6.2 "In normal operation, EAP related information will only be recognized in the NAS. Any entity residing between end host and NAS should not be expected to understand/parse EAP messages. " [BA] The EAP architecture requires the NAS to be EAP-method agnostic if it's acting as a pass-through. So even the NAS can't be depended upon to understand/parse EAP methods. But why would it need to? " 1.b) Emergency NAI: The NAI comes with a realm or username part indicating emergency (e.g. 'emergency@emergency.com'). An advantage of this method for NAA cases is that no new requirements are put on the involved signaling procedures. Only the identity used for network entry is impacted. Potential disadvantages include that different methods to indicate emergency for NAA cases and standard emergency network attachments may be required. Also, modifying the NAI itself (the username@realm part) may conflict with network selection and network entry procedures, depending on the actual access network. " [BA] There are two distinct ideas being presented here. One is to define an emergency user name (e.g. "emergency"); another is to define an emergency domain (e.g. "emergency.com"). The former concept may make sense, but the latter one is dangerous since existing systems not including the emergency realm in their routing tables may just return an error. So the question is what realm should be used, if any. The problem with including any realm is that it assumes realm reachability. If reachability doesn't exist, then the host will get an error. If there is no realm, then the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access. " 2) Emergency EAP method An emergency indication can be given by using a dedicated EAP method that is reserved for emergency network attachment only. " [BA] Why is a dedicated EAP method needed for emergency access? EMU WG has already discussed this and come up with mechanisms that would allow client unauthenticated access from any TLS-based method (e.g. server side either doesn't ask for a client cert, or accepts the client not providing one). That mechanism is supported in RFC 5216, and can also be applied to existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc. In effect, the only real constraint here is that a local network advertising support for emergency calling needs to support one or more of these methods. " 2.a) Existing EAP method with new type: An existing EAP method may be used. EAP methods themselves typically do not support emergency indication. One option would be to pick a common EAP method like EAP-TLS and allocate a new method type for the same method that is exclusively reserved to emergency use. Such EAP method should be chosen in a way that the same method can support NAA cases as well as standard emergency network attachment. " Given that RFC 5216 already supports client-unauthenticated anonymous access (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a new method type? " 2.b) Existing EAP method: Same as 2a), but without assigning a new EAP method type for emergency. In this case some implicit indication must be used. For example, in cases where EAP-TLS is used in network attachment in combination with client certificates, the absence of a client certificate could be interpreted by the network as a request for emergency network attachment. " [BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency attachment. If an NAI corresponding to an existing account is used, then normal policies will apply (which would probably require authenticated access). " 2.c) Emergency EAP method: A new EAP method could be defined that is specifically designed for emergency network entry in NAA cases. Most likely, such EAP method would not be usable for standard emergency network attachment with an existing subscription. Such dedicated emergency EAP method should be key-generating in compliance with RFC3748 to enable the regular air interface security methods even in unauthenticated operation. " [BA] Since any TLS-based method can potentially support client-unauthenticated access, it's not clear to me that there is a good case for creating yet another method. Section 6.3 " Therefore, for network attachment that is by default based on EAP authentication it is desirable also for NAA network attachment to use a key-generating EAP method (that provides an MSK key to the authenticator to bootstrap further key derivation for protecting the wireless link). " [BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you don't really have a choice. " 2) Null authentication: an EAP method is performed. However, no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly available static key for emergency access could be used. In the latter case, the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. " [BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only uses the 4-way handshake, not EAP. " 3) Device authentication: This case extends the server-only authentication case. If the device is configured with a device certificate and the IAP/ISP EAP server can rely on a trusted root allowing the EAP server to verify the device certificate, at least the device identity (e.g. the MAC address) can be authenticated by the IAP/ISP in NAA cases. An example for this are WiMAX devices that are shipped with device certificates issued under the global WiMAX device public-key infrastructure. To perform unauthenticated emergency calls, if allowed by the IAP/ISP, such devices perform EAP- TLS based network attachment with client authentication based on the device certificate. " IEEE 802.1ar might also be an example of this. ------=_NextPart_000_0007_01CA622D.00F3F9C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Section =
6
 
“   =
signalling allows an IEEE 802.1X to occur without =
exchanging

   cryptogrpahic keys”

 

[BA] Not sure what this is saying.  In IEEE 802.1X-2004, there is no = encryption supported.  However, EAP is still run.  This can include = methods that don’t generate keys (e.g. EAP-MD5).  But the issue here is = client unauthenticated access, not key generation, right? =

 

Section 6.1

 

“   In general, link layer emergency indications =
provide good integration
   into the =
actual network access procedure regarding the enabling =
of
   means to recognize and prioritize =
an emergency service request from
   an =
end host at a very early stage of the network =
attachment
   procedure.  However, =
support in end hosts for such methods cannot =
be
   considered to be commonly =
available.

”

 

[BA] I’m not sure what this is referring to.  If it’s = referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA WMM).  If it’s talking about higher layer emergency service prioritization, that’s also independent of the lower layer.  = So what exactly is a host expected to do at the lower layer to distinguish an = emergency call?  

 

Section 6.2

 

“In normal operation, EAP =
related
   information will only be =
recognized in the NAS.  Any entity =
residing
   between end host and NAS =
should not be expected to =
understand/parse
   EAP =
messages.

”

 

[BA] The EAP architecture requires the NAS to be EAP-method agnostic if = it’s acting as a pass-through.  So even the NAS can’t be depended = upon to understand/parse EAP methods.  But why would it need to? =

 

“   1.b) Emergency NAI: The NAI comes with a realm =
or username part
   indicating emergency =
(e.g. 'emergency@emergency.com').  An =
advantage
   of this method for NAA cases =
is that no new requirements are put on
   =
the involved signaling procedures.  Only the identity used =
for
   network entry is impacted.  =
Potential disadvantages include that
   =
different methods to indicate emergency for NAA cases and =
standard
   emergency network attachments =
may be required.  Also, modifying =
the
   NAI itself (the username@realm =
part) may conflict with network
   =
selection and network entry procedures, depending on the =
actual
   access =
network.

”

 

[BA] There are two distinct ideas being presented here.  One is to = define an emergency user name (e.g. “emergency”); another is to define = an emergency domain (e.g. “emergency.com”).  The former = concept may make sense, but the latter one is dangerous since existing systems = not including the emergency realm in their routing tables may just return an error.  So the question is what realm should be used, if any.  = The problem with including any realm is that it assumes realm = reachability.  If reachability doesn’t exist, then the host will get an = error.  If there is no realm, then the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access.

 

“   2) Emergency EAP =
method
 
   An =
emergency indication can be given by using a dedicated EAP =
method
   that is reserved for emergency =
network attachment only.

”

 

[BA] Why is a dedicated EAP method needed for emergency access?  EMU WG = has already discussed this and come up with mechanisms that would allow = client unauthenticated access from any TLS-based method (e.g. server side = either doesn’t ask for a client cert, or accepts the client not providing one).  = That mechanism is supported in RFC 5216, and can also be applied to existing = methods such as EAP FAST, EAP TTLSv0, PEAP, etc.

 

In effect, the only real constraint here is that a local network = advertising support for emergency calling needs to support one or more of these = methods. 

 

“   2.a) Existing EAP method with new type: An =
existing EAP method may be
   used.  =
EAP methods themselves typically do not support =
emergency
   indication.  One option =
would be to pick a common EAP method =
like
   EAP-TLS and allocate a new method =
type for the same method that is
   =
exclusively reserved to emergency use.  Such EAP method should =
be
   chosen in a way that the same =
method can support NAA cases as well =
as
   standard emergency network =
attachment.
 

”

 

Given that RFC 5216 already supports client-unauthenticated anonymous access = (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a = new method type?

 

“   2.b) Existing EAP method: Same as 2a), but =
without assigning a new
   EAP method =
type for emergency.  In this case some implicit =
indication
   must be used.  For =
example, in cases where EAP-TLS is used in =
network
   attachment in combination with =
client certificates, the absence of a
   =
client certificate could be interpreted by the network as a =
request
   for emergency network =
attachment.

”

 

[BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency = attachment.  If an NAI corresponding to an existing account is used, then normal policies = will apply (which would probably require authenticated access). =

 

“   2.c) Emergency EAP method: A new EAP method =
could be defined that is
   specifically =
designed for emergency network entry in NAA cases.  =
Most
   likely, such EAP method would not =
be usable for standard emergency
   =
network attachment with an existing subscription.  Such =
dedicated
   emergency EAP method should =
be key-generating in compliance with
   =
RFC3748 to enable the =
regular air interface security methods even =
in
   unauthenticated =
operation.

”

 

[BA] Since any TLS-based method can potentially support = client-unauthenticated access, it’s not clear to me that there is a good case for = creating yet another method.

 

Section 6.3

 

“   Therefore, for network attachment that is by =
default based on EAP
   authentication it =
is desirable also for NAA network attachment to =
use
   a key-generating EAP method (that =
provides an MSK key to the
   =
authenticator to bootstrap further key derivation for protecting =
the
   wireless link).

”

 

[BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you = don’t really have a choice. 

 

“   2) Null authentication: an EAP method is =
performed.  However, no
   =
credentials specific to either the server or the device =
or
   subscription are used as part of =
the authentication exchange.  An
   =
example for this would be an EAP-TLS exchange with using =
the
   TLS_DH_anon (anonymous) =
ciphersuite.  Alternatively, a =
publicly
   available static key for =
emergency access could be used.  In =
the
   latter case, the device would need =
to be provisioned with the
   appropriate =
emergency key for the IAP/ISP in =
advance.
 

”

 

[BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only uses = the 4-way handshake, not EAP.

 

“   3) Device authentication: This case extends the =
server-only
   authentication case.  =
If the device is configured with a =
device
   certificate and the IAP/ISP EAP =
server can rely on a trusted root
   =
allowing the EAP server to verify the device certificate, at =
least
   the device identity (e.g. the =
MAC address) can be authenticated by
   =
the IAP/ISP in NAA cases.  An example for this are WiMAX devices =
that
   are shipped with device =
certificates issued under the global =
WiMAX
   device public-key =
infrastructure.  To perform =
unauthenticated
   emergency calls, if =
allowed by the IAP/ISP, such devices perform =
EAP-
   TLS based network attachment with =
client authentication based on the
   =
device certificate.

”

 

IEEE 802.1ar might also be an example of this.

------=_NextPart_000_0007_01CA622D.00F3F9C0-- From Ray.Bellis@nominet.org.uk Tue Nov 10 18:17:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C52628C266 for ; Tue, 10 Nov 2009 18:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POVXmgGPNifY for ; Tue, 10 Nov 2009 18:17:03 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id BFA4328C26C for ; Tue, 10 Nov 2009 18:17:02 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=m1qfHgjqu7WkfZRshdDTAVPZMtL+FeoVca4WnJ2wMpjgtRNoBqbztncf vyNMATqnWTVdjb+rcGfTV3VA+yjmbbG+c7g8dWSyvQqvY+2e2W8oFVDji hanLGgCa9Bep9tB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257905851; x=1289441851; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Direct=20ac cess=20-=20the=20"normal"=20call-path|Date:=20Wed,=2011 =20Nov=202009=2011:17:27=20+0900|Message-ID:=20|To:=20ecrit=20|MIME-Version:=201. 0; bh=fJUEEy44rjo89f9ApbIqFzr6qFwNHqb9jV42b3ejRqQ=; b=pwv08M8Cqg1KVNVa93itk5rY1fszKvBRE9HD9bU28AoSCB2DRfanon2o YbKuIEk+Nn9VSuAmtXjOk1R2rfKbPSf4x1CUpMYAXGogNU9HsR5+5ypwY t5dI3KTxu+Jeba1; X-IronPort-AV: E=Sophos;i="4.44,719,1249254000"; d="scan'208";a="19296915" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 11 Nov 2009 02:17:29 +0000 To: ecrit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 11 Nov 2009 11:17:27 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/11/2009 02:17:28 AM, Serialize complete at 11/11/2009 02:17:28 AM Content-Type: multipart/alternative; boundary="=_alternative 000C94F84925766B_=" Subject: [Ecrit] Direct access - the "normal" call-path X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:17:04 -0000 This is a multipart message in MIME format. --=_alternative 000C94F84925766B_= Content-Type: text/plain; charset="US-ASCII" Regarding Brian's comments in the WG session - Our corporate PBX does *not* have a subscription to a SIP VSP, and as far as I know never will. Our "normal" call-path for any SIP URI is to send the call *direct* to the SIP server listed in the domain's SRV records. If we had to follow the "use a VSP" rule then the only fallback for us would be to send the call over the PSTN, which rather defeats the point. In the UK the partial integration of PSAPs into the VoIP world is currently only possible because the number of VSPs with direct PSTN interconnect is very limited (< 20, AFAIK) and because in the interim all ES calls arrive over PSTN. The remaining VSPs that only have IP connectivity number in the several hundreds. Since (as above) ES calls have to go over the PSTN they then have to route the call via one of the 20 that does have PSTN interconnect. We've *already* got a scale problem - it's not feasible for the PSAPs to recognise all of the existing UK-based VSPs, let alone the many thousands more that lie outside of our national jurisdiction. Given these circumstances ECRIT-direct makes a lot of sense, IMHO. Ray --=_alternative 000C94F84925766B_= Content-Type: text/html; charset="US-ASCII" Regarding Brian's comments in the WG session -

Our corporate PBX does *not* have a subscription to a SIP VSP, and as far as I know never will.

Our "normal" call-path for any SIP URI is to send the call *direct* to the SIP server listed in the domain's SRV records.

If we had to follow the "use a VSP" rule then the only fallback for us would be to send the call over the PSTN, which rather defeats the point.

In the UK the partial integration of PSAPs into the VoIP world is currently only possible because the number of VSPs with direct PSTN interconnect is very limited (< 20, AFAIK) and because in the interim all ES calls arrive over PSTN.  

The remaining VSPs that only have IP connectivity number in the several hundreds.  Since (as above) ES calls have to go over the PSTN they then have to route the call via one of the 20 that does have PSTN interconnect.

We've *already* got a scale problem - it's not feasible for the PSAPs to recognise all of the existing UK-based VSPs, let alone the many thousands more that lie outside of our national jurisdiction.

Given these circumstances ECRIT-direct makes a lot of sense, IMHO.

Ray
--=_alternative 000C94F84925766B_=-- From Ray.Bellis@nominet.org.uk Tue Nov 10 18:28:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56DE28C275 for ; Tue, 10 Nov 2009 18:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioIY-LGZfEa4 for ; Tue, 10 Nov 2009 18:28:36 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id C3C9928C271 for ; Tue, 10 Nov 2009 18:28:35 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=RXJrPTS4OxZ6UP6t8J6t2uUypVbtdLy78AMvGRCUaTccxLqf8voH3KEz lABM2yuWaVqxakTWu3RZo+4+eY3MZIU1Ejiz+RUlYJK4wE+uu6zcOPmos joHniI8cGsfg4Si; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1257906544; x=1289442544; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Direct=20access=20-=20the=20"normal"=20call-path |Date:=20Wed,=2011=20Nov=202009=2011:28:59=20+0900 |Message-ID:=20|To:=20ecrit=20|MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=HnLbVcqrz2q/PE4ZCwV09TocZzhquekEgl8cBuhApZ0=; b=5M/Em0Hun8q6G4lIXJYSJHEUxC3/d1D3KJbouVnIoLAn6HDaJ9x3eJSc 4b09x8luhbW6d6wXw5FTcNsqDS225A2+qcjGySX/rJlo9Se9d/ui+XpUI 2C8oeWzVCOyWsiX; X-IronPort-AV: E=Sophos;i="4.44,720,1249254000"; d="scan'208";a="19297344" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 11 Nov 2009 02:29:02 +0000 In-Reply-To: References: To: ecrit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 11 Nov 2009 11:28:59 +0900 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/11/2009 02:29:02 AM, Serialize complete at 11/11/2009 02:29:02 AM Content-Type: multipart/alternative; boundary="=_alternative 000DA38D4925766B_=" Subject: Re: [Ecrit] Direct access - the "normal" call-path X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:28:36 -0000 This is a multipart message in MIME format. --=_alternative 000DA38D4925766B_= Content-Type: text/plain; charset="US-ASCII" I should clarify (insufficient sleep last night) - Most of what I just wrote relates to a *future* world where the UK PSAPs are IP-connected. That's when we'd really have the scale problem that ECRIT-direct (indirectly) resolves, in-so-much as ECRIT-direct fixes the VSP-trust network scaling problem by implicitly trusting *everybody*. At the moment it's moot because in the interim all ES calls have to go over the PSTN anyway. Ray --=_alternative 000DA38D4925766B_= Content-Type: text/html; charset="US-ASCII" I should clarify (insufficient sleep last night) -

Most of what I just wrote relates to a *future* world where the UK PSAPs are IP-connected.  That's when we'd really have the scale problem that ECRIT-direct (indirectly) resolves, in-so-much as ECRIT-direct fixes the VSP-trust network scaling problem by implicitly trusting *everybody*.

At the moment it's moot because in the interim all ES calls have to go over the PSTN anyway.

Ray
--=_alternative 000DA38D4925766B_=-- From Hannes.Tschofenig@gmx.net Tue Nov 10 19:29:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2343A6A37 for ; Tue, 10 Nov 2009 19:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arK+sV33nRqP for ; Tue, 10 Nov 2009 19:29:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EBD073A6878 for ; Tue, 10 Nov 2009 19:29:14 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 03:29:40 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp022) with SMTP; 11 Nov 2009 04:29:40 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4qys+00b4p3cqAOJD5oN6DqvyE9wY+9MeN2/ji8 RH+rGl++Ro04sB From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 12:32:54 +0900 Message-ID: <003a01ca627f$aa20b7c0$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpif6eTyVJfj1JqTp6H11feibyskg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] LoST Revision is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:29:16 -0000 Hi all, During the meeting today we discussed the way for addressing bugs in the LoST specification. Cullen suggested to use the RFC Errata process for doing that. This is an good idea! For extensions I suggest to write separate documents and to extend LoST in the already envisioned way. Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:39:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669853A6A1C for ; Tue, 10 Nov 2009 20:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz1haEQSWRS7 for ; Tue, 10 Nov 2009 20:39:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 22DA13A6942 for ; Tue, 10 Nov 2009 20:39:28 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:39:54 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp011) with SMTP; 11 Nov 2009 05:39:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4ER4jQZK4vTZF+6x+0CwSsE1BmL+DNtPhWTLpnw 8WvXjfh6zl4ujm From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:43:12 +0900 Message-ID: <003d01ca6289$7a19c030$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiiXliLmp4fRICQPG6NZs7l26rug== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: [Ecrit] AI for PSAP Callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:39:30 -0000 We are at a point with this document were we need a discussion about the individual solution approaches. I will propose a list of possible solutions and we will figure out what the pros and cons are with respect to the individual solutions. I am planning to use our WG wiki: http://trac.tools.ietf.org/wg/ecrit/trac/wiki/WikiStart Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:39:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543CC3A6B8A for ; Tue, 10 Nov 2009 20:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeDIEbRK+5Gj for ; Tue, 10 Nov 2009 20:39:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 182043A687B for ; Tue, 10 Nov 2009 20:39:26 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:39:52 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp011) with SMTP; 11 Nov 2009 05:39:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9+Ehq1xi9vPoxHzjyANYzOI01zgS/ML68020P+M Kczq+Q2FDcZsmL From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:43:06 +0900 Message-ID: <003c01ca6289$78a102e0$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiiXXf4uY82OH/Rd6g7oiyXxg45A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: [Ecrit] AI for LoST Sync X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:39:32 -0000 Hi all, based on the feedback during the meeting we will add some text to the security consideration section describing the potential problems caused by misconfiguration or attacks. Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:39:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DCF28C267 for ; Tue, 10 Nov 2009 20:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw7d9VpS7GoK for ; Tue, 10 Nov 2009 20:39:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A6FAC28C266 for ; Tue, 10 Nov 2009 20:39:48 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:40:14 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp011) with SMTP; 11 Nov 2009 05:40:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+L4/BaZVCLxyl7IkJTBfCOuha3zwmQSKCBWU0zXW dAnkFCMaUe63oe From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:43:28 +0900 Message-ID: <003e01ca6289$85eb4370$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiiYL+qwhT8+0KQR+wNBB3ZCIKAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] AI for Service URN Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:39:50 -0000 Hi all, Cullen forwarded feedback from the IESG back to the group and the main concern with the document is that it currently only defines the change of the policy but does not give any guidelines to the expert reviewer on what would be acceptable entries. When considering the registry defined in http://tools.ietf.org/html/draft-forte-ecrit-service-classification-02 one can easily imagine a huge number of items being registered and it is unclear on what is acceptable and what not. Cullen further pointed out that the APPS area has tried to tackle this space before and failed. Hence, the request was made to the group to find groups with an expertise about this topic and whether something could be imported/re-used from there. Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:40:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97EE3A6942 for ; Tue, 10 Nov 2009 20:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqdbRrdrwQAZ for ; Tue, 10 Nov 2009 20:40:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 982923A687B for ; Tue, 10 Nov 2009 20:40:17 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:40:43 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp072) with SMTP; 11 Nov 2009 05:40:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/JjWIS5rDJVTnsLdaUlhMPB/xYOOkg6ZrHGsMWrp /Yft6jXxvA2KaR From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:43:55 +0900 Message-ID: <003f01ca6289$972ab300$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiiZMPIEjUTzm4Qx2AFJufnp5MQg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001 Subject: [Ecrit] AI for SOS Parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:40:18 -0000 During the meeting we had a discussion about the error cases for the SOS parameter document. Here is the issue. What happens if a SIP UA uses the parameter defined in this document but contacts a registrar that does not understand this extension. The fear was the mechanism defined in this document leads to undesireable outcome. Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:41:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BB93A6942 for ; Tue, 10 Nov 2009 20:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn3AzQZIir5P for ; Tue, 10 Nov 2009 20:41:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2B30A3A687B for ; Tue, 10 Nov 2009 20:41:24 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:41:51 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp069) with SMTP; 11 Nov 2009 05:41:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vUz8d+tAvd9Pt+Um6hLvI7Wp5ARF6gyD7uqGFGr N5SlwqAhVKdj2m From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:45:05 +0900 Message-ID: <004101ca6289$bf80a080$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:41:26 -0000 We had a lot of discussion on this topic on the list and during the meeting. There are two issues: A) The technical aspects of how to deal with SIP signaling exchanges when there is no VSP/ASP involved. As I mentioned in my other mail there is a relationship to the work in the unauthenticated draft. B) Deployment policy on whether calls would be routed with or without (the Xbox example) involvement of the VSP in the emergency call exchange. There are regulatory issues, migration aspects, and many security challenges involved. I believe we need a solution for (A). The hard part is (B): Making progress on (B) will be impacted by our judgement of trustworthy location vs. the value of identity, as discussed in http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-02.txt. So, I suggest to finally get our head around this issue first. Other suggestions? Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:41:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F673A6A1C for ; Tue, 10 Nov 2009 20:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4-yEsmeXWA7 for ; Tue, 10 Nov 2009 20:41:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4C8BB3A6BFF for ; Tue, 10 Nov 2009 20:41:29 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:41:55 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp069) with SMTP; 11 Nov 2009 05:41:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18mfckOzsMmeWgYTs6f/hw/VvvC1/M5M2lOCm6UoE z6A3+iT1V4TP+Y From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:45:12 +0900 Message-ID: <004201ca6289$c1eee160$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiicEdDmWcJqFNR++NjdoPuA2/Rw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 Subject: [Ecrit] AI for Data-Only Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:41:30 -0000 draft-rosen-ecrit-data-only-ea-00.txt describes a solution for conveying a CAP message in a SIP MESSAGE. There is one big open issue in the document: How do we carry location information in or attached to the CAP message (since CAP does not carry what we need with respect to location information). So, we will need a discussion of what could be sensible to do. Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Nov 10 20:41:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286033A687B for ; Tue, 10 Nov 2009 20:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Hqhzwu3OTv for ; Tue, 10 Nov 2009 20:41:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3A28A3A67A3 for ; Tue, 10 Nov 2009 20:41:56 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:42:22 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp061) with SMTP; 11 Nov 2009 05:42:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19pFmYN5appBjCYLgWxqozXO6U0kZL8s8cUnRkPwq F6IjWQPZ+2RJyk From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:45:35 +0900 Message-ID: <004301ca6289$d1bf57a0$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpiic7jLtE22JuAQ/+ESPpAEy8c2g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] ECRIT Meeting Notes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:41:57 -0000 Please take a look at the meeting notes: http://www.ietf.org/proceedings/09nov/minutes/ecrit.txt Thanks Spencer for taking notes and for making them available so quickly. Ciao Hannes From James.Winterbottom@andrew.com Tue Nov 10 20:46:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996F43A6942 for ; Tue, 10 Nov 2009 20:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQOqf4YrGQWY for ; Tue, 10 Nov 2009 20:46:52 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id CD38E3A68E3 for ; Tue, 10 Nov 2009 20:46:52 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:20045 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087001AbZKKErU convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2009 22:47:20 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 22:47:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 12:47:17 +0800 From: "Winterbottom, James" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 11 Nov 2009 12:47:15 +0800 Thread-Topic: [Ecrit] AI for ECRIT Direct Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUAAABdSw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> References: <004101ca6289$bf80a080$4b725d85@nsnintra.net> In-Reply-To: <004101ca6289$bf80a080$4b725d85@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:46:53 -0000 Hi Hannes, I don't believe that the trustworthy location element comes into play here. I believe that there is a relationship between this and the unauthenticated draft, but only in some scenarios, certainly not all scenarios. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Wednesday, 11 November 2009 3:45 PM > To: ecrit@ietf.org > Subject: [Ecrit] AI for ECRIT Direct > > We had a lot of discussion on this topic on the list and during the > meeting. > > > There are two issues: > > A) The technical aspects of how to deal with SIP signaling exchanges when > there is no VSP/ASP involved. As I mentioned in my other mail there is a > relationship to the work in the unauthenticated draft. > > B) Deployment policy on whether calls would be routed with or without (the > Xbox example) involvement of the VSP in the emergency call exchange. There > are regulatory issues, migration aspects, and many security challenges > involved. > > I believe we need a solution for (A). The hard part is (B): Making > progress > on (B) will be impacted by our judgement of trustworthy location vs. the > value of identity, as discussed in > http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location- > 02.txt. > So, I suggest to finally get our head around this issue first. > > Other suggestions? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Tue Nov 10 20:47:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00B83A68E3 for ; Tue, 10 Nov 2009 20:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYx3cOmq-Ei4 for ; Tue, 10 Nov 2009 20:47:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8ADA43A6924 for ; Tue, 10 Nov 2009 20:47:00 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 04:40:46 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp072) with SMTP; 11 Nov 2009 05:40:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CL5JnBedC18cuLRCmVMvDx4kT78okbw7x4bzZj3 +JZkwQwsgNoYNe From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 13:44:02 +0900 Message-ID: <004001ca6289$98788fc0$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiiZZW7e7NwR6OTdS0nidmov/K1A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Subject: [Ecrit] AI for Unauthenticated Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:47:02 -0000 There are two aspects that need to get worked out: * SIP signaling interaction when there is no VSP involved. This is the space where we should accomplish an alignment with ECRIT Direct. * Network Access Authentication Procedure During this IETF meeting we had a discussion about this aspect in ECRIT and in EMU. A discussion about the topic is in the document itself with the recent update and I believe it would be good to produce a recommendation/solution (most likely in interaction with the EMU group). I furthermore suggest to separate the two issues and to work on them independently as the do not overlap. One document would deal with the terminology and the description of the network access authentication and authorization procedures. Then, a separate document would deal with SIP signaling in the lack of a VSP (as this may have wider applicability). Feedback? From Martin.Thomson@andrew.com Tue Nov 10 20:50:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E93C3A6B05 for ; Tue, 10 Nov 2009 20:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3HGNmLPaqbG for ; Tue, 10 Nov 2009 20:50:06 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 6DDB63A6AB8 for ; Tue, 10 Nov 2009 20:50:06 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:28175 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087029AbZKKEue (ORCPT ); Tue, 10 Nov 2009 22:50:34 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 22:50:34 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 12:50:31 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 11 Nov 2009 12:51:01 +0800 Thread-Topic: [Ecrit] AI for SOS Parameter Thread-Index: AcpiiZMPIEjUTzm4Qx2AFJufnp5MQgAACrEg Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E544C@SISPE7MB1.commscope.com> References: <003f01ca6289$972ab300$4b725d85@nsnintra.net> In-Reply-To: <003f01ca6289$972ab300$4b725d85@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] AI for SOS Parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:50:07 -0000 U3BlY2lmaWNhbGx5OiAgdGhlIGRldmljZSBkb2VzIG5vdCBrbm93IHRoYXQgdGhlIHJlZ2lzdHJh ciB1bmRlcnN0b29kIHRoZSBwYXJhbWV0ZXIuDQoNClRleHQgaXMgZGVzaXJlZCB0aGF0IHdpbGwg ZG9jdW1lbnQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBtYWtpbmcgaXQgY2xlYXJlciB0aGF0IHRo ZSBwdXJwb3NlIG9mIHRoZSBwYXJhbWV0ZXIgaXMgZm9yIHRoZSBjb25zdW1wdGlvbiBvZiB0aGUg cmVnaXN0cmFyIG9ubHkgLSBzbyB0aGF0IGl0IGNhbiBhcHBseSBkaWZmZXJlbnQgcG9saWN5IChp LmUuIGFsbG93IHRoZSByZWdpc3RyYXRpb24gZXZlbiB0aG91Z2ggdGhlIHVzZXIgbWlnaHQgbm90 IGJlIGZ1bGx5IHBhaWQgdXApLg0KDQpDdWxsZW4ncyBjb25jZXJuIHJlbGF0ZXMgdG8gd2hldGhl ciB0aGlzIGlzIGEgZGVzaXJhYmxlIGF0dHJpYnV0ZSBvZiB0aGUgc29sdXRpb24gYW5kIHdoZXRo ZXIgdGhlcmUgbWlnaHQgYmUgY2FzZXMgd2hlcmUgdGhlIGRldmljZSBjb3VsZCBiZSBnaXZlbiBh IGZhbHNlIGltcHJlc3Npb246DQoNClRoZSBzcGVjaWZpYyBzY2VuYXJpbyBpcyB3aGVyZSB0aGUg cmVnaXN0cmF0aW9uIGlzIGFjY2VwdGVkIGJ5IGEgcmVnaXN0cmFyIHRoYXQgZG9lcyBub3Qgc3Vw cG9ydCB0aGUgZXh0ZW5zaW9uLiAgSWYgdGhlIFVBIHRoZW4gYXNzdW1lcyB0aGF0IC0gYmVjYXVz ZSBpdHMgZW1lcmdlbmN5IHJlZ2lzdHJhdGlvbiB3YXMgYWNjZXB0ZWQgLSB0aGF0IGFuIGVtZXJn ZW5jeSBjYWxsIHdpbGwgYmUgcGVybWl0dGVkLCB0aGUgbmV0IGVmZmVjdCBtaWdodCBiZSBhIGZh aWxlZCBlbWVyZ2VuY3kgY2FsbC4NCg0KSSdtIG5vdCBvdmVybHkgY29uY2VybmVkIGFib3V0IHRo aXMgcHJvYmxlbSAtIGFzIGxvbmcgYXMgd2UgbWFrZSBpdCBjbGVhciB0aGF0IGEgY2FsbCBpcyBu b3QgZ3VhcmFudGVlZCB0byB3b3JrIGlmIHRoZSByZWdpc3RyYXRpb24gc3VjY2VlZHMsIGZvciBt YW55IHJlYXNvbnMsIGluY2x1ZGluZyB0aGUgc29ydHMgb2YgcG9saWN5IHRoaW5ncyB0aGF0IHRo aXMgZW1lcmdlbmN5IHJlZ2lzdHJhdGlvbiBpcyBpbnRlbmRlZCB0byB3YXZlIGFzaWRlLg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSGFubmVz IFRzY2hvZmVuaWcNCj4gU2VudDogV2VkbmVzZGF5LCAxMSBOb3ZlbWJlciAyMDA5IDE6NDQgUE0N Cj4gVG86IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFtFY3JpdF0gQUkgZm9yIFNPUyBQYXJh bWV0ZXINCj4gDQo+IER1cmluZyB0aGUgbWVldGluZyB3ZSBoYWQgYSBkaXNjdXNzaW9uIGFib3V0 IHRoZSBlcnJvciBjYXNlcyBmb3IgdGhlDQo+IFNPUw0KPiBwYXJhbWV0ZXIgZG9jdW1lbnQuDQo+ IA0KPiBIZXJlIGlzIHRoZSBpc3N1ZS4NCj4gDQo+IFdoYXQgaGFwcGVucyBpZiBhIFNJUCBVQSB1 c2VzIHRoZSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50DQo+IGJ1dA0KPiBjb250 YWN0cyBhIHJlZ2lzdHJhciB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhpcyBleHRlbnNpb24u IFRoZSBmZWFyDQo+IHdhcw0KPiB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCBsZWFkcyB0byB1bmRlc2lyZWFibGUgb3V0Y29tZS4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBF Y3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo= From Martin.Thomson@andrew.com Tue Nov 10 20:54:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6448A3A687B for ; Tue, 10 Nov 2009 20:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LdeCN1F0nkM for ; Tue, 10 Nov 2009 20:54:46 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id A5E163A67AF for ; Tue, 10 Nov 2009 20:54:18 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:50253 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087107AbZKKEyq (ORCPT ); Tue, 10 Nov 2009 22:54:46 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 22:54:46 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 12:54:43 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 11 Nov 2009 12:55:15 +0800 Thread-Topic: [Ecrit] AI for Data-Only Emergency Calls Thread-Index: AcpiicEdDmWcJqFNR++NjdoPuA2/RwAAQEQw Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E5450@SISPE7MB1.commscope.com> References: <004201ca6289$c1eee160$4b725d85@nsnintra.net> In-Reply-To: <004201ca6289$c1eee160$4b725d85@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] AI for Data-Only Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:54:47 -0000 SSBzdWdnZXN0ZWQgdGhhdCB3ZSBhbHJlYWR5IGhhdmUgYSBtZWNoYW5pc20gZm9yIHRoaXMgYW5k IHRoYXQgdGhlcmUgd2Fzbid0IGFueSBuZWVkIGZvciBjaGFuZ2UuICBCcmlhbiBleHByZXNzZWQg dGhlIGRlc2lyZSB0aGF0IHRoZSBsb2NhdGlvbiB1c2VkIGZvciByb3V0aW5nIHRoZSBtZXNzYWdl IGJlIGlkZW50aWNhbCB0byB0aGF0IGluY2x1ZGVkIGluIHRoZSBhY3R1YWwgYWxlcnQuDQoNCkZv ciB0aGF0LCBJJ2QgcmVjb21tZW5kIHRoYXQgQnJpYW4gdGFsayB0byB0aG9zZSB3aG8gZGVmaW5l IENBUC4gIEkgZG9uJ3Qgc2VlIHRoZXJlIGJlaW5nIG11Y2ggdGhhdCB3ZSBjb3VsZCBkbyBoZXJl LCBhc2lkZSBmcm9tIG5vdGluZyBob3cgdGhlIENBUCBtaWdodCBiZSBwb3B1bGF0ZWQuICBGb3Ig bm93LCBwZXJoYXBzIHdlIG5lZWQgdG8gYWNjZXB0IHRoYXQgdGhlIENBUCBkb2N1bWVudCB3aWxs IGNvbnRhaW4gbGVzcyBpbmZvcm1hdGlvbiAob3IgbGVzcyBkZXRhaWxlZCBpbmZvcm1hdGlvbikg dGhhbiBpcyBpbmNsdWRlZCBmb3Igcm91dGluZy4NCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEhhbm5lcyBUc2Nob2Zlbmln DQo+IFNlbnQ6IFdlZG5lc2RheSwgMTEgTm92ZW1iZXIgMjAwOSAxOjQ1IFBNDQo+IFRvOiBlY3Jp dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbRWNyaXRdIEFJIGZvciBEYXRhLU9ubHkgRW1lcmdlbmN5 IENhbGxzDQo+IA0KPiBkcmFmdC1yb3Nlbi1lY3JpdC1kYXRhLW9ubHktZWEtMDAudHh0IGRlc2Ny aWJlcyBhIHNvbHV0aW9uIGZvcg0KPiBjb252ZXlpbmcgYQ0KPiBDQVAgbWVzc2FnZSBpbiBhIFNJ UCBNRVNTQUdFLg0KPiANCj4gVGhlcmUgaXMgb25lIGJpZyBvcGVuIGlzc3VlIGluIHRoZSBkb2N1 bWVudDogSG93IGRvIHdlIGNhcnJ5IGxvY2F0aW9uDQo+IGluZm9ybWF0aW9uIGluIG9yIGF0dGFj aGVkIHRvIHRoZSBDQVAgbWVzc2FnZSAoc2luY2UgQ0FQIGRvZXMgbm90IGNhcnJ5DQo+IHdoYXQN Cj4gd2UgbmVlZCB3aXRoIHJlc3BlY3QgdG8gbG9jYXRpb24gaW5mb3JtYXRpb24pLg0KPiANCj4g U28sIHdlIHdpbGwgbmVlZCBhIGRpc2N1c3Npb24gb2Ygd2hhdCBjb3VsZCBiZSBzZW5zaWJsZSB0 byBkby4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K DQo= From Martin.Thomson@andrew.com Tue Nov 10 20:56:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE30F28C230 for ; Tue, 10 Nov 2009 20:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkyZuAXJ2hxq for ; Tue, 10 Nov 2009 20:56:09 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 1048228C10C for ; Tue, 10 Nov 2009 20:56:09 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:36208 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087098AbZKKE4h (ORCPT ); Tue, 10 Nov 2009 22:56:37 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 22:56:37 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 12:56:09 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 11 Nov 2009 12:56:38 +0800 Thread-Topic: [Ecrit] AI for ECRIT Direct Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUAAABdSwAABZPvA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E5451@SISPE7MB1.commscope.com> References: <004101ca6289$bf80a080$4b725d85@nsnintra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:56:10 -0000 SSB0aGluayB0aGF0IHRoZSBwb2ludCBpcyB0aGF0IHRoZSBjb25jZXJucyB0aGF0IHdlcmUgcmFp c2VkIHdlcmUgbm90IGFwcGxpY2FibGUgdG8gdGhpcyBzcGVjaWZpYyBkcmFmdC4gIFdlJ3JlIGFj dHVhbGx5IGRpc2N1c3NpbmcgcHJvYmxlbXMgdGhhdCBleGlzdCB3aXRoIHRoZSBzeXN0ZW0gYXMg YSB3aG9sZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlY3JpdC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm DQo+IE9mIFdpbnRlcmJvdHRvbSwgSmFtZXMNCj4gU2VudDogV2VkbmVzZGF5LCAxMSBOb3ZlbWJl ciAyMDA5IDE6NDcgUE0NCj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBlY3JpdEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW0Vjcml0XSBBSSBmb3IgRUNSSVQgRGlyZWN0DQo+IA0KPiBIaSBIYW5u ZXMsDQo+IA0KPiBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGUgdHJ1c3R3b3J0aHkgbG9jYXRpb24g ZWxlbWVudCBjb21lcyBpbnRvIHBsYXkNCj4gaGVyZS4NCj4gSSBiZWxpZXZlIHRoYXQgdGhlcmUg aXMgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGlzIGFuZCB0aGUNCj4gdW5hdXRoZW50aWNhdGVk IGRyYWZ0LCBidXQgb25seSBpbiBzb21lIHNjZW5hcmlvcywgY2VydGFpbmx5IG5vdCBhbGwNCj4g c2NlbmFyaW9zLg0KPiANCj4gQ2hlZXJzDQo+IEphbWVzDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YNCj4gPiBIYW5uZXMgVHNj aG9mZW5pZw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgMTEgTm92ZW1iZXIgMjAwOSAzOjQ1IFBNDQo+ ID4gVG86IGVjcml0QGlldGYub3JnDQo+ID4gU3ViamVjdDogW0Vjcml0XSBBSSBmb3IgRUNSSVQg RGlyZWN0DQo+ID4NCj4gPiBXZSBoYWQgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGlj IG9uIHRoZSBsaXN0IGFuZCBkdXJpbmcgdGhlDQo+ID4gbWVldGluZy4NCj4gPg0KPiA+DQo+ID4g VGhlcmUgYXJlIHR3byBpc3N1ZXM6DQo+ID4NCj4gPiBBKSBUaGUgdGVjaG5pY2FsIGFzcGVjdHMg b2YgaG93IHRvIGRlYWwgd2l0aCBTSVAgc2lnbmFsaW5nIGV4Y2hhbmdlcw0KPiB3aGVuDQo+ID4g dGhlcmUgaXMgbm8gVlNQL0FTUCBpbnZvbHZlZC4gQXMgSSBtZW50aW9uZWQgaW4gbXkgb3RoZXIg bWFpbCB0aGVyZQ0KPiBpcyBhDQo+ID4gcmVsYXRpb25zaGlwIHRvIHRoZSB3b3JrIGluIHRoZSB1 bmF1dGhlbnRpY2F0ZWQgZHJhZnQuDQo+ID4NCj4gPiBCKSBEZXBsb3ltZW50IHBvbGljeSBvbiB3 aGV0aGVyIGNhbGxzIHdvdWxkIGJlIHJvdXRlZCB3aXRoIG9yIHdpdGhvdXQNCj4gKHRoZQ0KPiA+ IFhib3ggZXhhbXBsZSkgaW52b2x2ZW1lbnQgb2YgdGhlIFZTUCBpbiB0aGUgZW1lcmdlbmN5IGNh bGwgZXhjaGFuZ2UuDQo+IFRoZXJlDQo+ID4gYXJlIHJlZ3VsYXRvcnkgaXNzdWVzLCBtaWdyYXRp b24gYXNwZWN0cywgYW5kIG1hbnkgc2VjdXJpdHkNCj4gY2hhbGxlbmdlcw0KPiA+IGludm9sdmVk Lg0KPiA+DQo+ID4gSSBiZWxpZXZlIHdlIG5lZWQgYSBzb2x1dGlvbiBmb3IgKEEpLiBUaGUgaGFy ZCBwYXJ0IGlzIChCKTogTWFraW5nDQo+ID4gcHJvZ3Jlc3MNCj4gPiBvbiAoQikgd2lsbCBiZSBp bXBhY3RlZCBieSBvdXIganVkZ2VtZW50IG9mIHRydXN0d29ydGh5IGxvY2F0aW9uIHZzLg0KPiB0 aGUNCj4gPiB2YWx1ZSBvZiBpZGVudGl0eSwgYXMgZGlzY3Vzc2VkIGluDQo+ID4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzY2hvZmVuaWctZWNyaXQtdHJ1c3R3b3J0aHktbG9jYXRp b24tDQo+ID4gMDIudHh0Lg0KPiA+IFNvLCBJIHN1Z2dlc3QgdG8gZmluYWxseSBnZXQgb3VyIGhl YWQgYXJvdW5kIHRoaXMgaXNzdWUgZmlyc3QuDQo+ID4NCj4gPiBPdGhlciBzdWdnZXN0aW9ucz8N Cj4gPg0KPiA+IENpYW8NCj4gPiBIYW5uZXMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4g RWNyaXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vjcml0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo= From James.Winterbottom@andrew.com Tue Nov 10 20:57:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F1828C105 for ; Tue, 10 Nov 2009 20:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAEt7FwTS50G for ; Tue, 10 Nov 2009 20:57:33 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id A708228C0F6 for ; Tue, 10 Nov 2009 20:57:33 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:44684 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S66648AbZKKE6B convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2009 22:58:01 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 22:58:01 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 11 Nov 2009 12:57:58 +0800 From: "Winterbottom, James" To: "Thomson, Martin" , Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 11 Nov 2009 12:57:57 +0800 Thread-Topic: [Ecrit] AI for ECRIT Direct Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUAAABdSwAABZPvAAAA6ZsA== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA325A@SISPE7MB1.commscope.com> References: <004101ca6289$bf80a080$4b725d85@nsnintra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0F2E5451@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E5451@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:57:34 -0000 In that case it seems to me that either we hold back all work until it is solved, or we can allow all work to proceed. Cheers James > -----Original Message----- > From: Thomson, Martin > Sent: Wednesday, 11 November 2009 3:57 PM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] AI for ECRIT Direct > > I think that the point is that the concerns that were raised were not > applicable to this specific draft. We're actually discussing problems > that exist with the system as a whole. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Wednesday, 11 November 2009 1:47 PM > > To: Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] AI for ECRIT Direct > > > > Hi Hannes, > > > > I don't believe that the trustworthy location element comes into play > > here. > > I believe that there is a relationship between this and the > > unauthenticated draft, but only in some scenarios, certainly not all > > scenarios. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of > > > Hannes Tschofenig > > > Sent: Wednesday, 11 November 2009 3:45 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] AI for ECRIT Direct > > > > > > We had a lot of discussion on this topic on the list and during the > > > meeting. > > > > > > > > > There are two issues: > > > > > > A) The technical aspects of how to deal with SIP signaling exchanges > > when > > > there is no VSP/ASP involved. As I mentioned in my other mail there > > is a > > > relationship to the work in the unauthenticated draft. > > > > > > B) Deployment policy on whether calls would be routed with or without > > (the > > > Xbox example) involvement of the VSP in the emergency call exchange. > > There > > > are regulatory issues, migration aspects, and many security > > challenges > > > involved. > > > > > > I believe we need a solution for (A). The hard part is (B): Making > > > progress > > > on (B) will be impacted by our judgement of trustworthy location vs. > > the > > > value of identity, as discussed in > > > http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location- > > > 02.txt. > > > So, I suggest to finally get our head around this issue first. > > > > > > Other suggestions? > > > > > > Ciao > > > Hannes > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Nov 10 21:22:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A716D3A6820 for ; Tue, 10 Nov 2009 21:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2JwF6K5tjZL for ; Tue, 10 Nov 2009 21:22:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CC1E428C290 for ; Tue, 10 Nov 2009 21:22:49 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAEnZ+UqrR7Hu/2dsb2JhbACIG7xmmE+EPAQ X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="269290025" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 05:23:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5NHRQ025351; Wed, 11 Nov 2009 05:23:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:23:17 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.68.243]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:23:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 23:23:15 -0600 To: "Winterbottom, James" , Cullen Jennings , ECRIT From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.com mscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2009 05:23:16.0984 (UTC) FILETIME=[12DD9F80:01CA628F] Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:22:50 -0000 At 06:23 PM 11/10/2009, Winterbottom, James wrote: >Hi Cullen, > >My thoughts on this stuff are that the more ways that you have of >doing it the less chance you have of stuff interoperating. I would >prefer to see the absolute minimum set that must be supported in phone BCP. James "Delayed offer" is a mandatory to implement part of SIP, per RFC 3261. Are you wanting to officially update RFC 3261 for this minimizing optimization? Further, there are a LOT of products out there that currently do Delayed offer, most of this is because customers/operators have demanded it be this way (as they believe they have greater control with Delayed offer that normal or early offer). IMO there needs to be a consensus from those operators that this is worth bypassing their requirement (for Delayed Offer) for. James >Cheers >James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Cullen Jennings > > Sent: Wednesday, 11 November 2009 11:18 AM > > To: ECRIT > > Subject: [Ecrit] Question about phone BCP > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all realize, > > this adds ways to use SIP but it allowed both the fast setup when the > > offer was in an INVITE and it allowed SIP to gateway to many other > > protocols where one needed to have an INVITE with no offer. > > > > I have received complaints that Phone BCP currently profiles SIP to a > > subset of it by eliminating the option of an INVITE with no offer. I > > was wondering if there is a strong reason that this was needed in > > Phone BCP. > > > > Cullen > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Tue Nov 10 21:29:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E12D28C27C for ; Tue, 10 Nov 2009 21:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3JR4TCzY8WI for ; Tue, 10 Nov 2009 21:29:46 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 6FDF73A67AF for ; Tue, 10 Nov 2009 21:29:18 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:46473 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S67428AbZKKF3o convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2009 23:29:44 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 23:29:43 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 13:29:37 +0800 From: "Winterbottom, James" To: "James M. Polk" , Cullen Jennings , ECRIT Date: Wed, 11 Nov 2009 13:29:35 +0800 Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: AcpijxbqNdtylsKYSjquUxEQHxqewAAAIOBA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:29:47 -0000 Hi James, Thanks for the lecture. My belief is that if you want stuff to just work the more simple it is the better. I actually see phone BCP was a SIP profile as a consequence I don't see why the UA can't insist on putting an SDP element in there. Surely RFC3261 says that a SIP proxy has to be able to deal with delayed offer, not that a client MUST send it? Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, 11 November 2009 4:23 PM > To: Winterbottom, James; Cullen Jennings; ECRIT > Subject: Re: [Ecrit] Question about phone BCP > > At 06:23 PM 11/10/2009, Winterbottom, James wrote: > >Hi Cullen, > > > >My thoughts on this stuff are that the more ways that you have of > >doing it the less chance you have of stuff interoperating. I would > >prefer to see the absolute minimum set that must be supported in phone > BCP. > > James > > "Delayed offer" is a mandatory to implement part of SIP, per RFC > 3261. Are you wanting to officially update RFC 3261 for this > minimizing optimization? > > Further, there are a LOT of products out there that currently do > Delayed offer, most of this is because customers/operators have > demanded it be this way (as they believe they have greater control > with Delayed offer that normal or early offer). > > IMO there needs to be a consensus from those operators that this is > worth bypassing their requirement (for Delayed Offer) for. > > James > > > >Cheers > >James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > > Cullen Jennings > > > Sent: Wednesday, 11 November 2009 11:18 AM > > > To: ECRIT > > > Subject: [Ecrit] Question about phone BCP > > > > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all realize, > > > this adds ways to use SIP but it allowed both the fast setup when the > > > offer was in an INVITE and it allowed SIP to gateway to many other > > > protocols where one needed to have an INVITE with no offer. > > > > > > I have received complaints that Phone BCP currently profiles SIP to a > > > subset of it by eliminating the option of an INVITE with no offer. I > > > was wondering if there is a strong reason that this was needed in > > > Phone BCP. > > > > > > Cullen > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Tue Nov 10 21:42:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34743A69BE for ; Tue, 10 Nov 2009 21:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6KKJGW9ShHB for ; Tue, 10 Nov 2009 21:42:54 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DCFA53A6930 for ; Tue, 10 Nov 2009 21:42:54 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAO7d+UqrR7Ht/2dsb2JhbACIG7xUmE6CPYF/BA X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="269296561" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 05:43:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5hMRc015315; Wed, 11 Nov 2009 05:43:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:43:21 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.68.243]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:43:21 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 23:43:20 -0600 To: Ray.Bellis@nominet.org.uk, ecrit From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2009 05:43:21.0598 (UTC) FILETIME=[E0DF21E0:01CA6291] Subject: Re: [Ecrit] Direct access - the "normal" call-path X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:42:56 -0000 Ray What's the normal SIP signaling flow between your SIP UA (i.e., phone) and another SIP UA? Does this go through a proxy server? Does it have to go through a proxy server? Do you agree that some customers would want to lock UAs into communicating through a certain domain proxy server before it proxies that signaling out towards its ultimate destination UA? Now, with "Direct", any UA can register with a Emergency Services Routing Proxy (ESRP). Let's call this an Emergency Services Registrar or "ESR". The purpose of an Registrar is to populate a logical location database with the host-id of the UA, and link that with the user's URI and the IP address -- thus creating at least 3 entries for the Proxy to refer to when looking up a SIP request to determine if it knows a path or destination UA (by IP address) to send this SIP request towards. Any UA probably has already done this within their own domain, with that domain's Registrar - so that UA can receive SIP requests forwarded by that domain's proxy server. What I understand this ID wanting to accomplish is allowing a UA to register to more than one domain (which I normally don't have an issue with), but that second domain to only be used by a certain application -- based on attempts to contact the sos URN (i.e. dialing 911 or 112 or 999, depending on where you are). Now, if your UA's domain is open and free of access, this will not be a problem. But, if your domain is more constrained, your first hop proxy server for sos calls just might have a problem being contacted, because it is outside of a trust boundary -- i.e., you attempt to directly contact the ESRP without going through any internal domain proxy or B2BUA or SBC first. This can be a problem. This also flies in the face of what phoneBCP is currently defining -- which isn't really that great -- because most of what we should be doing is complementary. Besides, imagine the cost of resources it'll take to operate this ESR, with all these registrations -- that really can't be rejected, unless you want to restrict them to having to be within a location region. That means a PIDF-LO will have to be in the REGISTER request to the ESR, which is not normal. All that state information... that's gonna be a hunking machine in major metropolitan areas. unless i'm missing something... James At 08:17 PM 11/10/2009, Ray.Bellis@nominet.org.uk wrote: >Regarding Brian's comments in the WG session - > >Our corporate PBX does *not* have a subscription to a SIP VSP, and >as far as I know never will. > >Our "normal" call-path for any SIP URI is to send the call *direct* >to the SIP server listed in the domain's SRV records. > >If we had to follow the "use a VSP" rule then the only fallback for >us would be to send the call over the PSTN, which rather defeats the point. > >In the UK the partial integration of PSAPs into the VoIP world is >currently only possible because the number of VSPs with direct PSTN >interconnect is very limited (< 20, AFAIK) and because in the >interim all ES calls arrive over PSTN. > >The remaining VSPs that only have IP connectivity number in the >several hundreds. Since (as above) ES calls have to go over the >PSTN they then have to route the call via one of the 20 that does >have PSTN interconnect. > >We've *already* got a scale problem - it's not feasible for the >PSAPs to recognise all of the existing UK-based VSPs, let alone the >many thousands more that lie outside of our national jurisdiction. > >Given these circumstances ECRIT-direct makes a lot of sense, IMHO. > >Ray >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Nov 10 21:51:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7E23A6853 for ; Tue, 10 Nov 2009 21:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=1.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pheoLLRnoq0 for ; Tue, 10 Nov 2009 21:51:14 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 823413A6C0A for ; Tue, 10 Nov 2009 21:51:13 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.71]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:51:41 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Hannes Tschofenig'" , References: <004001ca6289$98788fc0$4b725d85@nsnintra.net> In-Reply-To: <004001ca6289$98788fc0$4b725d85@nsnintra.net> Date: Tue, 10 Nov 2009 21:51:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiiZZW7e7NwR6OTdS0nidmov/K1AACPDIw Content-Language: en-us X-OriginalArrivalTime: 11 Nov 2009 05:51:41.0232 (UTC) FILETIME=[0AAD3B00:01CA6293] Subject: Re: [Ecrit] AI for Unauthenticated Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:51:17 -0000 The two issues are orthogonal, so handling them separately is fine. The question in my mind is whether a document dealing with emergency NAI usage belongs in ECRIT or somewhere else. Keep in mind that emergency NAIs are not necessarily just reserved for use in EAP; they also could occur in non-EAP scenarios too. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, November 10, 2009 8:44 PM To: ecrit@ietf.org Subject: [Ecrit] AI for Unauthenticated Emergency Services There are two aspects that need to get worked out: * SIP signaling interaction when there is no VSP involved. This is the space where we should accomplish an alignment with ECRIT Direct. * Network Access Authentication Procedure During this IETF meeting we had a discussion about this aspect in ECRIT and in EMU. A discussion about the topic is in the document itself with the recent update and I believe it would be good to produce a recommendation/solution (most likely in interaction with the EMU group). I furthermore suggest to separate the two issues and to work on them independently as the do not overlap. One document would deal with the terminology and the description of the network access authentication and authorization procedures. Then, a separate document would deal with SIP signaling in the lack of a VSP (as this may have wider applicability). Feedback? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Nov 10 21:53:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A049D3A6C1A for ; Tue, 10 Nov 2009 21:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QYvvDB4ekHl for ; Tue, 10 Nov 2009 21:53:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA2D23A6C18 for ; Tue, 10 Nov 2009 21:53:58 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAILg+UqrR7H+/2dsb2JhbACIGrxUmE2EPAQ X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="429718684" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 05:54:26 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5sQsr004323; Wed, 11 Nov 2009 05:54:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:54:26 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.68.243]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:54:26 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 23:54:24 -0600 To: "Winterbottom, James" , Cullen Jennings , ECRIT From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.com mscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2009 05:54:26.0169 (UTC) FILETIME=[6CFC9E90:01CA6293] Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:53:59 -0000 James I'm not fan of delayed offer btw, and wish it didn't exist, but it been here for years, it's productized by most vendors, and to limit applicability in SIP to a subset of how it's been used for years would in fact limit widespread adoption of phonebcp, which is not your goal, I don't believe. James At 11:29 PM 11/10/2009, Winterbottom, James wrote: >Hi James, > >Thanks for the lecture. >My belief is that if you want stuff to just work the more simple it >is the better. I actually see phone BCP was a SIP profile as a >consequence I don't see why the UA can't insist on putting an SDP >element in there. Surely RFC3261 says that a SIP proxy has to be >able to deal with delayed offer, not that a client MUST send it? > >Cheers >James > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, 11 November 2009 4:23 PM > > To: Winterbottom, James; Cullen Jennings; ECRIT > > Subject: Re: [Ecrit] Question about phone BCP > > > > At 06:23 PM 11/10/2009, Winterbottom, James wrote: > > >Hi Cullen, > > > > > >My thoughts on this stuff are that the more ways that you have of > > >doing it the less chance you have of stuff interoperating. I would > > >prefer to see the absolute minimum set that must be supported in phone > > BCP. > > > > James > > > > "Delayed offer" is a mandatory to implement part of SIP, per RFC > > 3261. Are you wanting to officially update RFC 3261 for this > > minimizing optimization? > > > > Further, there are a LOT of products out there that currently do > > Delayed offer, most of this is because customers/operators have > > demanded it be this way (as they believe they have greater control > > with Delayed offer that normal or early offer). > > > > IMO there needs to be a consensus from those operators that this is > > worth bypassing their requirement (for Delayed Offer) for. > > > > James > > > > > > >Cheers > > >James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > > Cullen Jennings > > > > Sent: Wednesday, 11 November 2009 11:18 AM > > > > To: ECRIT > > > > Subject: [Ecrit] Question about phone BCP > > > > > > > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all realize, > > > > this adds ways to use SIP but it allowed both the fast setup when the > > > > offer was in an INVITE and it allowed SIP to gateway to many other > > > > protocols where one needed to have an INVITE with no offer. > > > > > > > > I have received complaints that Phone BCP currently profiles SIP to a > > > > subset of it by eliminating the option of an INVITE with no offer. I > > > > was wondering if there is a strong reason that this was needed in > > > > Phone BCP. > > > > > > > > Cullen > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > From James.Winterbottom@andrew.com Tue Nov 10 21:57:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1F63A6C10 for ; Tue, 10 Nov 2009 21:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGAbIUbXtTTZ for ; Tue, 10 Nov 2009 21:57:57 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id E9BF63A6820 for ; Tue, 10 Nov 2009 21:57:56 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:57469 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087621AbZKKF6Y convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2009 23:58:24 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 10 Nov 2009 23:58:24 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 13:58:21 +0800 From: "Winterbottom, James" To: "James M. Polk" , Cullen Jennings , ECRIT Date: Wed, 11 Nov 2009 13:58:20 +0800 Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: Acpik3E+jhiPo6NeSNqBGnJ8wjVxgAAACKtA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3297@SISPE7MB1.commscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:57:58 -0000 Hi James, My point was more that a proxy kind of doesn't have too much say in this matter, surely it can't reject and INVITE that contains an SDP body can it? If we want Phone BCP to be adopted then more than likely clients will need to be modified so it could be added in then anyway. Perhaps the change is however bigger than I am presupposing. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, 11 November 2009 4:54 PM > To: Winterbottom, James; Cullen Jennings; ECRIT > Subject: RE: [Ecrit] Question about phone BCP > > James > > I'm not fan of delayed offer btw, and wish it didn't exist, but it > been here for years, it's productized by most vendors, and to limit > applicability in SIP to a subset of how it's been used for years > would in fact limit widespread adoption of phonebcp, which is not > your goal, I don't believe. > > James > > At 11:29 PM 11/10/2009, Winterbottom, James wrote: > >Hi James, > > > >Thanks for the lecture. > >My belief is that if you want stuff to just work the more simple it > >is the better. I actually see phone BCP was a SIP profile as a > >consequence I don't see why the UA can't insist on putting an SDP > >element in there. Surely RFC3261 says that a SIP proxy has to be > >able to deal with delayed offer, not that a client MUST send it? > > > >Cheers > >James > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Wednesday, 11 November 2009 4:23 PM > > > To: Winterbottom, James; Cullen Jennings; ECRIT > > > Subject: Re: [Ecrit] Question about phone BCP > > > > > > At 06:23 PM 11/10/2009, Winterbottom, James wrote: > > > >Hi Cullen, > > > > > > > >My thoughts on this stuff are that the more ways that you have of > > > >doing it the less chance you have of stuff interoperating. I would > > > >prefer to see the absolute minimum set that must be supported in > phone > > > BCP. > > > > > > James > > > > > > "Delayed offer" is a mandatory to implement part of SIP, per RFC > > > 3261. Are you wanting to officially update RFC 3261 for this > > > minimizing optimization? > > > > > > Further, there are a LOT of products out there that currently do > > > Delayed offer, most of this is because customers/operators have > > > demanded it be this way (as they believe they have greater control > > > with Delayed offer that normal or early offer). > > > > > > IMO there needs to be a consensus from those operators that this is > > > worth bypassing their requirement (for Delayed Offer) for. > > > > > > James > > > > > > > > > >Cheers > > > >James > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > Of > > > > > Cullen Jennings > > > > > Sent: Wednesday, 11 November 2009 11:18 AM > > > > > To: ECRIT > > > > > Subject: [Ecrit] Question about phone BCP > > > > > > > > > > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all > realize, > > > > > this adds ways to use SIP but it allowed both the fast setup when > the > > > > > offer was in an INVITE and it allowed SIP to gateway to many other > > > > > protocols where one needed to have an INVITE with no offer. > > > > > > > > > > I have received complaints that Phone BCP currently profiles SIP > to a > > > > > subset of it by eliminating the option of an INVITE with no offer. > I > > > > > was wondering if there is a strong reason that this was needed in > > > > > Phone BCP. > > > > > > > > > > Cullen > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > >_______________________________________________ > > > >Ecrit mailing list > > > >Ecrit@ietf.org > > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > From bernard_aboba@hotmail.com Tue Nov 10 22:03:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07A43A6C1A for ; Tue, 10 Nov 2009 22:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsnYqjQTcMa1 for ; Tue, 10 Nov 2009 22:03:10 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by core3.amsl.com (Postfix) with ESMTP id B6C0A3A6820 for ; Tue, 10 Nov 2009 22:03:10 -0800 (PST) Received: from BLU137-DS6 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:03:38 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Thomson, Martin'" , "'Winterbottom, James'" , "'Hannes Tschofenig'" , References: <004101ca6289$bf80a080$4b725d85@nsnintra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0F2E5451@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E5451@SISPE7MB1.commscope.com> Date: Tue, 10 Nov 2009 22:03:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUAAABdSwAABZPvAAAgQr0A== Content-Language: en-us X-OriginalArrivalTime: 11 Nov 2009 06:03:38.0336 (UTC) FILETIME=[B61A9E00:01CA6294] Subject: Re: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:03:11 -0000 I'd agree with Martin on this. While I certainly understand the potential security issues involved in ECRIT Direct, the same set of issues also exist with enabling the PSAPs to interconnect with any VSP on the planet. So while I can understand Brian's assertion that ECRIT Direct would be difficult to implement securely, I take that as a tacit admission that interconnection of PSAPs with all VSPs is also difficult to implement securely. What bothers me most about this is that is seems to be yet another symptom of Cullen's comment on "revisionitis". These are very basic questions -- and if we haven't answered them yet and are having these kind of discussions now, I shudder to think about what these discussions will be like once we actually try to deploy this and try to figure out how to secure it. In some ways, the difficulty of this problem makes some of the "smart grid" security discussions look simple by comparison. At least in those scenarios we don't have an expectation that anyone should be able to read the home meter or gain access to a nuclear power plant. The closest analogy I can come up with is the problems we've had with SPAM -- and we know how that one turned out. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Thomson, Martin Sent: Tuesday, November 10, 2009 8:57 PM To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] AI for ECRIT Direct I think that the point is that the concerns that were raised were not applicable to this specific draft. We're actually discussing problems that exist with the system as a whole. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Wednesday, 11 November 2009 1:47 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] AI for ECRIT Direct > > Hi Hannes, > > I don't believe that the trustworthy location element comes into play > here. > I believe that there is a relationship between this and the > unauthenticated draft, but only in some scenarios, certainly not all > scenarios. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > > Hannes Tschofenig > > Sent: Wednesday, 11 November 2009 3:45 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] AI for ECRIT Direct > > > > We had a lot of discussion on this topic on the list and during the > > meeting. > > > > > > There are two issues: > > > > A) The technical aspects of how to deal with SIP signaling exchanges > when > > there is no VSP/ASP involved. As I mentioned in my other mail there > is a > > relationship to the work in the unauthenticated draft. > > > > B) Deployment policy on whether calls would be routed with or without > (the > > Xbox example) involvement of the VSP in the emergency call exchange. > There > > are regulatory issues, migration aspects, and many security > challenges > > involved. > > > > I believe we need a solution for (A). The hard part is (B): Making > > progress > > on (B) will be impacted by our judgement of trustworthy location vs. > the > > value of identity, as discussed in > > http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location- > > 02.txt. > > So, I suggest to finally get our head around this issue first. > > > > Other suggestions? > > > > Ciao > > Hannes > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Nov 10 22:16:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA7928C2AD for ; Tue, 10 Nov 2009 22:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sff3mxTZZ6sR for ; Tue, 10 Nov 2009 22:16:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9C24928C2B6 for ; Tue, 10 Nov 2009 22:16:50 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FACPm+UqrR7H+/2dsb2JhbACIGrxFmEaEPAQ X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="269309371" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 06:17:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB6HIDE018170; Wed, 11 Nov 2009 06:17:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:17:18 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.68.243]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:17:17 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Nov 2009 00:17:16 -0600 To: "Winterbottom, James" , Cullen Jennings , ECRIT From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3297@SISPE7MB1.com mscope.com> References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3297@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2009 06:17:18.0061 (UTC) FILETIME=[9EB2B9D0:01CA6296] Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:16:54 -0000 At 11:58 PM 11/10/2009, Winterbottom, James wrote: >Hi James, > >My point was more that a proxy kind of doesn't have too much say in >this matter, surely it can't reject and INVITE that contains an SDP >body can it? no, INVITEs don't get rejected just for having an SDP message body. I think with operators that don't want early/normal offers - if they do receive an SDP that wasn't supposed to be there (in the INVITE), they delete the SDP along the signaling path (probably as close to the UAC as possible) and insert the SDP offer where they normally would if there wasn't any SDP message body originally. >If we want Phone BCP to be adopted then more than likely clients >will need to be modified so it could be added in then anyway. I agree that new code is needed. but... >Perhaps the change is however bigger than I am presupposing. ...I believe this will limit the applicability to only those environments (voice/video topologies?) that are configured to do early/normal offer, and not environments that still do delayed offer. Those in the latter camp will likely simply choose to not do phonebcp, which is the "widespread deployments" point (below) that I believe we don't want to hinder. James >Cheers >James > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, 11 November 2009 4:54 PM > > To: Winterbottom, James; Cullen Jennings; ECRIT > > Subject: RE: [Ecrit] Question about phone BCP > > > > James > > > > I'm not fan of delayed offer btw, and wish it didn't exist, but it > > been here for years, it's productized by most vendors, and to limit > > applicability in SIP to a subset of how it's been used for years > > would in fact limit widespread adoption of phonebcp, which is not > > your goal, I don't believe. > > > > James > > > > At 11:29 PM 11/10/2009, Winterbottom, James wrote: > > >Hi James, > > > > > >Thanks for the lecture. > > >My belief is that if you want stuff to just work the more simple it > > >is the better. I actually see phone BCP was a SIP profile as a > > >consequence I don't see why the UA can't insist on putting an SDP > > >element in there. Surely RFC3261 says that a SIP proxy has to be > > >able to deal with delayed offer, not that a client MUST send it? > > > > > >Cheers > > >James > > > > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: Wednesday, 11 November 2009 4:23 PM > > > > To: Winterbottom, James; Cullen Jennings; ECRIT > > > > Subject: Re: [Ecrit] Question about phone BCP > > > > > > > > At 06:23 PM 11/10/2009, Winterbottom, James wrote: > > > > >Hi Cullen, > > > > > > > > > >My thoughts on this stuff are that the more ways that you have of > > > > >doing it the less chance you have of stuff interoperating. I would > > > > >prefer to see the absolute minimum set that must be supported in > > phone > > > > BCP. > > > > > > > > James > > > > > > > > "Delayed offer" is a mandatory to implement part of SIP, per RFC > > > > 3261. Are you wanting to officially update RFC 3261 for this > > > > minimizing optimization? > > > > > > > > Further, there are a LOT of products out there that currently do > > > > Delayed offer, most of this is because customers/operators have > > > > demanded it be this way (as they believe they have greater control > > > > with Delayed offer that normal or early offer). > > > > > > > > IMO there needs to be a consensus from those operators that this is > > > > worth bypassing their requirement (for Delayed Offer) for. > > > > > > > > James > > > > > > > > > > > > >Cheers > > > > >James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > > Of > > > > > > Cullen Jennings > > > > > > Sent: Wednesday, 11 November 2009 11:18 AM > > > > > > To: ECRIT > > > > > > Subject: [Ecrit] Question about phone BCP > > > > > > > > > > > > > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all > > realize, > > > > > > this adds ways to use SIP but it allowed both the fast setup when > > the > > > > > > offer was in an INVITE and it allowed SIP to gateway to many other > > > > > > protocols where one needed to have an INVITE with no offer. > > > > > > > > > > > > I have received complaints that Phone BCP currently profiles SIP > > to a > > > > > > subset of it by eliminating the option of an INVITE with no offer. > > I > > > > > > was wondering if there is a strong reason that this was needed in > > > > > > Phone BCP. > > > > > > > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > >_______________________________________________ > > > > >Ecrit mailing list > > > > >Ecrit@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > > From Martin.Dawson@andrew.com Tue Nov 10 22:31:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE4B28C2B5 for ; Tue, 10 Nov 2009 22:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdirTneZFeSu for ; Tue, 10 Nov 2009 22:31:10 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 4CBC528C290 for ; Tue, 10 Nov 2009 22:31:07 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:173 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5087915AbZKKGbf convert rfc822-to-8bit (ORCPT ); Wed, 11 Nov 2009 00:31:35 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 11 Nov 2009 00:31:35 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 11 Nov 2009 14:30:54 +0800 From: "Dawson, Martin" To: "James M. Polk" , "Ray.Bellis@nominet.org.uk" , ecrit Date: Wed, 11 Nov 2009 14:30:51 +0800 Thread-Topic: [Ecrit] Direct access - the "normal" call-path Thread-Index: AcpikeYZIlbYCeWnS8GSJvKLl7QnHgAA50tQ Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E54B8@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] Direct access - the "normal" call-path X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:31:12 -0000 An emergency call is not "normal" so "normal" isn't an argument - nor a panacea. If a domain/UA is so locked down that SIP invites can only go to a specific proxy then that's either a proxy scenario (not direct) or the domain should also have LoST locked down so the PSAP URI points at the proxy it wants... it can look like direct to the client but still be proxy. There's plenty to be said for the proxy using the direct recommendations as well. Having an emergency specific proxy registration (on behalf of the UA) has benefits in terms of ability to prioritise call back. I don't think this draft is in conflict with phonebcp. If the jurisdiction can't afford the horsepower to support the registration/callback then they don't have to. The facility is negotiated; it has to be. I'm sceptical that it's as significant as all that. Heck yes, applying policy based on location (by value or reference) is recommended. Direct mode simplifies these considerations. I'm still waiting for someone to point me at the part of phonebcp that explains how VSPs/proxies are supposed to be authenticated/authorized in order for this subscriber identity validation to occur. I honestly never thought that was part of the requirements or in scope; it's a recent addition from my perspective. I thought that the typical "proxy" that we were referring to was an enterprise soft switch - not arbitrary foreign VSPs. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Wednesday, 11 November 2009 4:43 PM To: Ray.Bellis@nominet.org.uk; ecrit Subject: Re: [Ecrit] Direct access - the "normal" call-path Ray What's the normal SIP signaling flow between your SIP UA (i.e., phone) and another SIP UA? Does this go through a proxy server? Does it have to go through a proxy server? Do you agree that some customers would want to lock UAs into communicating through a certain domain proxy server before it proxies that signaling out towards its ultimate destination UA? Now, with "Direct", any UA can register with a Emergency Services Routing Proxy (ESRP). Let's call this an Emergency Services Registrar or "ESR". The purpose of an Registrar is to populate a logical location database with the host-id of the UA, and link that with the user's URI and the IP address -- thus creating at least 3 entries for the Proxy to refer to when looking up a SIP request to determine if it knows a path or destination UA (by IP address) to send this SIP request towards. Any UA probably has already done this within their own domain, with that domain's Registrar - so that UA can receive SIP requests forwarded by that domain's proxy server. What I understand this ID wanting to accomplish is allowing a UA to register to more than one domain (which I normally don't have an issue with), but that second domain to only be used by a certain application -- based on attempts to contact the sos URN (i.e. dialing 911 or 112 or 999, depending on where you are). Now, if your UA's domain is open and free of access, this will not be a problem. But, if your domain is more constrained, your first hop proxy server for sos calls just might have a problem being contacted, because it is outside of a trust boundary -- i.e., you attempt to directly contact the ESRP without going through any internal domain proxy or B2BUA or SBC first. This can be a problem. This also flies in the face of what phoneBCP is currently defining -- which isn't really that great -- because most of what we should be doing is complementary. Besides, imagine the cost of resources it'll take to operate this ESR, with all these registrations -- that really can't be rejected, unless you want to restrict them to having to be within a location region. That means a PIDF-LO will have to be in the REGISTER request to the ESR, which is not normal. All that state information... that's gonna be a hunking machine in major metropolitan areas. unless i'm missing something... James At 08:17 PM 11/10/2009, Ray.Bellis@nominet.org.uk wrote: >Regarding Brian's comments in the WG session - > >Our corporate PBX does *not* have a subscription to a SIP VSP, and >as far as I know never will. > >Our "normal" call-path for any SIP URI is to send the call *direct* >to the SIP server listed in the domain's SRV records. > >If we had to follow the "use a VSP" rule then the only fallback for >us would be to send the call over the PSTN, which rather defeats the point. > >In the UK the partial integration of PSAPs into the VoIP world is >currently only possible because the number of VSPs with direct PSTN >interconnect is very limited (< 20, AFAIK) and because in the >interim all ES calls arrive over PSTN. > >The remaining VSPs that only have IP connectivity number in the >several hundreds. Since (as above) ES calls have to go over the >PSTN they then have to route the call via one of the 20 that does >have PSTN interconnect. > >We've *already* got a scale problem - it's not feasible for the >PSAPs to recognise all of the existing UK-based VSPs, let alone the >many thousands more that lie outside of our national jurisdiction. > >Given these circumstances ECRIT-direct makes a lot of sense, IMHO. > >Ray >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Tue Nov 10 22:40:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B24B28C2B5 for ; Tue, 10 Nov 2009 22:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KALijO-c-H+p for ; Tue, 10 Nov 2009 22:40:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 278AA3A68F3 for ; Tue, 10 Nov 2009 22:40:43 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 06:41:10 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp007) with SMTP; 11 Nov 2009 07:41:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nA+QmnfpnsyCvyC4LMrXeYeb7MjjS4T0iqB+j9d lw3dp+bqiXn4F2 From: "Hannes Tschofenig" To: "'Winterbottom, James'" , , References: <004101ca6289$bf80a080$4b725d85@nsnintra.net> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> Date: Wed, 11 Nov 2009 15:44:24 +0900 Message-ID: <023e01ca629a$6b50e630$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpiibzlUlb+MORoSz2/QKWGh/cIUAAABdSwAAP7iKA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA3252@SISPE7MB1.commscope.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: Re: [Ecrit] AI for ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:40:47 -0000 Hi James, >Hi Hannes, > >I don't believe that the trustworthy location element comes >into play here. The important sticking point seems to be security in this discussion. The trustworthy location is about security of location vs. identity. >I believe that there is a relationship between this and the >unauthenticated draft, but only in some scenarios, certainly >not all scenarios. The technical text in the unauthenticated draft (see Section 7) is very similar to the solution in ECRIT direct (with some delta). The arguments on why these things are different in the two docs. Ciao Hannes > >Cheers >James > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Hannes Tschofenig >> Sent: Wednesday, 11 November 2009 3:45 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] AI for ECRIT Direct >> >> We had a lot of discussion on this topic on the list and during the >> meeting. >> >> >> There are two issues: >> >> A) The technical aspects of how to deal with SIP signaling exchanges >> when there is no VSP/ASP involved. As I mentioned in my other mail >> there is a relationship to the work in the unauthenticated draft. >> >> B) Deployment policy on whether calls would be routed with >or without >> (the Xbox example) involvement of the VSP in the emergency call >> exchange. There are regulatory issues, migration aspects, and many >> security challenges involved. >> >> I believe we need a solution for (A). The hard part is (B): Making >> progress on (B) will be impacted by our judgement of trustworthy >> location vs. the value of identity, as discussed in >> http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location- >> 02.txt. >> So, I suggest to finally get our head around this issue first. >> >> Other suggestions? >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Tue Nov 10 22:59:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22C23A6C23 for ; Tue, 10 Nov 2009 22:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OTCBGhxqLvV for ; Tue, 10 Nov 2009 22:59:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 758423A6B8A for ; Tue, 10 Nov 2009 22:59:27 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2009 06:59:53 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp049) with SMTP; 11 Nov 2009 07:59:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/6MoE1nMj6WueoVDLOzfH0P7A1dIJL1X679xm24h ejjAZp8ZYm4Fxd From: "Hannes Tschofenig" To: Date: Wed, 11 Nov 2009 16:03:09 +0900 Message-ID: <023f01ca629d$091159c0$4b725d85@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0240_01CA62E8.78F901C0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpinQaG4cLQ282QToqv/xfw+ZerWw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64,0.64 Subject: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:59:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0240_01CA62E8.78F901C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ECRIT-Direct (see http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt) uses the following procedure: * End host obtains location * Uses location with LoST to obtain a ESRP URI * Registers with the ESRP for callback * Let the ESRP verify location and let it do the routing decision The unauthenticated draft (see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.t xt) uses the following procedure: * End host MAY obtain location and MAY use LoST * If it does not use LoST then it needs to obtain the ESRP URI using DHCP * Let the ESRP obtain location (if not done already by the end host) and let it do the routing decision * No SIP registration procedure described. Which parts do people like / dislike? Ciao Hannes ------=_NextPart_000_0240_01CA62E8.78F901C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Difference between ECRIT-Direct and Unauthenticated Draft

ECRIT-Direct (see = http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-0= 1.txt) uses the following = procedure:

* End host obtains location
* Uses location with LoST to obtain a = ESRP URI
* Registers with the ESRP for = callback
* Let the ESRP verify location and let = it do the routing decision

The unauthenticated draft (see = http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthent= icated-access-06.txt) uses = the following procedure:

* End host MAY obtain location and MAY = use LoST
* If it does not use LoST then it = needs to obtain the ESRP URI using DHCP
* Let the ESRP obtain location (if not = done already by the end host) and let it do the routing decision
* No SIP registration procedure described.

Which parts do people like / dislike? =

Ciao
Hannes

------=_NextPart_000_0240_01CA62E8.78F901C0-- From bernard_aboba@hotmail.com Wed Nov 11 00:57:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D813A688C for ; Wed, 11 Nov 2009 00:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShUfXzRid8HE for ; Wed, 11 Nov 2009 00:57:31 -0800 (PST) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id 918193A69DC for ; Wed, 11 Nov 2009 00:57:31 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:57:59 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Hannes Tschofenig'" , References: <023f01ca629d$091159c0$4b725d85@nsnintra.net> In-Reply-To: <023f01ca629d$091159c0$4b725d85@nsnintra.net> Date: Wed, 11 Nov 2009 00:57:58 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01CA626A.02F18AC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpinQaG4cLQ282QToqv/xfw+ZerWwADyqJA Content-Language: en-us X-OriginalArrivalTime: 11 Nov 2009 08:57:59.0191 (UTC) FILETIME=[11426A70:01CA62AD] Subject: Re: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:57:36 -0000 ------=_NextPart_000_0069_01CA626A.02F18AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I dislike the assumption that providers of unauthenticated access will do anything to enable emergency calling. We're talking about cafes and hotels here, deploying equipment that displays many of the same issues that have been found in home gateways (e.g. DNS proxies as documented in RFC 5625). If they do try to "help" with emergency services, they probably will botch it so badly that we'd wish they didn't try at all. Much of the equipment in question consists of vintage 2001 access points (IEEE 802.11b, no a, b, g or n). It could be a decade before the L2 emergency functionality discussed in today's meeting makes it into broad use, if it ever does. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, November 10, 2009 11:03 PM To: ecrit@ietf.org Subject: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft ECRIT-Direct (see http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt) uses the following procedure: * End host obtains location * Uses location with LoST to obtain a ESRP URI * Registers with the ESRP for callback * Let the ESRP verify location and let it do the routing decision The unauthenticated draft (see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.t xt) uses the following procedure: * End host MAY obtain location and MAY use LoST * If it does not use LoST then it needs to obtain the ESRP URI using DHCP * Let the ESRP obtain location (if not done already by the end host) and let it do the routing decision * No SIP registration procedure described. Which parts do people like / dislike? Ciao Hannes ------=_NextPart_000_0069_01CA626A.02F18AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Difference between ECRIT-Direct and Unauthenticated Draft

I dislike the assumption that providers of = unauthenticated access will do anything to enable emergency calling.   We’re = talking about cafes and hotels here, deploying equipment that displays many of = the same issues that have been found in home gateways (e.g. DNS proxies as = documented in RFC 5625).  If they do try to “help” with emergency = services, they probably will botch it so badly that we’d wish they = didn’t try at all.

 

Much of the equipment in question consists of vintage = 2001 access points (IEEE 802.11b, no a, b, g or n).  It could be a = decade before the L2 emergency functionality discussed in today’s meeting = makes it into broad use, if it ever does.

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Hannes Tschofenig
Sent: Tuesday, November 10, 2009 11:03 PM
To: ecrit@ietf.org
Subject: [Ecrit] Difference between ECRIT-Direct and = Unauthenticated Draft

 

 

ECRIT-Direct (see = http://tools.= ietf.org/id/draft-winterbottom-ecrit-direct-01.txt) uses the = following procedure:

* = End host obtains location
* Uses = location with LoST to obtain a ESRP URI
* = Registers with the ESRP for callback
* Let = the ESRP verify location and let it do the routing decision =

The unauthenticated draft (see http://tools.= ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.txt<= /a>) uses the = following procedure:

* = End host MAY obtain location and MAY use LoST
* If = it does not use LoST then it needs to obtain the ESRP URI using DHCP
* Let = the ESRP obtain location (if not done already by the end host) and let it do the = routing decision
* No SIP registration procedure described.

Which parts do people like / dislike?

Ciao =
Hannes=

------=_NextPart_000_0069_01CA626A.02F18AC0-- From hgs@cs.columbia.edu Wed Nov 11 02:25:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC943A6810 for ; Wed, 11 Nov 2009 02:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggyr3tDqO2Ns for ; Wed, 11 Nov 2009 02:25:17 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 56BEF3A6932 for ; Wed, 11 Nov 2009 02:25:17 -0800 (PST) Received: from fokuswl198.fhi-fokus.de (fokuswl198.fhi-fokus.de [193.174.153.198]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nABAPeUg001242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Nov 2009 05:25:41 -0500 (EST) References: <023f01ca629d$091159c0$4b725d85@nsnintra.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-13-455065266 Message-Id: <2FED1336-3966-429F-A0F2-1CD03C59670A@cs.columbia.edu> From: Henning Schulzrinne Date: Wed, 11 Nov 2009 05:25:39 -0500 To: Bernard Aboba X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:25:18 -0000 --Apple-Mail-13-455065266 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes The "decade" part doesn't worry me - having specs allows planning for =20= future networks (and writing the RFCs into RFPs), particularly in semi-=20= public places, such as airports and downtown WiFi networks. In any =20 event, it will likely be a decade before we convert PSTN PSAPs into IP =20= PSAPs. Henning On Nov 11, 2009, at 3:57 AM, Bernard Aboba wrote: > I dislike the assumption that providers of unauthenticated access =20 > will do anything to enable emergency calling. We=92re talking about =20= > cafes and hotels here, deploying equipment that displays many of the =20= > same issues that have been found in home gateways (e.g. DNS proxies =20= > as documented in RFC 5625). If they do try to =93help=94 with = emergency =20 > services, they probably will botch it so badly that we=92d wish they =20= > didn=92t try at all. > > Much of the equipment in question consists of vintage 2001 access =20 > points (IEEE 802.11b, no a, b, g or n). It could be a decade before =20= > the L2 emergency functionality discussed in today=92s meeting makes it = =20 > into broad use, if it ever does. > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of Hannes Tschofenig > Sent: Tuesday, November 10, 2009 11:03 PM > To: ecrit@ietf.org > Subject: [Ecrit] Difference between ECRIT-Direct and Unauthenticated =20= > Draft > > > ECRIT-Direct (see = http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt=20 > ) uses the following procedure: > > * End host obtains location > * Uses location with LoST to obtain a ESRP URI > * Registers with the ESRP for callback > * Let the ESRP verify location and let it do the routing decision > > The unauthenticated draft (see = http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06= .txt=20 > ) uses the following procedure: > > * End host MAY obtain location and MAY use LoST > * If it does not use LoST then it needs to obtain the ESRP URI using =20= > DHCP > * Let the ESRP obtain location (if not done already by the end host) =20= > and let it do the routing decision > * No SIP registration procedure described. > > Which parts do people like / dislike? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-13-455065266 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The "decade" part doesn't worry me - having = specs allows planning for future networks (and writing the RFCs into = RFPs), particularly in semi-public places, such as airports and downtown = WiFi networks. In any event, it will likely be a decade before we = convert PSTN PSAPs into IP = PSAPs.

Henning

On Nov 11, = 2009, at 3:57 AM, Bernard Aboba wrote:

I dislike the assumption that providers of = unauthenticated access will do anything to enable emergency = calling.   We=92re talking about cafes and hotels here, = deploying equipment that displays many of the same issues that have been = found in home gateways (e.g. DNS proxies as documented in RFC 5625). =  If they do try to =93help=94 with emergency services, they = probably will botch it so badly that we=92d wish they didn=92t try at = all.
 
Much of the equipment in question = consists of vintage 2001 access points (IEEE 802.11b, no a, b, g or = n).  It could be a decade before the L2 emergency functionality = discussed in today=92s meeting makes it into broad use, if it ever = does.
 
 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf = Of Hannes = Tschofenig
Sent: Tuesday, November 10, 2009 = 11:03 PM
To: ecrit@ietf.org
Subject: [Ecrit] Difference between = ECRIT-Direct and Unauthenticated = Draft
 

ECRIT-Direct (see ) = uses the following procedure:

* End host obtains = location 
* Uses = location with LoST to obtain a ESRP URI 
* Registers with the ESRP for = callback 
* Let the ESRP verify = location and let it do the routing decision

The unauthenticated draft = (see ) uses the following procedure:

* End host MAY obtain location = and MAY use LoST 
* If it does not use LoST = then it needs to obtain the ESRP URI using DHCP 
* Let the ESRP obtain = location (if not done already by the end host) and let it do the routing = decision
* No SIP registration procedure = described.

Which parts do people like / = dislike?

Ciao 
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:03:27 -0000 I think the bottom line in this case is simple and meets everyone's needs. I'll rev phonebcp to remove the SDP requirement. If the INVITE shows at the ESRP without an offer, it should be accepted, the PSAP should accept it, and follow normal offer/answer procedures. I don't think we need to say that, we just have to remove the requirement that the INVITE has an offer. That makes it less "proscriptive" from James W.'s point of view, resolves Cullens comment, and doesn't change anything from James P's perspective. It was a mistake, we never intended to rule out delayed offer. Brian On 11/11/09 1:17 AM, "James Polk" wrote: > At 11:58 PM 11/10/2009, Winterbottom, James wrote: >> Hi James, >> >> My point was more that a proxy kind of doesn't have too much say in >> this matter, surely it can't reject and INVITE that contains an SDP >> body can it? > > no, INVITEs don't get rejected just for having an SDP message body. > > I think with operators that don't want early/normal offers - if they > do receive an SDP that wasn't supposed to be there (in the INVITE), > they delete the SDP along the signaling path (probably as close to > the UAC as possible) and insert the SDP offer where they normally > would if there wasn't any SDP message body originally. > > >> If we want Phone BCP to be adopted then more than likely clients >> will need to be modified so it could be added in then anyway. > > I agree that new code is needed. but... > >> Perhaps the change is however bigger than I am presupposing. > > ...I believe this will limit the applicability to only those > environments (voice/video topologies?) that are configured to do > early/normal offer, and not environments that still do delayed > offer. Those in the latter camp will likely simply choose to not do > phonebcp, which is the "widespread deployments" point (below) that I > believe we don't want to hinder. > > James > > >> Cheers >> James >> >> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Wednesday, 11 November 2009 4:54 PM >>> To: Winterbottom, James; Cullen Jennings; ECRIT >>> Subject: RE: [Ecrit] Question about phone BCP >>> >>> James >>> >>> I'm not fan of delayed offer btw, and wish it didn't exist, but it >>> been here for years, it's productized by most vendors, and to limit >>> applicability in SIP to a subset of how it's been used for years >>> would in fact limit widespread adoption of phonebcp, which is not >>> your goal, I don't believe. >>> >>> James >>> >>> At 11:29 PM 11/10/2009, Winterbottom, James wrote: >>>> Hi James, >>>> >>>> Thanks for the lecture. >>>> My belief is that if you want stuff to just work the more simple it >>>> is the better. I actually see phone BCP was a SIP profile as a >>>> consequence I don't see why the UA can't insist on putting an SDP >>>> element in there. Surely RFC3261 says that a SIP proxy has to be >>>> able to deal with delayed offer, not that a client MUST send it? >>>> >>>> Cheers >>>> James >>>> >>>> >>>>> -----Original Message----- >>>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>>> Sent: Wednesday, 11 November 2009 4:23 PM >>>>> To: Winterbottom, James; Cullen Jennings; ECRIT >>>>> Subject: Re: [Ecrit] Question about phone BCP >>>>> >>>>> At 06:23 PM 11/10/2009, Winterbottom, James wrote: >>>>>> Hi Cullen, >>>>>> >>>>>> My thoughts on this stuff are that the more ways that you have of >>>>>> doing it the less chance you have of stuff interoperating. I would >>>>>> prefer to see the absolute minimum set that must be supported in >>> phone >>>>> BCP. >>>>> >>>>> James >>>>> >>>>> "Delayed offer" is a mandatory to implement part of SIP, per RFC >>>>> 3261. Are you wanting to officially update RFC 3261 for this >>>>> minimizing optimization? >>>>> >>>>> Further, there are a LOT of products out there that currently do >>>>> Delayed offer, most of this is because customers/operators have >>>>> demanded it be this way (as they believe they have greater control >>>>> with Delayed offer that normal or early offer). >>>>> >>>>> IMO there needs to be a consensus from those operators that this is >>>>> worth bypassing their requirement (for Delayed Offer) for. >>>>> >>>>> James >>>>> >>>>> >>>>>> Cheers >>>>>> James >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> Cullen Jennings >>>>>>> Sent: Wednesday, 11 November 2009 11:18 AM >>>>>>> To: ECRIT >>>>>>> Subject: [Ecrit] Question about phone BCP >>>>>>> >>>>>>> >>>>>>> So SIP allows INVITEs with or without an SDP offer. As we all >>> realize, >>>>>>> this adds ways to use SIP but it allowed both the fast setup when >>> the >>>>>>> offer was in an INVITE and it allowed SIP to gateway to many other >>>>>>> protocols where one needed to have an INVITE with no offer. >>>>>>> >>>>>>> I have received complaints that Phone BCP currently profiles SIP >>> to a >>>>>>> subset of it by eliminating the option of an INVITE with no offer. >>> I >>>>>>> was wondering if there is a strong reason that this was needed in >>>>>>> Phone BCP. >>>>>>> >>>>>>> Cullen >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fluffy@cisco.com Wed Nov 11 07:10:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3357F3A68C8 for ; Wed, 11 Nov 2009 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ18zgV+tfls for ; Wed, 11 Nov 2009 07:10:17 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D378A3A67E3 for ; Wed, 11 Nov 2009 07:10:17 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="223228170" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Nov 2009 15:10:46 +0000 Received: from tky-vpn-client-230-66.cisco.com (tky-vpn-client-230-66.cisco.com [10.70.230.66]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABFAjmf002390; Wed, 11 Nov 2009 15:10:45 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: Date: Thu, 12 Nov 2009 00:10:44 +0900 Content-Transfer-Encoding: 7bit Message-Id: <55ADBA99-5DC5-42C8-AB3C-EF5530012838@cisco.com> References: To: "Brian Rosen" X-Mailer: Apple Mail (2.1076) Cc: ECRIT Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:10:19 -0000 On Nov 12, 2009, at 24:03 , Brian Rosen wrote: > I think the bottom line in this case is simple and meets everyone's > needs. > I'll rev phonebcp to remove the SDP requirement. If the INVITE > shows at the > ESRP without an offer, it should be accepted, the PSAP should accept > it, and > follow normal offer/answer procedures. I don't think we need to say > that, > we just have to remove the requirement that the INVITE has an offer. > > That makes it less "proscriptive" from James W.'s point of view, > resolves > Cullens comment, and doesn't change anything from James P's > perspective. > > It was a mistake, we never intended to rule out delayed offer. > > Brian I think this sounds like the right plan to keep moving stuff forward quickly. Thanks From br@brianrosen.net Wed Nov 11 07:32:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03C33A68DB for ; Wed, 11 Nov 2009 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZqDxgfxDVM7 for ; Wed, 11 Nov 2009 07:32:13 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4B6FE3A685D for ; Wed, 11 Nov 2009 07:32:13 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8FBQ-00047w-82; Wed, 11 Nov 2009 09:32:32 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 11 Nov 2009 10:32:34 -0500 From: Brian Rosen To: "Dawson, Martin" , James Polk , "Ray.Bellis@nominet.org.uk" , ecrit Message-ID: Thread-Topic: [Ecrit] Direct access - the "normal" call-path Thread-Index: AcpikeYZIlbYCeWnS8GSJvKLl7QnHgAA50tQABOrUQE= In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E54B8@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Direct access - the "normal" call-path X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:32:14 -0000 First of all, Ray, if your normal call path is direct over the Internet, send it direct over the Internet. "We" (at least North American PSAPs upgraded to NG9-1-1) will take them. There may end up being some kind of formal introduction process involving testing, and possibly a credential, but we haven't worked anything like that out yet. Calls would be accepted from unknown sources as long as there wasn't an attack in progress which we didn't have better filtering for. As I mentioned before, we may end up with some transitive trust mechanisms such that if the U.K. PSAP upgraded to IP connectivity compatible with phonebcp, and you had a credential they trusted, the U.S. PSAPs may trust you. That might occur if one of your employees came to the U.S. and used your PBX with a softclient from a Starbucks. It will work. Such mechanisms aren't described in phonebcp. I don't think they have to be. We're not looking for any phone behavior, and since all we are looking for in the proxy is TLS with mutual auth, we don't need anything there for proxies either. I want calls sent on the normal call path: through whatever proxies you normally use. They have to route per the Route headers and Request URI of course. Sounds like that would be what you normally do, which is good. Right now, you send 999 calls over the PSTN. I do hope you will have "SIP Trunking" to replace your E1s or whatever your PSTN connection is now. We would prefer your emergency calls to come that way, through your carrier, as they do now. But if you have a good reason to send them direct, do it as long as they meet phonebcp requirements. We'd LOVE a good Identity header btw. Brian On 11/11/09 1:30 AM, "Dawson, Martin" wrote: > An emergency call is not "normal" so "normal" isn't an argument - nor a > panacea. > > If a domain/UA is so locked down that SIP invites can only go to a specific > proxy then that's either a proxy scenario (not direct) or the domain should > also have LoST locked down so the PSAP URI points at the proxy it wants... it > can look like direct to the client but still be proxy. > > There's plenty to be said for the proxy using the direct recommendations as > well. Having an emergency specific proxy registration (on behalf of the UA) > has benefits in terms of ability to prioritise call back. I don't think this > draft is in conflict with phonebcp. > > If the jurisdiction can't afford the horsepower to support the > registration/callback then they don't have to. The facility is negotiated; it > has to be. I'm sceptical that it's as significant as all that. > > Heck yes, applying policy based on location (by value or reference) is > recommended. Direct mode simplifies these considerations. > > I'm still waiting for someone to point me at the part of phonebcp that > explains how VSPs/proxies are supposed to be authenticated/authorized in order > for this subscriber identity validation to occur. I honestly never thought > that was part of the requirements or in scope; it's a recent addition from my > perspective. I thought that the typical "proxy" that we were referring to was > an enterprise soft switch - not arbitrary foreign VSPs. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Wednesday, 11 November 2009 4:43 PM > To: Ray.Bellis@nominet.org.uk; ecrit > Subject: Re: [Ecrit] Direct access - the "normal" call-path > > Ray > > What's the normal SIP signaling flow between your SIP UA (i.e., > phone) and another SIP UA? > > Does this go through a proxy server? > > Does it have to go through a proxy server? > > Do you agree that some customers would want to lock UAs into > communicating through a certain domain proxy server before it proxies > that signaling out towards its ultimate destination UA? > > Now, with "Direct", any UA can register with a Emergency Services > Routing Proxy (ESRP). Let's call this an Emergency Services Registrar or > "ESR". > > The purpose of an Registrar is to populate a logical location > database with the host-id of the UA, and link that with the user's > URI and the IP address -- thus creating at least 3 entries for the > Proxy to refer to when looking up a SIP request to determine if it > knows a path or destination UA (by IP address) to send this SIP > request towards. > > Any UA probably has already done this within their own domain, with > that domain's Registrar - so that UA can receive SIP requests > forwarded by that domain's proxy server. > > What I understand this ID wanting to accomplish is allowing a UA to > register to more than one domain (which I normally don't have an > issue with), but that second domain to only be used by a certain > application -- based on attempts to contact the sos URN (i.e. dialing > 911 or 112 or 999, depending on where you are). > > Now, if your UA's domain is open and free of access, this will not be > a problem. > > But, if your domain is more constrained, your first hop proxy server > for sos calls just might have a problem being contacted, because it > is outside of a trust boundary -- i.e., you attempt to directly > contact the ESRP without going through any internal domain proxy or > B2BUA or SBC first. This can be a problem. > > This also flies in the face of what phoneBCP is currently defining -- > which isn't really that great -- because most of what we should be > doing is complementary. > > Besides, imagine the cost of resources it'll take to operate this > ESR, with all these registrations -- that really can't be rejected, > unless you want to restrict them to having to be within a location > region. That means a PIDF-LO will have to be in the REGISTER request > to the ESR, which is not normal. All that state information... > that's gonna be a hunking machine in major metropolitan areas. > > unless i'm missing something... > > James > > At 08:17 PM 11/10/2009, Ray.Bellis@nominet.org.uk wrote: >> Regarding Brian's comments in the WG session - >> >> Our corporate PBX does *not* have a subscription to a SIP VSP, and >> as far as I know never will. >> >> Our "normal" call-path for any SIP URI is to send the call *direct* >> to the SIP server listed in the domain's SRV records. >> >> If we had to follow the "use a VSP" rule then the only fallback for >> us would be to send the call over the PSTN, which rather defeats the point. >> >> In the UK the partial integration of PSAPs into the VoIP world is >> currently only possible because the number of VSPs with direct PSTN >> interconnect is very limited (< 20, AFAIK) and because in the >> interim all ES calls arrive over PSTN. >> >> The remaining VSPs that only have IP connectivity number in the >> several hundreds. Since (as above) ES calls have to go over the >> PSTN they then have to route the call via one of the 20 that does >> have PSTN interconnect. >> >> We've *already* got a scale problem - it's not feasible for the >> PSAPs to recognise all of the existing UK-based VSPs, let alone the >> many thousands more that lie outside of our national jurisdiction. >> >> Given these circumstances ECRIT-direct makes a lot of sense, IMHO. >> >> Ray >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Nov 11 07:47:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C943A68E2 for ; Wed, 11 Nov 2009 07:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaUGI3sw2HrN for ; Wed, 11 Nov 2009 07:47:16 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CCC063A68A8 for ; Wed, 11 Nov 2009 07:47:16 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8FQ1-00050g-Bt; Wed, 11 Nov 2009 09:47:37 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 11 Nov 2009 10:47:40 -0500 From: Brian Rosen To: Hannes Tschofenig , Message-ID: Thread-Topic: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft Thread-Index: AcpinQaG4cLQ282QToqv/xfw+ZerWwASUYJo In-Reply-To: <023f01ca629d$091159c0$4b725d85@nsnintra.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340781264_67554279" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:47:22 -0000 > 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. --B_3340781264_67554279 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Small note on this. You say: If it does not use LoST then it needs to obtain the ESRP URI using DHCP I may have missed something, but I think the only circumstance you can get an ESRP URI from DHCP is if you were unable to get to a LoST server. It should not be the case that a device prefers the DHCP server=B9s ESRP URI to attempting to get to a LoST server. It has to be a backup, and should roughly never happen. In the NENA work, we have an unwavering rule: ALL CALLS, without exception, are routed by LoST. I guess I=B9ll qualify =B3without exception=B2 to say agree that if you tried to get to a LoST server and failed, that falling back to DHCP for the ESRP URI is okay. We want LoST to be used because our experience is that although we have lot= s of backups and mechanisms to control routing, that in disasters, often things happen you did not anticipate, and you need to change the basic routing information. There are caches, and there could be reachability issues (although we will try mightily to make sure that if there is a path to the ESRP, there is a path to a LoST server), so I am comfortable with th= e notion that if you can=B9t get to a LoST server, use DHCP. However, it should roughly never happen that you can=B9t get to a LoST server= . Brian On 11/11/09 2:03 AM, "Hannes Tschofenig" wrote: >=20 >=20 > ECRIT-Direct (see > http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt > ) uses = the > following procedure: >=20 > * End host obtains location > * Uses location with LoST to obtain a ESRP URI > * Registers with the ESRP for callback > * Let the ESRP verify location and let it do the routing decision >=20 > The unauthenticated draft (see > http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-0= 6.txt > t> ) uses the following procedure: >=20 > * End host MAY obtain location and MAY use LoST > * If it does not use LoST then it needs to obtain the ESRP URI using DHCP > * Let the ESRP obtain location (if not done already by the end host) and = let > it do the routing decision > * No SIP registration procedure described. >=20 > Which parts do people like / dislike? >=20 > Ciao=20 > Hannes=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --B_3340781264_67554279 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draf= t Small note on this.  You say:

If it does not use LoST then it needs to obtain the ESRP URI using DHCP
I may have missed something, but I think the only circumstance you can get = an ESRP URI from DHCP is if you were unable to get to a LoST server.

It should not be the case that a device prefers the DHCP server’s ESR= P URI to attempting to get to a LoST server.  It has to be a backup, an= d should roughly never happen.

In the NENA work, we have an unwavering rule: ALL CALLS, without exception,= are routed by LoST.
I guess I’ll qualify “without exception” to say agree tha= t if you tried to get to a LoST server and failed, that falling back to DHCP= for the ESRP URI is okay.

We want LoST to be used because our experience is that although we have lot= s of backups and mechanisms to control routing, that in disasters, often thi= ngs happen you did not anticipate, and you need to change the basic routing = information.  There are caches, and there could be reachability issues = (although we will try mightily to make sure that if there is a path to the E= SRP, there is a path to a LoST server), so I am comfortable with the notion = that if you can’t get to a LoST server, use DHCP.  

However, it should roughly never happen that you can’t get to a LoST = server.

Brian


On 11/11/09 2:03 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>

ECRIT-Direct (see http://tools.ietf.org/id/draft-wi= nterbottom-ecrit-direct-01.txt <http:/= /tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt> ) uses th= e following procedure:

* End host obtains location
* Uses location with LoST to obtain a ESRP URI
* Registers with the ESRP for callback
* Let the ESRP verify location and let it do the routing decision

The unauthenticated draft (see http:= //tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.txt <http://tools.ietf.org/id= /draft-schulzrinne-ecrit-unauthenticated-access-06.txt> ) uses the f= ollowing procedure:

* End host MAY obtain location and MAY use LoST
* If it does not use LoST then it needs to obtain the ESRP URI using DHCP<= /SPAN>
* Let the ESRP obtain location (if not done already by the end host) and l= et it do the routing decision
* No SIP registration procedure described.

Which parts do people like / dislike?

Ciao<= SPAN STYLE=3D'font-size:11pt'>
Hannes

___________= ____________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit
--B_3340781264_67554279-- From Martin.Thomson@andrew.com Wed Nov 11 15:46:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D2B3A69DF for ; Wed, 11 Nov 2009 15:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H8iEhVbUdFR for ; Wed, 11 Nov 2009 15:46:21 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id C28C43A6B6E for ; Wed, 11 Nov 2009 15:46:21 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:23520 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S69823AbZKKXqu (ORCPT ); Wed, 11 Nov 2009 17:46:50 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 11 Nov 2009 17:46:50 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 12 Nov 2009 07:46:45 +0800 From: "Thomson, Martin" To: "ecrit@ietf.org" Date: Thu, 12 Nov 2009 07:45:51 +0800 Thread-Topic: Link to review of rough-loc Thread-Index: AcpjKRn7HXeA2+lPRm+y3LrwKsmUmA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E55F2@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Ecrit] Link to review of rough-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:46:22 -0000 SSBkaWQgbm90IHJlY2VpdmUgYW4gZW1haWwgcmVzcG9uc2UgdG8gdGhpcyByZXZpZXcsIGFsdGhv dWdoIEkgY2FuJ3QgcmVtZW1iZXIgdGhlIHJlc29sdXRpb24gYmVjYXVzZSBpdCB3YXMgYSB3aGls ZSBiYWNrLiAgVGhlcmUgYXJlIHByb2JhYmx5IGEgZmV3IGNvbW1lbnRzIGhlcmUgdGhhdCBubyBs b25nZXIgYXBwbHkuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lY3Jp dC9jdXJyZW50L21zZzA2MjM0Lmh0bWwNCg0KSSBwcmV2aW91c2x5IGNvbW1lbnRlZCBvbiB0aGUg YWJzZW5jZSBvZiBkZWZpbml0aW9uIGZvciBjaXZpYyBzZXJ2aWNlIGJvdW5kYXJpZXMuICBUaGF0 IGNvbW1lbnQgc3RpbGwgc3RhbmRzLiAgV2UgY2FuIGluZmVyIGhvdyBib3VuZGFyaWVzIHdvcmss IGFzIEJyaWFuIHBvaW50ZWQgb3V0LCBidXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgc29t ZXRoaW5nIGRvY3VtZW50ZWQgc28gd2UgZG9uJ3QgYWxsIG1ha2UgZGlmZmVyZW50IGluZmVyZW5j ZXMuDQoNCldpdGhvdXQgYSBnb29kIGRlZmluaXRpb24gZm9yIHRoZSBhYm92ZSwgSSBkb24ndCBo YXZlIGEgYW55IGJhc2lzIHVwb24gd2hpY2ggdG8gZXZhbHVhdGUgU2VjdGlvbiAzLjIuMiBvZiBy b3VnaC1sb2MuICBJIGNhbiBndWVzcywgYnV0IEknbSBub3Qgc3VyZSB0aGF0IG15IGd1ZXNzIHdv dWxkIGJlIHRoZSBzYW1lIGFzIG90aGVycywgb3IgdGhhdCBteSBndWVzcyB3b3VsZCBiZSBpbnRl cnByZXRlZCBjb25zaXN0ZW50bHkgYnkgb3RoZXIgbm9kZXMuDQoNCk1heWJlIHdlIG5lZWQgYSBk b2N1bWVudCBkZXNjcmliaW5nIGhvdyB0aGlzIG1pZ2h0IGJlIGRvbmUuICBJIHdvdWxkIGhhdmUg cHJlZmVycmVkIHRoYXQgTG9TVCBkZWZpbmUgdGhpcyBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCi0t TWFydGluDQo= From alexander.mayrhofer@nic.at Fri Nov 13 01:53:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C466C3A6A06 for ; Fri, 13 Nov 2009 01:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.873 X-Spam-Level: X-Spam-Status: No, score=-8.873 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9MnaiyIBJs0 for ; Fri, 13 Nov 2009 01:53:04 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 7D1843A68CF for ; Fri, 13 Nov 2009 01:53:02 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Fri, 13 Nov 2009 10:53:30 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Nov 2009 10:53:29 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508B59297@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST-Synchronization & Loop prevention? Thread-Index: AcpkRycRGYyiHH5vSnaT45Mg8hw0Kg== From: "Alexander Mayrhofer" To: "Ecrit@Ietf. Org" X-XWALL-BCKS: auto Subject: [Ecrit] LoST-Synchronization & Loop prevention? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 09:53:04 -0000 Hello, I've just thought about something that i haven't seen discussed in any of the documents yet. Assume that there are 3 forest guides, which have the following "sync relations". A -------- B \ / \ / \ / \ / C Assuming that "A" gets updated, it would then send Sync messages to B (and probably C). B in turn would probably redistribute the message received from A over to C (because from the perspective of B, it compromises new information to be distributed) - B wouldn't know that C has already received the information from A directly.=20 I understand that "source", "sourceid" and "last updated" could be used to identify whether a message has already been seen. However, my guts feeling tells me that there could be situations in which a FG rewrites information that it has received, and essentially creates messages that cannot be correlated with the original message (or, simple implementation problems...)=20 I understand it looks like NNTP - I'm just curious if loop prevention has been considered, and discussed in detail ... "injecting" a loop into the global network of FGs could be a very effective DoS attack... Alex From drage@alcatel-lucent.com Sun Nov 15 09:37:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DB33A697A for ; Sun, 15 Nov 2009 09:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekbYRZcSpkQT for ; Sun, 15 Nov 2009 09:37:46 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id B75BE3A67F5 for ; Sun, 15 Nov 2009 09:37:45 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAFHbccM024194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 15 Nov 2009 18:37:38 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 15 Nov 2009 18:37:38 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , "James M. Polk" , Cullen Jennings , ECRIT Date: Sun, 15 Nov 2009 18:37:37 +0100 Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: AcpijxbqNdtylsKYSjquUxEQHxqewAAAIOBAANwD9uA= Message-ID: References: <02E78979-FD18-432F-9ADC-72D45C9376F6@cisco.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA313E@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8EA327E@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 17:37:47 -0000 In answer to this thread I would note two things (RFC 3261 says): A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. 1) The above could result in the UAC automatically generating a BYE request= on reception of the SDP offer and therefore the emergency call failing. If= we are going to allow this behaviour, then we should include a warning of = the potential effects. 2) In this case the PSAP now has to generate the SDP offer. What are our re= commendations on what that offer should contain. How do we know it was a vo= ice terminal that generated the call, and how do we cater for the potential= that it was a real time text terminal that generated the call, or at least= the case where the user wished to use real time text. (So much easier if t= he user actually indicates what they want).=20 regards Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Wednesday, November 11, 2009 5:30 AM > To: James M. Polk; Cullen Jennings; ECRIT > Subject: Re: [Ecrit] Question about phone BCP >=20 > Hi James, >=20 > Thanks for the lecture. > My belief is that if you want stuff to just work the more=20 > simple it is the better. I actually see phone BCP was a SIP=20 > profile as a consequence I don't see why the UA can't insist=20 > on putting an SDP element in there. Surely RFC3261 says that=20 > a SIP proxy has to be able to deal with delayed offer, not=20 > that a client MUST send it? >=20 > Cheers > James >=20 >=20 > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, 11 November 2009 4:23 PM > > To: Winterbottom, James; Cullen Jennings; ECRIT > > Subject: Re: [Ecrit] Question about phone BCP > >=20 > > At 06:23 PM 11/10/2009, Winterbottom, James wrote: > > >Hi Cullen, > > > > > >My thoughts on this stuff are that the more ways that you have of=20 > > >doing it the less chance you have of stuff interoperating. I would=20 > > >prefer to see the absolute minimum set that must be supported in=20 > > >phone > > BCP. > >=20 > > James > >=20 > > "Delayed offer" is a mandatory to implement part of SIP,=20 > per RFC 3261.=20 > > Are you wanting to officially update RFC 3261 for this minimizing=20 > > optimization? > >=20 > > Further, there are a LOT of products out there that currently do=20 > > Delayed offer, most of this is because customers/operators have=20 > > demanded it be this way (as they believe they have greater control=20 > > with Delayed offer that normal or early offer). > >=20 > > IMO there needs to be a consensus from those operators that this is=20 > > worth bypassing their requirement (for Delayed Offer) for. > >=20 > > James > >=20 > >=20 > > >Cheers > > >James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > > Behalf > > Of > > > > Cullen Jennings > > > > Sent: Wednesday, 11 November 2009 11:18 AM > > > > To: ECRIT > > > > Subject: [Ecrit] Question about phone BCP > > > > > > > > > > > > So SIP allows INVITEs with or without an SDP offer. As we all=20 > > > > realize, this adds ways to use SIP but it allowed both the fast=20 > > > > setup when the offer was in an INVITE and it allowed SIP to=20 > > > > gateway to many other protocols where one needed to=20 > have an INVITE with no offer. > > > > > > > > I have received complaints that Phone BCP currently=20 > profiles SIP=20 > > > > to a subset of it by eliminating the option of an=20 > INVITE with no=20 > > > > offer. I was wondering if there is a strong reason=20 > that this was=20 > > > > needed in Phone BCP. > > > > > > > > Cullen > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From br@brianrosen.net Tue Nov 17 07:04:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4553228C214 for ; Tue, 17 Nov 2009 07:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvZKFzB2WUgN for ; Tue, 17 Nov 2009 07:04:06 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1DCDD28C0FE for ; Tue, 17 Nov 2009 07:04:06 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NAPaz-0005Br-R4; Tue, 17 Nov 2009 09:03:54 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 17 Nov 2009 10:03:54 -0500 From: Brian Rosen To: "DRAGE, Keith (Keith)" , James Winterbottom , James Polk , Cullen Jennings , ECRIT Message-ID: Thread-Topic: [Ecrit] Question about phone BCP Thread-Index: AcpijxbqNdtylsKYSjquUxEQHxqewAAAIOBAANwD9uAAZeDkGg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:04:07 -0000 I am about to release the update, and wanted to address this. First of all, I intended to change MUST include an offer to MAY. I could change it to SHOULD, but then I need text for when it wouldn't. I could use the basic argument that emergency calls come in many different media, and the PSAP doesn't know what the UAC wants, but that is not exactly new news. The text referenced talks about an update of an existing session. Strictly speaking, the text that says MUST include an offer is talking about the initial INVITE. Is this really an issue? If the UAC doing the reINVITE doesn't specify something the UAS receiving the INVITE can handle (as represented by the original offer/answer), then there is the possibility the call would fail. Seems reasonable to me, and discussed well enough in 3261, which is referenced by phonebcp. Do we need to make it more obvious? If the original INVITE contains no offer, than the PSAP may well have to offer several audio, several video and a text codec or two. Is that not obvious? A full featured video device may well offer all of that normally, so it's not that weird. I guess a device expecting only one or two audio codecs might have to plow through a lot of dreck, but it's supposed to be able to do that. I'd actually think that fact that such an offer may push the 2XX over a packet may be more onerous than all the SDP to wade through. If I need to open up -framework, a line or two about this issue wouldn't be a bad idea. Brian On 11/15/09 12:37 PM, "DRAGE, Keith (Keith)" wrote: > In answer to this thread I would note two things (RFC 3261 says): > > A UAS providing an offer in a 2xx (because the INVITE did not contain > an offer) SHOULD construct the offer as if the UAS were making a > brand new call, subject to the constraints of sending an offer that > updates an existing session, as described in [13] in the case of SDP. > Specifically, this means that it SHOULD include as many media formats > and media types that the UA is willing to support. The UAS MUST > ensure that the session description overlaps with its previous > session description in media formats, transports, or other parameters > that require support from the peer. This is to avoid the need for > the peer to reject the session description. If, however, it is > unacceptable to the UAC, the UAC SHOULD generate an answer with a > valid session description, and then send a BYE to terminate the > session. > > 1) The above could result in the UAC automatically generating a BYE request on > reception of the SDP offer and therefore the emergency call failing. If we are > going to allow this behaviour, then we should include a warning of the > potential effects. > > 2) In this case the PSAP now has to generate the SDP offer. What are our > recommendations on what that offer should contain. How do we know it was a > voice terminal that generated the call, and how do we cater for the potential > that it was a real time text terminal that generated the call, or at least the > case where the user wished to use real time text. (So much easier if the user > actually indicates what they want). > > regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Winterbottom, James >> Sent: Wednesday, November 11, 2009 5:30 AM >> To: James M. Polk; Cullen Jennings; ECRIT >> Subject: Re: [Ecrit] Question about phone BCP >> >> Hi James, >> >> Thanks for the lecture. >> My belief is that if you want stuff to just work the more >> simple it is the better. I actually see phone BCP was a SIP >> profile as a consequence I don't see why the UA can't insist >> on putting an SDP element in there. Surely RFC3261 says that >> a SIP proxy has to be able to deal with delayed offer, not >> that a client MUST send it? >> >> Cheers >> James >> >> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Wednesday, 11 November 2009 4:23 PM >>> To: Winterbottom, James; Cullen Jennings; ECRIT >>> Subject: Re: [Ecrit] Question about phone BCP >>> >>> At 06:23 PM 11/10/2009, Winterbottom, James wrote: >>>> Hi Cullen, >>>> >>>> My thoughts on this stuff are that the more ways that you have of >>>> doing it the less chance you have of stuff interoperating. I would >>>> prefer to see the absolute minimum set that must be supported in >>>> phone >>> BCP. >>> >>> James >>> >>> "Delayed offer" is a mandatory to implement part of SIP, >> per RFC 3261. >>> Are you wanting to officially update RFC 3261 for this minimizing >>> optimization? >>> >>> Further, there are a LOT of products out there that currently do >>> Delayed offer, most of this is because customers/operators have >>> demanded it be this way (as they believe they have greater control >>> with Delayed offer that normal or early offer). >>> >>> IMO there needs to be a consensus from those operators that this is >>> worth bypassing their requirement (for Delayed Offer) for. >>> >>> James >>> >>> >>>> Cheers >>>> James >>>> >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Cullen Jennings >>>>> Sent: Wednesday, 11 November 2009 11:18 AM >>>>> To: ECRIT >>>>> Subject: [Ecrit] Question about phone BCP >>>>> >>>>> >>>>> So SIP allows INVITEs with or without an SDP offer. As we all >>>>> realize, this adds ways to use SIP but it allowed both the fast >>>>> setup when the offer was in an INVITE and it allowed SIP to >>>>> gateway to many other protocols where one needed to >> have an INVITE with no offer. >>>>> >>>>> I have received complaints that Phone BCP currently >> profiles SIP >>>>> to a subset of it by eliminating the option of an >> INVITE with no >>>>> offer. I was wondering if there is a strong reason >> that this was >>>>> needed in Phone BCP. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From dromasca@avaya.com Tue Nov 17 07:16:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A163A6AB3; Tue, 17 Nov 2009 07:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdaDxUrmo8zu; Tue, 17 Nov 2009 07:15:59 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 914513A6970; Tue, 17 Nov 2009 07:15:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,758,1249272000"; d="scan'208";a="163506652" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Nov 2009 10:15:55 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Nov 2009 10:15:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Nov 2009 16:15:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802 Emergency Services Thread-Index: AcpnmNKjAirVuJ2LQ3GdGlHql4q96Q== From: "Romascanu, Dan (Dan)" To: Cc: iesg@ietf.org Subject: [Ecrit] IEEE 802 Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:16:00 -0000 FYI, the IEEE 802 Executive Committee Study Group on Emergency Services are meeting this week. You may find information about the goals and schedules of the SG at http://grouper.ieee.org/groups/802/ecsg/ Dan From rbarnes@bbn.com Tue Nov 17 07:29:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF6928C16A; Tue, 17 Nov 2009 07:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQaEUmoa6DFh; Tue, 17 Nov 2009 07:29:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D450A3A6AB7; Tue, 17 Nov 2009 07:29:09 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NAPzP-0004vM-BI; Tue, 17 Nov 2009 10:29:07 -0500 Message-Id: From: Richard Barnes To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 10:29:06 -0500 References: X-Mailer: Apple Mail (2.936) Cc: ecrit@ietf.org, iesg@ietf.org Subject: Re: [Ecrit] IEEE 802 Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:29:10 -0000 Dan, Thanks for the note. I would encourage ECRIT participants to take a look at what this group is doing, since it is likely to have a strong interaction with ECRIT technologies, for example with respect to unauthenticated calling. At the ESW a couple of weeks ago, James Winterbottom, Martin Dawson, and I spent a fair bit of time talking with the SG chair (Geoff Thompson), and based on the initial sketch he gave of when they have in mind (essentially a layer-2 tunnel to an "emergency services router"), there may need to be a lot more dialogue about how layer 2 can best support ECRIT. --Richard On Nov 17, 2009, at 10:15 AM, Romascanu, Dan (Dan) wrote: > FYI, the IEEE 802 Executive Committee Study Group on Emergency > Services > are meeting this week. You may find information about the goals and > schedules of the SG at http://grouper.ieee.org/groups/802/ecsg/ > > Dan > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Nov 17 09:12:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A83A6986 for ; Tue, 17 Nov 2009 09:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C466-AzChazZ for ; Tue, 17 Nov 2009 09:12:20 -0800 (PST) Received: from blu0-omc4-s16.blu0.hotmail.com (blu0-omc4-s16.blu0.hotmail.com [65.55.111.155]) by core3.amsl.com (Postfix) with ESMTP id 398D33A6920 for ; Tue, 17 Nov 2009 09:12:20 -0800 (PST) Received: from BLU137-W37 ([65.55.111.137]) by blu0-omc4-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:12:18 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_41bbd7c0-2a7f-410f-b201-bb04c7fff893_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , "dromasca@avaya.com" Date: Tue, 17 Nov 2009 09:12:18 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2009 17:12:18.0782 (UTC) FILETIME=[1E3B57E0:01CA67A9] Cc: ecrit@ietf.org Subject: Re: [Ecrit] IEEE 802 Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:12:22 -0000 --_41bbd7c0-2a7f-410f-b201-bb04c7fff893_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the second instantiation of an Emergency Services Study Group withi= n IEEE 802. The first instantiation (within IEEE 802.21) did not succeed = in getting its proposed PAR approved=2C so an IEEE 802-wide Executive Commi= ttee Study group was formed to draw in input from a larger group.=20 There were a number of issues which lead to the withdrawal of the original = PAR=2C some of which were summarized by Tony Jeffree in his PAR review: http://www.ieee802.org/secmail/msg11779.html Aside from those issues (several of which may still apply to the new PAR)= =2C there may be questions about the type of "layer 2 tunnel" that is being= proposed. In one scenario=2C this would merely be an "emergency services VLAN". Thi= s would presumably provide access to services required to make an emergency= call and not much else. However=2C from an IP (and SIP) point of view=2C = the environment appears normal. Aside from some potentially unique topolog= ical aspects=2C I would assume that no changes to the ECRIT architecture wo= uld be required.=20 However=2C there was also discussion in the IEEE 802.21 study group about a= n "emergency services Ethertype". If the new Ethertype is not for use in= "MAC in MAC" encapsulation=2C this would raise the question of exactly how= IP (or SIP for that matter) would function. Since a new Ethertype would n= ot be the IPv4 or IPv6 Ethertype=2C IP as we know it could not run over it.= =20 So unless it is the intent to run signaling over "bare metal" (e.g. SIP ove= r Ethernet) it's not clear to me how an Emergency Call could be placed.=20 =20 > Dan=2C >=20 > Thanks for the note. I would encourage ECRIT participants to take a =20 > look at what this group is doing=2C since it is likely to have a strong = =20 > interaction with ECRIT technologies=2C for example with respect to =20 > unauthenticated calling. At the ESW a couple of weeks ago=2C James =20 > Winterbottom=2C Martin Dawson=2C and I spent a fair bit of time talking = =20 > with the SG chair (Geoff Thompson)=2C and based on the initial sketch he = =20 > gave of when they have in mind (essentially a layer-2 tunnel to an =20 > "emergency services router")=2C there may need to be a lot more dialogue = =20 > about how layer 2 can best support ECRIT. >=20 > --Richard >=20 >=20 >=20 >=20 > On Nov 17=2C 2009=2C at 10:15 AM=2C Romascanu=2C Dan (Dan) wrote: >=20 > > FYI=2C the IEEE 802 Executive Committee Study Group on Emergency =20 > > Services > > are meeting this week. You may find information about the goals and > > schedules of the SG at http://grouper.ieee.org/groups/802/ecsg/ = --_41bbd7c0-2a7f-410f-b201-bb04c7fff893_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the second instantiation of an Emergency Services Study Group withi= n IEEE 802. =3B =3B The first instantiation (within IEEE 802.21) di= d not succeed in getting its proposed PAR approved=2C so an IEEE 802-wide E= xecutive Committee Study group was formed to draw in input from a larger gr= oup.

There were a number of issues which lead to the withdrawal of = the original PAR=2C some of which were summarized by Tony Jeffree in his PA= R review:
http://www.ieee802.org/secmail/msg11779.html

Aside from= those issues (several of which may still apply to the new PAR)=2C there ma= y be questions about the type of "layer 2 tunnel" that is being proposed.
In one scenario=2C this would merely be an "emergency services VLAN".=  =3B =3B This would presumably provide access to services required = to make an emergency call and not much else. =3B However=2C from an IP = (and SIP) point of view=2C the environment appears normal. =3B Aside fr= om some potentially unique topological aspects=2C I would assume that no ch= anges to the ECRIT architecture would be required.

However=2C there= was also discussion in the IEEE 802.21 study group about an "emergency ser= vices Ethertype". =3B =3B =3B If the new Ethertype is not for u= se in "MAC in MAC" encapsulation=2C this would raise the question of exactl= y how IP (or SIP for that matter) would function. =3B Since a new Ether= type would not be the IPv4 or IPv6 Ethertype=2C IP as we know it could not = run over it.
So unless it is the intent to run signaling over "bare met= al" (e.g. SIP over Ethernet) it's not clear to me how an Emergency Call cou= ld be placed.


 =3B

>=3B Dan=2C
>=3B
>= =3B Thanks for the note. I would encourage ECRIT participants to take a <= br>>=3B look at what this group is doing=2C since it is likely to have a = strong
>=3B interaction with ECRIT technologies=2C for example with = respect to
>=3B unauthenticated calling. At the ESW a couple of wee= ks ago=2C James
>=3B Winterbottom=2C Martin Dawson=2C and I spent a = fair bit of time talking
>=3B with the SG chair (Geoff Thompson)=2C = and based on the initial sketch he
>=3B gave of when they have in mi= nd (essentially a layer-2 tunnel to an
>=3B "emergency services rout= er")=2C there may need to be a lot more dialogue
>=3B about how laye= r 2 can best support ECRIT.
>=3B
>=3B --Richard
>=3B
&g= t=3B
>=3B
>=3B
>=3B On Nov 17=2C 2009=2C at 10:15 AM=2C R= omascanu=2C Dan (Dan) wrote:
>=3B
>=3B >=3B FYI=2C the IEEE 80= 2 Executive Committee Study Group on Emergency
>=3B >=3B Services<= br>>=3B >=3B are meeting this week. You may find information about the = goals and
>=3B >=3B schedules of the SG at http://grouper.ieee.org/g= roups/802/ecsg/
= --_41bbd7c0-2a7f-410f-b201-bb04c7fff893_-- From dromasca@avaya.com Wed Nov 18 02:14:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAA93A68FB for ; Wed, 18 Nov 2009 02:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W6-yoZjVwny for ; Wed, 18 Nov 2009 02:14:51 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C05863A68CD for ; Wed, 18 Nov 2009 02:14:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,764,1249272000"; d="scan'208,217";a="163626256" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Nov 2009 05:14:46 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Nov 2009 05:14:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6837.F1CDDE15" Date: Wed, 18 Nov 2009 11:14:39 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IEEE 802 Emergency Services Thread-Index: AcpnqR7cAVp2syfcQByVf4VXOR0aNQAjgDLA References: , From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Cc: ecrit@ietf.org Subject: Re: [Ecrit] IEEE 802 Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 10:14:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6837.F1CDDE15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This needs to be followed and we may want to provide comments to their proposed charter. The presentation at https://mentor.ieee.org/802-sg-emergency-services/dcn/09/sg-emergency-se rvices-09-0008-00-ESSG-es-preso-for-wgs-091116.pdf still speaks about 'Provide Packet Type for ES' for example, don't know if they mean Ethertype or some other way of marking. =20 Dan =20 =20 =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, November 17, 2009 7:12 PM To: rbarnes@bbn.com; Romascanu, Dan (Dan) Cc: ecrit@ietf.org Subject: RE: [Ecrit] IEEE 802 Emergency Services =09 =09 This is the second instantiation of an Emergency Services Study Group within IEEE 802. The first instantiation (within IEEE 802.21) did not succeed in getting its proposed PAR approved, so an IEEE 802-wide Executive Committee Study group was formed to draw in input from a larger group.=20 =09 There were a number of issues which lead to the withdrawal of the original PAR, some of which were summarized by Tony Jeffree in his PAR review: http://www.ieee802.org/secmail/msg11779.html =09 Aside from those issues (several of which may still apply to the new PAR), there may be questions about the type of "layer 2 tunnel" that is being proposed. =09 In one scenario, this would merely be an "emergency services VLAN". This would presumably provide access to services required to make an emergency call and not much else. However, from an IP (and SIP) point of view, the environment appears normal. Aside from some potentially unique topological aspects, I would assume that no changes to the ECRIT architecture would be required.=20 =09 However, there was also discussion in the IEEE 802.21 study group about an "emergency services Ethertype". If the new Ethertype is not for use in "MAC in MAC" encapsulation, this would raise the question of exactly how IP (or SIP for that matter) would function. Since a new Ethertype would not be the IPv4 or IPv6 Ethertype, IP as we know it could not run over it.=20 So unless it is the intent to run signaling over "bare metal" (e.g. SIP over Ethernet) it's not clear to me how an Emergency Call could be placed.=20 =09 =09 =20 =09 > Dan, >=20 > Thanks for the note. I would encourage ECRIT participants to take a=20 > look at what this group is doing, since it is likely to have a strong=20 > interaction with ECRIT technologies, for example with respect to=20 > unauthenticated calling. At the ESW a couple of weeks ago, James=20 > Winterbottom, Martin Dawson, and I spent a fair bit of time talking=20 > with the SG chair (Geoff Thompson), and based on the initial sketch he=20 > gave of when they have in mind (essentially a layer-2 tunnel to an=20 > "emergency services router"), there may need to be a lot more dialogue=20 > about how layer 2 can best support ECRIT. >=20 > --Richard >=20 >=20 >=20 >=20 > On Nov 17, 2009, at 10:15 AM, Romascanu, Dan (Dan) wrote: >=20 > > FYI, the IEEE 802 Executive Committee Study Group on Emergency=20 > > Services > > are meeting this week. You may find information about the goals and > > schedules of the SG at http://grouper.ieee.org/groups/802/ecsg/ =09 ------_=_NextPart_001_01CA6837.F1CDDE15 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This=20 needs to be followed and we may want to provide comments to their = proposed=20 charter. The presentation at https://mentor.ieee.org/802-sg-emergency-services/dcn/09/sg-= emergency-services-09-0008-00-ESSG-es-preso-for-wgs-091116.pdf=  still speaks about 'Provide Packet Type for = ES' for=20 example, don't know if they mean Ethertype or some other way of=20 marking.
 
Dan
 

 

 

<= BR>
From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Tuesday, November = 17, 2009=20 7:12 PM
To: rbarnes@bbn.com; Romascanu, Dan = (Dan)
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] IEEE 802 Emergency=20 Services

This is the second instantiation of an Emergency Services = Study=20 Group within IEEE 802.   The first instantiation (within = IEEE=20 802.21) did not succeed in getting its proposed PAR approved, so an = IEEE=20 802-wide Executive Committee Study group was formed to draw in input = from a=20 larger group.

There were a number of issues which lead to the=20 withdrawal of the original PAR, some of which were summarized by Tony = Jeffree=20 in his PAR=20 review:
http://www.ieee802.org/secmail/msg11779.html

Aside = from=20 those issues (several of which may still apply to the new PAR), there = may be=20 questions about the type of "layer 2 tunnel" that is being = proposed.

In=20 one scenario, this would merely be an "emergency services = VLAN".  =20 This would presumably provide access to services required to make an = emergency=20 call and not much else.  However, from an IP (and SIP) point of = view, the=20 environment appears normal.  Aside from some potentially unique=20 topological aspects, I would assume that no changes to the ECRIT = architecture=20 would be required.

However, there was also discussion in the = IEEE=20 802.21 study group about an "emergency services = Ethertype".   =20 If the new Ethertype is not for use in "MAC in MAC" encapsulation, = this would=20 raise the question of exactly how IP (or SIP for that matter) would=20 function.  Since a new Ethertype would not be the IPv4 or IPv6 = Ethertype,=20 IP as we know it could not run over it.
So unless it is the intent = to run=20 signaling over "bare metal" (e.g. SIP over Ethernet) it's not clear to = me how=20 an Emergency Call could be placed.


 

> = Dan,
>=20
> Thanks for the note. I would encourage ECRIT participants to = take a=20
> look at what this group is doing, since it is likely to have = a strong=20
> interaction with ECRIT technologies, for example with respect = to=20
> unauthenticated calling. At the ESW a couple of weeks ago, = James=20
> Winterbottom, Martin Dawson, and I spent a fair bit of time = talking=20
> with the SG chair (Geoff Thompson), and based on the initial = sketch=20 he
> gave of when they have in mind (essentially a layer-2 = tunnel to an=20
> "emergency services router"), there may need to be a lot more = dialogue
> about how layer 2 can best support ECRIT.
> =
>=20 --Richard
>
>
>
>
> On Nov 17, 2009, = at=20 10:15 AM, Romascanu, Dan (Dan) wrote:
>
> > FYI, the = IEEE 802=20 Executive Committee Study Group on Emergency
> > = Services
>=20 > are meeting this week. You may find information about the goals=20 and
> > schedules of the SG at=20 = http://grouper.ieee.org/groups/802/ecsg/
------_=_NextPart_001_01CA6837.F1CDDE15-- From rbarnes@bbn.com Wed Nov 18 07:39:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9F028C0E9 for ; Wed, 18 Nov 2009 07:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ35ijOv7SjE for ; Wed, 18 Nov 2009 07:39:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 05D1A28C0E7 for ; Wed, 18 Nov 2009 07:39:25 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NAmcs-00015R-9q; Wed, 18 Nov 2009 10:39:22 -0500 Message-Id: <2A0F19AB-C0CA-49B1-A80F-798688643658@bbn.com> From: Richard Barnes To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--1068792399 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 10:39:25 -0500 References: , X-Mailer: Apple Mail (2.936) Cc: ecrit@ietf.org Subject: Re: [Ecrit] IEEE 802 Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:39:26 -0000 --Apple-Mail-1--1068792399 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit When I talked to Geoff, he was using the term "Ethertype", but he may have been using that as a representative example. --Richard On Nov 18, 2009, at 5:14 AM, Romascanu, Dan (Dan) wrote: > This needs to be followed and we may want to provide comments to > their proposed charter. The presentation at https://mentor.ieee.org/802-sg-emergency-services/dcn/09/sg-emergency-services-09-0008-00-ESSG-es-preso-for-wgs-091116.pdf > still speaks about 'Provide Packet Type for ES' for example, don't > know if they mean Ethertype or some other way of marking. > > Dan > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, November 17, 2009 7:12 PM > To: rbarnes@bbn.com; Romascanu, Dan (Dan) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] IEEE 802 Emergency Services > > This is the second instantiation of an Emergency Services Study > Group within IEEE 802. The first instantiation (within IEEE > 802.21) did not succeed in getting its proposed PAR approved, so an > IEEE 802-wide Executive Committee Study group was formed to draw in > input from a larger group. > > There were a number of issues which lead to the withdrawal of the > original PAR, some of which were summarized by Tony Jeffree in his > PAR review: > http://www.ieee802.org/secmail/msg11779.html > > Aside from those issues (several of which may still apply to the new > PAR), there may be questions about the type of "layer 2 tunnel" that > is being proposed. > > In one scenario, this would merely be an "emergency services > VLAN". This would presumably provide access to services required > to make an emergency call and not much else. However, from an IP > (and SIP) point of view, the environment appears normal. Aside from > some potentially unique topological aspects, I would assume that no > changes to the ECRIT architecture would be required. > > However, there was also discussion in the IEEE 802.21 study group > about an "emergency services Ethertype". If the new Ethertype is > not for use in "MAC in MAC" encapsulation, this would raise the > question of exactly how IP (or SIP for that matter) would function. > Since a new Ethertype would not be the IPv4 or IPv6 Ethertype, IP as > we know it could not run over it. > So unless it is the intent to run signaling over "bare metal" (e.g. > SIP over Ethernet) it's not clear to me how an Emergency Call could > be placed. > > > > > > Dan, > > > > Thanks for the note. I would encourage ECRIT participants to take a > > look at what this group is doing, since it is likely to have a > strong > > interaction with ECRIT technologies, for example with respect to > > unauthenticated calling. At the ESW a couple of weeks ago, James > > Winterbottom, Martin Dawson, and I spent a fair bit of time talking > > with the SG chair (Geoff Thompson), and based on the initial > sketch he > > gave of when they have in mind (essentially a layer-2 tunnel to an > > "emergency services router"), there may need to be a lot more > dialogue > > about how layer 2 can best support ECRIT. > > > > --Richard > > > > > > > > > > On Nov 17, 2009, at 10:15 AM, Romascanu, Dan (Dan) wrote: > > > > > FYI, the IEEE 802 Executive Committee Study Group on Emergency > > > Services > > > are meeting this week. You may find information about the goals > and > > > schedules of the SG at http://grouper.ieee.org/groups/802/ecsg/ --Apple-Mail-1--1068792399 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable When I talked to Geoff, he was = using the term "Ethertype", but he may have been using that as a = representative = example.
--Richard



On Nov 18, 2009, at 5:14 AM, Romascanu, Dan (Dan) wrote:

This needs to be followed and we may want to provide = comments to their proposed charter. The presentation at https://mentor.ieee.org/802-sg-emergency-services/dcn/09/sg= -emergency-services-09-0008-00-ESSG-es-preso-for-wgs-091116.pdf=  still speaks about 'Provide Packet Type for ES' for example, don't = know if they mean Ethertype or some other way of = marking.
 
Dan
<= div> 

 

 


From: Bernard Aboba [mailto:bernard_aboba@hotmail.com= ] 
Sent: Tuesday, November 17, 2009 = 7:12 PM
To: rbarnes@bbn.com; Romascanu, Dan = (Dan)
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] IEEE 802 = Emergency Services

This is the second = instantiation of an Emergency Services Study Group within IEEE = 802.   The first instantiation (within IEEE 802.21) did not = succeed in getting its proposed PAR approved, so an IEEE 802-wide = Executive Committee Study group was formed to draw in input from a = larger group. 

There were a number = of issues which lead to the withdrawal of the original PAR, some of = which were summarized by Tony Jeffree in his PAR review:
http://www.ieee802.o= rg/secmail/msg11779.html

Aside from those issues (several of = which may still apply to the new PAR), there may be questions about the = type of "layer 2 tunnel" that is being proposed.

In one scenario, = this would merely be an "emergency services VLAN".   This = would presumably provide access to services required to make an = emergency call and not much else.  However, from an IP (and SIP) = point of view, the environment appears normal.  Aside from some = potentially unique topological aspects, I would assume that no changes = to the ECRIT architecture would be required. 

However, there was = also discussion in the IEEE 802.21 study group about an "emergency = services Ethertype".    If the new Ethertype is not for = use in "MAC in MAC" encapsulation, this would raise the question of = exactly how IP (or SIP for that matter) would function.  Since a = new Ethertype would not be the IPv4 or IPv6 Ethertype, IP as we know it = could not run over it. 
So unless it is the = intent to run signaling over "bare metal" (e.g. SIP over Ethernet) it's = not clear to me how an Emergency Call could be placed. 


 

>= ; Dan,
> 
> = Thanks for the note. I would encourage ECRIT participants to take a 
> look at what this = group is doing, since it is likely to have a strong 
> interaction with = ECRIT technologies, for example with respect to 
> unauthenticated = calling. At the ESW a couple of weeks ago, James 
> Winterbottom, = Martin Dawson, and I spent a fair bit of time talking 
> with the SG chair = (Geoff Thompson), and based on the initial sketch he 
> gave of when they = have in mind (essentially a layer-2 tunnel to an 
> "emergency = services router"), there may need to be a lot more dialogue 
> about how layer 2 = can best support ECRIT.
> 
> = --Richard
> 
> 
> 
> 
> On Nov 17, 2009, = at 10:15 AM, Romascanu, Dan (Dan) wrote:
> 
> > FYI, the IEEE = 802 Executive Committee Study Group on Emergency 
> > = Services
> > are meeting this week. You may find information = about the goals and
> > schedules of the SG at http://grouper.ieee.org/= groups/802/ecsg/

<= /div>= --Apple-Mail-1--1068792399-- From jmpolk@cisco.com Wed Nov 18 09:31:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C2F3A6837 for ; Wed, 18 Nov 2009 09:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRId6tOAfJqg for ; Wed, 18 Nov 2009 09:31:53 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C662C3A67A4 for ; Wed, 18 Nov 2009 09:31:53 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACK+A0urR7Ht/2dsb2JhbACHb7cVhi+Rd4Q7BA X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208";a="224797998" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2009 17:31:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAIHVqZA020234; Wed, 18 Nov 2009 17:31:52 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 09:31:52 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.95.110]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 09:31:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Nov 2009 11:31:49 -0600 To: Brian Rosen , "DRAGE, Keith (Keith)" , James Winterbottom , Cullen Jennings , ECRIT From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Nov 2009 17:31:50.0466 (UTC) FILETIME=[0305E220:01CA6875] Subject: Re: [Ecrit] Question about phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:31:55 -0000 At 09:03 AM 11/17/2009, Brian Rosen wrote: >I am about to release the update, and wanted to address this. > >First of all, I intended to change MUST include an offer to MAY. I could >change it to SHOULD, but then I need text for when it wouldn't. I could use >the basic argument that emergency calls come in many different media, and >the PSAP doesn't know what the UAC wants, but that is not exactly new news. at the same time, if some of us can't keep up with how things generally are (and for what reason they are that way), others will really struggle to understand. >The text referenced talks about an update of an existing session. Strictly >speaking, the text that says MUST include an offer is talking about the >initial INVITE. Is this really an issue? If the UAC doing the reINVITE >doesn't specify something the UAS receiving the INVITE can handle (as >represented by the original offer/answer), then there is the possibility the >call would fail. Seems reasonable to me, and discussed well enough in 3261, >which is referenced by phonebcp. Do we need to make it more obvious? more obvious to others not so skilled in the art is always a good thing on this topic, IMO >If the original INVITE contains no offer, than the PSAP may well have to >offer several audio, several video and a text codec or two. that's the advice of 3261 already. But will folks read 3261? Most will, but it is a big doc to digest all the subtleties. Perhaps giving the section number for the stated behavior in 3261 would help. >Is that not >obvious? A full featured video device may well offer all of that normally, >so it's not that weird. I guess a device expecting only one or two audio >codecs might have to plow through a lot of dreck, but it's supposed to be >able to do that. I'd actually think that fact that such an offer may push >the 2XX over a packet may be more onerous than all the SDP to wade through. > >If I need to open up -framework, a line or two about this issue wouldn't be >a bad idea. > >Brian > > >On 11/15/09 12:37 PM, "DRAGE, Keith (Keith)" >wrote: > > > In answer to this thread I would note two things (RFC 3261 says): > > > > A UAS providing an offer in a 2xx (because the INVITE did not contain > > an offer) SHOULD construct the offer as if the UAS were making a > > brand new call, subject to the constraints of sending an offer that > > updates an existing session, as described in [13] in the case of SDP. > > Specifically, this means that it SHOULD include as many media formats > > and media types that the UA is willing to support. The UAS MUST > > ensure that the session description overlaps with its previous > > session description in media formats, transports, or other parameters > > that require support from the peer. This is to avoid the need for > > the peer to reject the session description. If, however, it is > > unacceptable to the UAC, the UAC SHOULD generate an answer with a > > valid session description, and then send a BYE to terminate the > > session. > > > > 1) The above could result in the UAC automatically generating a > BYE request on > > reception of the SDP offer and therefore the emergency call > failing. If we are > > going to allow this behaviour, then we should include a warning of the > > potential effects. > > > > 2) In this case the PSAP now has to generate the SDP offer. What are our > > recommendations on what that offer should contain. How do we know it was a > > voice terminal that generated the call, and how do we cater for > the potential > > that it was a real time text terminal that generated the call, or > at least the > > case where the user wished to use real time text. (So much easier > if the user > > actually indicates what they want). > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of Winterbottom, James > >> Sent: Wednesday, November 11, 2009 5:30 AM > >> To: James M. Polk; Cullen Jennings; ECRIT > >> Subject: Re: [Ecrit] Question about phone BCP > >> > >> Hi James, > >> > >> Thanks for the lecture. > >> My belief is that if you want stuff to just work the more > >> simple it is the better. I actually see phone BCP was a SIP > >> profile as a consequence I don't see why the UA can't insist > >> on putting an SDP element in there. Surely RFC3261 says that > >> a SIP proxy has to be able to deal with delayed offer, not > >> that a client MUST send it? > >> > >> Cheers > >> James > >> > >> > >>> -----Original Message----- > >>> From: James M. Polk [mailto:jmpolk@cisco.com] > >>> Sent: Wednesday, 11 November 2009 4:23 PM > >>> To: Winterbottom, James; Cullen Jennings; ECRIT > >>> Subject: Re: [Ecrit] Question about phone BCP > >>> > >>> At 06:23 PM 11/10/2009, Winterbottom, James wrote: > >>>> Hi Cullen, > >>>> > >>>> My thoughts on this stuff are that the more ways that you have of > >>>> doing it the less chance you have of stuff interoperating. I would > >>>> prefer to see the absolute minimum set that must be supported in > >>>> phone > >>> BCP. > >>> > >>> James > >>> > >>> "Delayed offer" is a mandatory to implement part of SIP, > >> per RFC 3261. > >>> Are you wanting to officially update RFC 3261 for this minimizing > >>> optimization? > >>> > >>> Further, there are a LOT of products out there that currently do > >>> Delayed offer, most of this is because customers/operators have > >>> demanded it be this way (as they believe they have greater control > >>> with Delayed offer that normal or early offer). > >>> > >>> IMO there needs to be a consensus from those operators that this is > >>> worth bypassing their requirement (for Delayed Offer) for. > >>> > >>> James > >>> > >>> > >>>> Cheers > >>>> James > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>> Behalf > >>> Of > >>>>> Cullen Jennings > >>>>> Sent: Wednesday, 11 November 2009 11:18 AM > >>>>> To: ECRIT > >>>>> Subject: [Ecrit] Question about phone BCP > >>>>> > >>>>> > >>>>> So SIP allows INVITEs with or without an SDP offer. As we all > >>>>> realize, this adds ways to use SIP but it allowed both the fast > >>>>> setup when the offer was in an INVITE and it allowed SIP to > >>>>> gateway to many other protocols where one needed to > >> have an INVITE with no offer. > >>>>> > >>>>> I have received complaints that Phone BCP currently > >> profiles SIP > >>>>> to a subset of it by eliminating the option of an > >> INVITE with no > >>>>> offer. I was wondering if there is a strong reason > >> that this was > >>>>> needed in Phone BCP. > >>>>> > >>>>> Cullen > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From bs7652@att.com Thu Nov 19 06:33:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294093A69F2 for ; Thu, 19 Nov 2009 06:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.739 X-Spam-Level: X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EycASK-AtJRj for ; Thu, 19 Nov 2009 06:33:31 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 38ABE3A68CC for ; Thu, 19 Nov 2009 06:33:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1258641202!37789751!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 15261 invoked from network); 19 Nov 2009 14:33:26 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Nov 2009 14:33:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nAJEXL34027009 for ; Thu, 19 Nov 2009 09:33:21 -0500 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id nAJEXDvL026940 for ; Thu, 19 Nov 2009 09:33:16 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:33:17 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:33:17 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6925.3B9AE1B0" x-cr-puzzleid: {3F556FF9-4DB2-48B8-AA39-185999FD9C94} x-cr-hashedpuzzle: ADn3 CjP9 CnZl C1Ta C49w DnxV D18A ErsC FclY FrBL F/Ui GR/I GUv1 Gc0G HbfK KkVs; 1; ZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {3F556FF9-4DB2-48B8-AA39-185999FD9C94}; YgBzADcANgA1ADIAQABhAHQAdAAuAGMAbwBtAA==; Thu, 19 Nov 2009 14:33:14 GMT; OQAxADEAIAB0AGUAeAB0AGkAbgBnAA== Content-Class: urn:content-classes:message Date: Thu, 19 Nov 2009 09:33:13 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA10F64C85@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 911 texting thread-index: AcppJTncsWzmF1zeQo6O1YmbwarngA== From: "Stark, Barbara" To: X-OriginalArrivalTime: 19 Nov 2009 14:33:17.0024 (UTC) FILETIME=[3BBA1E00:01CA6925] Subject: [Ecrit] 911 texting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:33:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6925.3B9AE1B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I thought ecrit might find this article interesting, about expectations around 911 texting. Barbara =20 http://www.courant.com/news/politics/hc-911texting1119.artnov19,0,235607 8.story =20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01CA6925.3B9AE1B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I thought ecrit might find this article = interesting, about expectations around 911 texting.

Barbara

 

http://www.courant.com/news/politics/hc-911texting1119.ar= tnov19,0,2356078.story

 

*****

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

 ------_=_NextPart_001_01CA6925.3B9AE1B0-- From john@johnlange.ca Fri Nov 20 12:34:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8CD3A690F for ; Fri, 20 Nov 2009 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi7w1el-yPcV for ; Fri, 20 Nov 2009 12:34:29 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id D59D43A6848 for ; Fri, 20 Nov 2009 12:34:28 -0800 (PST) Received: by qyk41 with SMTP id 41so2040536qyk.29 for ; Fri, 20 Nov 2009 12:34:23 -0800 (PST) Received: by 10.224.41.134 with SMTP id o6mr1062774qae.152.1258749263289; Fri, 20 Nov 2009 12:34:23 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 7sm2079466qwf.34.2009.11.20.12.34.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 12:34:22 -0800 (PST) From: John Lange To: ecrit Content-Type: text/plain; charset="UTF-8" Date: Fri, 20 Nov 2009 14:34:06 -0600 Message-Id: <1258749246.5943.62.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:34:30 -0000 Just thought the readers of this list would be interested in some developments here in Canada. Faced with the prospect of spending millions to implement a IP location system in support of the proposed Canadian i2 enhanced 911 for VOIP solution, a consortium of Canadian cable providers (Rogers, Shaw, Cogeco, and Videotron) commissioned a report to assess the true need for such a system. The result, in a nutshell is that nomadic VOIP is almost non-existent. The report contends that there there are 250,000 VOIP customers (0.00677% of the population) and of those, only 10,000 regularly move with their devices. This agrees with statistics gathered from New York which indicate only 0.0064% of calls to 911 come from nomadic VOIP customers. Given the above statistics, the current estimated cost of implementing Ci2 is between $20,000 - $30,000 per user. You can view the entire submission (the actual report was not released) as well as my comments on my blog: http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ Regards, -- John Lange http://www.johnlange.ca From br@brianrosen.net Fri Nov 20 12:52:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFD93A67BD for ; Fri, 20 Nov 2009 12:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlQihHnXmOoI for ; Fri, 20 Nov 2009 12:52:56 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 03A743A67AF for ; Fri, 20 Nov 2009 12:52:55 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NBaTC-0007D2-6k; Fri, 20 Nov 2009 14:52:42 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 20 Nov 2009 15:52:46 -0500 From: Brian Rosen To: John Lange , ecrit Message-ID: Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcpqI2mBjVGXqh6VlE2Qp559Epao7A== In-Reply-To: <1258749246.5943.62.camel@linux-k6vx.site> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:52:56 -0000 Not too surprising. Do consider that there are some reasons why you might think this will change. Extensive use of WiFi handsets for example. Still, it's probably more than a couple of years before the numbers would get big enough to matter. I'd also point out that for "next generation" emergency "call", things like instant messaging is almost entirely nomadic. Brian On 11/20/09 3:34 PM, "John Lange" wrote: > Just thought the readers of this list would be interested in some > developments here in Canada. > > Faced with the prospect of spending millions to implement a IP location > system in support of the proposed Canadian i2 enhanced 911 for VOIP > solution, a consortium of Canadian cable providers (Rogers, Shaw, > Cogeco, and Videotron) commissioned a report to assess the true need for > such a system. > > The result, in a nutshell is that nomadic VOIP is almost non-existent. > > The report contends that there there are 250,000 VOIP customers > (0.00677% of the population) and of those, only 10,000 regularly move > with their devices. > > This agrees with statistics gathered from New York which indicate only > 0.0064% of calls to 911 come from nomadic VOIP customers. > > Given the above statistics, the current estimated cost of implementing > Ci2 is between $20,000 - $30,000 per user. > > You can view the entire submission (the actual report was not released) > as well as my comments on my blog: > > http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ > > Regards, From hgs@cs.columbia.edu Fri Nov 20 13:06:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620EB28C173 for ; Fri, 20 Nov 2009 13:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cf-gx-tSx1W for ; Fri, 20 Nov 2009 13:06:21 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 86F0F3A67AF for ; Fri, 20 Nov 2009 13:06:21 -0800 (PST) Received: from [10.131.60.132] ([80.187.210.188]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nAKL6AWj027107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Nov 2009 16:06:17 -0500 (EST) References: <1258749246.5943.62.camel@linux-k6vx.site> In-Reply-To: <1258749246.5943.62.camel@linux-k6vx.site> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <9B2CF8C1-A461-4044-B0E0-A441AF3F3809@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Date: Fri, 20 Nov 2009 16:06:06 -0500 To: John Lange X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:06:22 -0000 I didn't know Canada had 3.6 billion inhabitants, let alone families. Do = moose get VoIP, too? Henning On Nov 20, 2009, at 3:34 PM, John Lange wrote: >=20 > The report contends that there there are 250,000 VOIP customers > (0.00677% of the population) and of those, only 10,000 regularly move > with their devices.=20 From mlinsner@cisco.com Fri Nov 20 13:36:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D48D3A680E for ; Fri, 20 Nov 2009 13:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqs0-XypszUB for ; Fri, 20 Nov 2009 13:36:06 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com (xmb-rtp-205.cisco.com [64.102.31.59]) by core3.amsl.com (Postfix) with ESMTP id 2755B3A67A3 for ; Fri, 20 Nov 2009 13:36:06 -0800 (PST) Received: from [10.116.195.125] ([10.116.195.125]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 16:36:03 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 20 Nov 2009 16:36:02 -0500 From: Marc Linsner To: ecrit Message-ID: Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcpqKXTYeMr22MRdwkexQPazC7LFCQ== In-Reply-To: <1258749246.5943.62.camel@linux-k6vx.site> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Nov 2009 21:36:03.0346 (UTC) FILETIME=[75A56F20:01CA6A29] Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:36:07 -0000 Apparently user supplied location will be the norm for 'wired' devices. -Marc- On 11/20/09 3:34 PM, "John Lange" wrote: > Just thought the readers of this list would be interested in some > developments here in Canada. > > Faced with the prospect of spending millions to implement a IP location > system in support of the proposed Canadian i2 enhanced 911 for VOIP > solution, a consortium of Canadian cable providers (Rogers, Shaw, > Cogeco, and Videotron) commissioned a report to assess the true need for > such a system. > > The result, in a nutshell is that nomadic VOIP is almost non-existent. > > The report contends that there there are 250,000 VOIP customers > (0.00677% of the population) and of those, only 10,000 regularly move > with their devices. > > This agrees with statistics gathered from New York which indicate only > 0.0064% of calls to 911 come from nomadic VOIP customers. > > Given the above statistics, the current estimated cost of implementing > Ci2 is between $20,000 - $30,000 per user. > > You can view the entire submission (the actual report was not released) > as well as my comments on my blog: > > http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ > > Regards, From rbarnes@bbn.com Fri Nov 20 14:11:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89603A6805 for ; Fri, 20 Nov 2009 14:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-pcl5UI6R1M for ; Fri, 20 Nov 2009 14:11:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 23FDB3A63D3 for ; Fri, 20 Nov 2009 14:11:19 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NBbhD-00015B-AV; Fri, 20 Nov 2009 17:11:15 -0500 Message-Id: <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> From: Richard Barnes To: John Lange In-Reply-To: <1258749246.5943.62.camel@linux-k6vx.site> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 17:11:14 -0500 References: <1258749246.5943.62.camel@linux-k6vx.site> X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:11:27 -0000 John, A few comments on a quick read of this submission: The most relevant finding of the study is that there are 250,000 "Nomadic VoIP" subscribers (a figure that itself seems dubious, given at the 800,000 Canadians using softphones are also nomadic and also using VoIP). Any one of those subscribers has the technical capability to move their VoIP endpoint to another place. If the CRTC is to adopt a solution that depends on those users staying in one place (such as user-supplied location), then they are increasing the risk, for all quarter-million of these users, that their calls will fail. There's simply no way to ensure that these users will not move their phones. This dramatically changes the cost analysis: The denominator in the "cost per user" fraction should be "number of users who benefit from Ci2". This standard would clearly include all 250,000 nomadic users, who benefit from the increased robustness (decreased risk) of their emergency calls. If you include them, the cost per user drops to $800-1200. If you also include the 800,000 softphone users (since there's no real technical difference between a nomadic user's ATA and a softphone on an iPod), the cost drops to less than $200 per user. So in this dimension, at least, the submission is off by at least two orders of magnitude. Finally the figure that "0.0064% of calls to 911 come from nomadic VOIP customers" is completely irrelevant to this debate, since most nomadic VoIP users (e.g., Skype users) have no way to get their 9-1-1 calls to a PSAP in the first place! --Richard On Nov 20, 2009, at 3:34 PM, John Lange wrote: > Just thought the readers of this list would be interested in some > developments here in Canada. > > Faced with the prospect of spending millions to implement a IP > location > system in support of the proposed Canadian i2 enhanced 911 for VOIP > solution, a consortium of Canadian cable providers (Rogers, Shaw, > Cogeco, and Videotron) commissioned a report to assess the true need > for > such a system. > > The result, in a nutshell is that nomadic VOIP is almost non-existent. > > The report contends that there there are 250,000 VOIP customers > (0.00677% of the population) and of those, only 10,000 regularly move > with their devices. > > This agrees with statistics gathered from New York which indicate only > 0.0064% of calls to 911 come from nomadic VOIP customers. > > Given the above statistics, the current estimated cost of implementing > Ci2 is between $20,000 - $30,000 per user. > > You can view the entire submission (the actual report was not > released) > as well as my comments on my blog: > > http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ > > Regards, > > -- > John Lange > http://www.johnlange.ca > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john@johnlange.ca Fri Nov 20 14:49:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DDB3A6884 for ; Fri, 20 Nov 2009 14:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XkQVqUVpris for ; Fri, 20 Nov 2009 14:49:41 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id E9DDC3A6805 for ; Fri, 20 Nov 2009 14:49:40 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so901707qwb.31 for ; Fri, 20 Nov 2009 14:49:33 -0800 (PST) Received: by 10.224.92.85 with SMTP id q21mr1130020qam.75.1258757373685; Fri, 20 Nov 2009 14:49:33 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 7sm5332707qwf.4.2009.11.20.14.49.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 14:49:33 -0800 (PST) From: John Lange To: Richard Barnes In-Reply-To: <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 20 Nov 2009 16:49:27 -0600 Message-Id: <1258757367.3212.43.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:49:41 -0000 >From my perspective the critical point of the submission is that VOIP is declining, not growing. Even accepting your point that potentially 250,000 users _could_ benefit, the investment would return less and less value as the number of subscribers declines. And given that Ci2 does not support services such as Skype, it fails to service what is by far the largest, and still growing segment of the nomadic VOIP landscape. To be clear, I support the goal of IP location determination for the purpose of providing enhanced 911 services to nomadic VOIP users. I just don't support the proposed Ci2 because, to a large extent, it does not meet that goal. Until the IETF gets all of the relevant standards in place and vendors start making products compatible with those standards, it's likely still too expensive and too early for implementation. -- John Lange http://www.johnlange.ca From fmenard@xittelecom.com Fri Nov 20 19:35:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609E63A6867 for ; Fri, 20 Nov 2009 19:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTkmgaB+xOoK for ; Fri, 20 Nov 2009 19:34:59 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 20B7D3A67D6 for ; Fri, 20 Nov 2009 19:34:58 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NBgkQ-0001Hy-2E; Fri, 20 Nov 2009 22:34:54 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NBgkP-0002iC-F6; Fri, 20 Nov 2009 22:34:53 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: "Francois D. Menard" In-Reply-To: <9B2CF8C1-A461-4044-B0E0-A441AF3F3809@cs.columbia.edu> Date: Fri, 20 Nov 2009 22:34:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1258749246.5943.62.camel@linux-k6vx.site> <9B2CF8C1-A461-4044-B0E0-A441AF3F3809@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 03:35:00 -0000 The report says: This translates into approximately 250,000 households =96 or slightly = less than 2% of all households when taking into account the fact approx = 76% of households subscribe to a high speed Internet service =96 that = are currently access-independent VoIP service subscribers. F. On 2009-11-20, at 4:06 PM, Henning Schulzrinne wrote: > I didn't know Canada had 3.6 billion inhabitants, let alone families. = Do moose get VoIP, too? >=20 > Henning >=20 > On Nov 20, 2009, at 3:34 PM, John Lange wrote: >=20 >>=20 >> The report contends that there there are 250,000 VOIP customers >> (0.00677% of the population) and of those, only 10,000 regularly move >> with their devices.=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Fri Nov 20 21:53:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A763A6817 for ; Fri, 20 Nov 2009 21:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWwpNJI8Brtl for ; Fri, 20 Nov 2009 21:53:13 -0800 (PST) Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by core3.amsl.com (Postfix) with ESMTP id D77B23A67A5 for ; Fri, 20 Nov 2009 21:53:12 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 21:53:09 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'John Lange'" , "'ecrit'" References: <1258749246.5943.62.camel@linux-k6vx.site> In-Reply-To: <1258749246.5943.62.camel@linux-k6vx.site> Date: Fri, 20 Nov 2009 21:53:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqINsMvvbFPi6MQYChHxdyr0JQOQASyjQQ Content-Language: en-us X-OriginalArrivalTime: 21 Nov 2009 05:53:09.0852 (UTC) FILETIME=[E7A111C0:01CA6A6E] Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 05:53:14 -0000 It is not all that surprising to me that a survey done of cable customers utilizing the wired fixed VOIP services offered by those providers would conclude that those VOIP users are not very mobile. Today broadband wireless is still in its infancy, smartphones still represent less than 15 percent of all cellular handsets and providers of fixed broadband services are only just beginning to bundle in access to wireless services such as WLAN hotspots. As a result, the vast majority of today's mobile telephony users find themselves attached to cellular networks. However, in 5 years, the situation might look quite different and therefore a survey of today's usage patterns does not enable us to conclude that the future will always look like the present, or even that the transition between today's usage patterns and tomorrow's will be gradual enough to enable us to plan the transition at our leisure. The nature of technological change is that things move at blinding speed once the "tipping point" is reached. Today, SMS is ubiquitous and therefore the demand for (and mis-informed use of) texting to 911 has become a problem for which we have no easily deployable solutions. This would have seemed quite unlikely 5 years ago. Thus while mobile VOIP technologies such as Voice over WLAN appear to be an overhyped bust with only a fraction of the market share of DECT (to pick just a single competitor), other technologies such as White Space could easily change the equation over the next decade. In the words of Monty Python, "nomadic VOIP's not dead -- he's only sleeping!" -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John Lange Sent: Friday, November 20, 2009 12:34 PM To: ecrit Subject: [Ecrit] Nomadic VOIP is dead Just thought the readers of this list would be interested in some developments here in Canada. Faced with the prospect of spending millions to implement a IP location system in support of the proposed Canadian i2 enhanced 911 for VOIP solution, a consortium of Canadian cable providers (Rogers, Shaw, Cogeco, and Videotron) commissioned a report to assess the true need for such a system. The result, in a nutshell is that nomadic VOIP is almost non-existent. The report contends that there there are 250,000 VOIP customers (0.00677% of the population) and of those, only 10,000 regularly move with their devices. This agrees with statistics gathered from New York which indicate only 0.0064% of calls to 911 come from nomadic VOIP customers. Given the above statistics, the current estimated cost of implementing Ci2 is between $20,000 - $30,000 per user. You can view the entire submission (the actual report was not released) as well as my comments on my blog: http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ Regards, -- John Lange http://www.johnlange.ca _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Fri Nov 20 22:12:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5561A3A6933 for ; Fri, 20 Nov 2009 22:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDlk8zCYOFhS for ; Fri, 20 Nov 2009 22:12:39 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 420443A694F for ; Fri, 20 Nov 2009 22:12:33 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:37144 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5323071AbZKUGMX convert rfc822-to-8bit (ORCPT ); Sat, 21 Nov 2009 00:12:23 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 21 Nov 2009 00:12:22 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 21 Nov 2009 14:12:18 +0800 From: "Dawson, Martin" To: Bernard Aboba , 'John Lange' , 'ecrit' Date: Sat, 21 Nov 2009 14:07:55 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcpqINsMvvbFPi6MQYChHxdyr0JQOQASyjQQAAE9A+M= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1F7EC3@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 06:12:40 -0000 Yes. If anyone can be bothered doing the research, they'll find similar reports from the late 80's and early 90's concluding that mobile telephony will never be a mass market technology. Too expensive, low market penetration based on current stats blah blah. It's a failure to recognize what Peter Drucker calls "the future that's already happened". It's a common syndrome. These are not the sort of people I want between me and the nearest PSAP. Roll on ECRIT direct! Cheers, Martin ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Bernard Aboba [bernard_aboba@hotmail.com] Sent: 20 November 2009 23:53 To: 'John Lange'; 'ecrit' Subject: Re: [Ecrit] Nomadic VOIP is dead It is not all that surprising to me that a survey done of cable customers utilizing the wired fixed VOIP services offered by those providers would conclude that those VOIP users are not very mobile. Today broadband wireless is still in its infancy, smartphones still represent less than 15 percent of all cellular handsets and providers of fixed broadband services are only just beginning to bundle in access to wireless services such as WLAN hotspots. As a result, the vast majority of today's mobile telephony users find themselves attached to cellular networks. However, in 5 years, the situation might look quite different and therefore a survey of today's usage patterns does not enable us to conclude that the future will always look like the present, or even that the transition between today's usage patterns and tomorrow's will be gradual enough to enable us to plan the transition at our leisure. The nature of technological change is that things move at blinding speed once the "tipping point" is reached. Today, SMS is ubiquitous and therefore the demand for (and mis-informed use of) texting to 911 has become a problem for which we have no easily deployable solutions. This would have seemed quite unlikely 5 years ago. Thus while mobile VOIP technologies such as Voice over WLAN appear to be an overhyped bust with only a fraction of the market share of DECT (to pick just a single competitor), other technologies such as White Space could easily change the equation over the next decade. In the words of Monty Python, "nomadic VOIP's not dead -- he's only sleeping!" -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John Lange Sent: Friday, November 20, 2009 12:34 PM To: ecrit Subject: [Ecrit] Nomadic VOIP is dead Just thought the readers of this list would be interested in some developments here in Canada. Faced with the prospect of spending millions to implement a IP location system in support of the proposed Canadian i2 enhanced 911 for VOIP solution, a consortium of Canadian cable providers (Rogers, Shaw, Cogeco, and Videotron) commissioned a report to assess the true need for such a system. The result, in a nutshell is that nomadic VOIP is almost non-existent. The report contends that there there are 250,000 VOIP customers (0.00677% of the population) and of those, only 10,000 regularly move with their devices. This agrees with statistics gathered from New York which indicate only 0.0064% of calls to 911 come from nomadic VOIP customers. Given the above statistics, the current estimated cost of implementing Ci2 is between $20,000 - $30,000 per user. You can view the entire submission (the actual report was not released) as well as my comments on my blog: http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/ Regards, -- John Lange http://www.johnlange.ca _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Sat Nov 21 14:17:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9733A68B1 for ; Sat, 21 Nov 2009 14:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPqrnglijIVq for ; Sat, 21 Nov 2009 14:17:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 264153A67EB for ; Sat, 21 Nov 2009 14:17:24 -0800 (PST) Received: from [128.89.252.162] (helo=[192.168.1.42]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NByGd-0003so-9m; Sat, 21 Nov 2009 17:17:19 -0500 Message-Id: From: Richard Barnes To: John Lange In-Reply-To: <1258757367.3212.43.camel@linux-k6vx.site> Content-Type: multipart/alternative; boundary=Apple-Mail-1--785738935 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 21 Nov 2009 17:16:58 -0500 References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site> X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:17:25 -0000 --Apple-Mail-1--785738935 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >> From my perspective the critical point of the submission is that >> VOIP is > declining, not growing. I hope you mean that "*Nomadic* VoIP is declining", and even then "Nomadic" understood in some peculiar sense that excludes soft- phones. (I'm not familiar with CRTC's specific definition, but whatever it is, it seems awkward from a technical perspective.) > And given that Ci2 does not support services such as Skype, it fails > to > service what is by far the largest, and still growing segment of the > nomadic VOIP landscape. That seems to me to argue for fixing the current incarnation of Ci2 rather than doing nothing. On the other hand, as I understand it, the major barrier to support for VSPs like Skype is the establishment of trust relationships with them. In which case, it should be straightforward to extend Ci2 to support a limited number of these VSPs. As the report notes, simply bringing Skype into the fold would cover more than 90% of users, or around 720,000 subscribers. > To be clear, I support the goal of IP location determination for the > purpose of providing enhanced 911 services to nomadic VOIP users. I > just > don't support the proposed Ci2 because, to a large extent, it does not > meet that goal. I certainly agree that there are better ways of doing it than current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful than the report seems to imply. --Richard --Apple-Mail-1--785738935 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
=46rom my perspective the = critical point of the submission is that VOIP = is
declining, not growing.

I = hope you mean that "*Nomadic* VoIP is declining", and even then = "Nomadic" understood in some peculiar sense that excludes soft-phones. =  (I'm not familiar with CRTC's specific definition, but whatever it = is, it seems awkward from a technical perspective.) =  

And given that Ci2 = does not support services such as Skype, it fails to
service what is = by far the largest, and still growing segment of the
nomadic VOIP = landscape.

That seems to me to = argue for fixing the current incarnation of Ci2 rather than doing = nothing.  

On the other hand, as I = understand it, the major barrier to support for VSPs like Skype is the = establishment of trust relationships with them.  In which case, it = should be straightforward to extend Ci2 to support a limited number of = these VSPs.  As the report notes, simply bringing Skype into the = fold would cover more than 90% of users, or around 720,000 subscribers. =  


To be = clear, I support the goal of IP location determination for = the
purpose of providing enhanced 911 services to nomadic VOIP users. = I just
don't support the proposed Ci2 because, to a large extent, it = does not
meet that goal.

I = certainly agree that there are better ways of doing it than current Ci2 = -- mainly, just deploying the GEOPRIV Location Configuration Protocols = (LCPs) -- but at the same time, Ci2 is more broadly useful than the = report seems to imply.

--Richard= --Apple-Mail-1--785738935-- From James.Winterbottom@andrew.com Sat Nov 21 14:38:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEE13A6874 for ; Sat, 21 Nov 2009 14:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls51tQDQc46m for ; Sat, 21 Nov 2009 14:38:02 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 181233A69DC for ; Sat, 21 Nov 2009 14:38:02 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:42968 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S71514AbZKUWh6 convert rfc822-to-8bit (ORCPT ); Sat, 21 Nov 2009 16:37:58 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 21 Nov 2009 16:37:58 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 22 Nov 2009 06:37:54 +0800 From: "Winterbottom, James" To: Richard Barnes , John Lange Date: Sun, 22 Nov 2009 06:37:53 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acpq+GoeUI3F41J9Q5aUJhkkog5NOgAAHtof Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:38:03 -0000 I have stayed largely out of this discussion to this point. Ci2 had very specific criteria that simply following base ECRIT could not meet, namely the location dependability criteria. I, and a number of others, have been saying in the IETF since before ECRIT came about that a lack of location dependability was a series impediment to uptake. I have subsequently visited and talked to quite a number of regulators around the world and as things currently stand they will not allow an architecture that does not have a solution to the location dependability problem. Ci2 addresses this problem by using HELD identity extensions and a trusted third-party query, though the solution also addresses quite a number of other barriers to deployment of a base-NENA i2 solution. Automatic location from the network is required to support all of the architectures that I have seen, and it is this component of the Ci2 solution that is deemed to be the most expensive to implement. So unless people are professing a solution of "only user provided location" then it seems that going Ci2 or some other architecture saves little to nothing. My understanding is that there is a strict requirement from the CRTC that says that the Ci2 solution must not require user-provided location, so it seems to me that location-enabling the network is not optional, it is mandatory. As far as I understand it, most of the people complaining about Ci2 are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This removes the VSPs from the equation when it comes to making an emergency call, so this should alleviate most of your concerns John. Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Richard Barnes [rbarnes@bbn.com] Sent: Saturday, November 21, 2009 4:16 PM To: John Lange Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead >From my perspective the critical point of the submission is that VOIP is declining, not growing. I hope you mean that "*Nomadic* VoIP is declining", and even then "Nomadic" understood in some peculiar sense that excludes soft-phones. (I'm not familiar with CRTC's specific definition, but whatever it is, it seems awkward from a technical perspective.) And given that Ci2 does not support services such as Skype, it fails to service what is by far the largest, and still growing segment of the nomadic VOIP landscape. That seems to me to argue for fixing the current incarnation of Ci2 rather than doing nothing. On the other hand, as I understand it, the major barrier to support for VSPs like Skype is the establishment of trust relationships with them. In which case, it should be straightforward to extend Ci2 to support a limited number of these VSPs. As the report notes, simply bringing Skype into the fold would cover more than 90% of users, or around 720,000 subscribers. To be clear, I support the goal of IP location determination for the purpose of providing enhanced 911 services to nomadic VOIP users. I just don't support the proposed Ci2 because, to a large extent, it does not meet that goal. I certainly agree that there are better ways of doing it than current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful than the report seems to imply. --Richard From fmenard@xittelecom.com Sat Nov 21 20:44:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C073A686B for ; Sat, 21 Nov 2009 20:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYxC-DKltN0G for ; Sat, 21 Nov 2009 20:44:25 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id D81C63A6853 for ; Sat, 21 Nov 2009 20:44:24 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NC4J6-0005nu-TT; Sat, 21 Nov 2009 23:44:17 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NC4J6-0007Tz-9w; Sat, 21 Nov 2009 23:44:16 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com> Date: Sat, 21 Nov 2009 23:44:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:44:26 -0000 Actually, ISPs also fear this quite a lot, as there is no standard for = LIS to LIS communications at this time. Reduced Ci2 was proposed. The document should be posted to the CRTC web = site on monday and I will circulate. At this time, many of you got it via private correspondance. We think that wholesale DSL and wholesale cable should enable ISPs to = implement their own LISes without being forced to interface with the = ILEC LIS in the live emergency call path. Location aware devices should become available prior to Ci2 being = available. The problem is Ci2 DENIES use of location aware devices. ILECs need to be told to enable SIP LOCATION CONVEYANCE on their = servers.... and forego all of this nonsense to use the public IP address = as the key to look for a LIS in an ARIN IP address block... its not = going to work. F. On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: > I have stayed largely out of this discussion to this point. > Ci2 had very specific criteria that simply following base ECRIT could = not meet, namely the location dependability criteria. I, and a number of = others, have been saying in the IETF since before ECRIT came about that = a lack of location dependability was a series impediment to uptake. I = have subsequently visited and talked to quite a number of regulators = around the world and as things currently stand they will not allow an = architecture that does not have a solution to the location dependability = problem. Ci2 addresses this problem by using HELD identity extensions = and a trusted third-party query, though the solution also addresses = quite a number of other barriers to deployment of a base-NENA i2 = solution. >=20 > Automatic location from the network is required to support all of the = architectures that I have seen, and it is this component of the Ci2 = solution that is deemed to be the most expensive to implement. So unless = people are professing a solution of "only user provided location" then = it seems that going Ci2 or some other architecture saves little to = nothing. My understanding is that there is a strict requirement from the = CRTC that says that the Ci2 solution must not require user-provided = location, so it seems to me that location-enabling the network is not = optional, it is mandatory. >=20 > As far as I understand it, most of the people complaining about Ci2 = are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. = This removes the VSPs from the equation when it comes to making an = emergency call, so this should alleviate most of your concerns John. >=20 > Cheers > James >=20 >=20 >=20 >=20 > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of = Richard Barnes [rbarnes@bbn.com] > Sent: Saturday, November 21, 2009 4:16 PM > To: John Lange > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead >=20 > =46rom my perspective the critical point of the submission is that = VOIP is > declining, not growing. >=20 > I hope you mean that "*Nomadic* VoIP is declining", and even then = "Nomadic" understood in some peculiar sense that excludes soft-phones. = (I'm not familiar with CRTC's specific definition, but whatever it is, = it seems awkward from a technical perspective.) >=20 > And given that Ci2 does not support services such as Skype, it fails = to > service what is by far the largest, and still growing segment of the > nomadic VOIP landscape. >=20 > That seems to me to argue for fixing the current incarnation of Ci2 = rather than doing nothing. >=20 > On the other hand, as I understand it, the major barrier to support = for VSPs like Skype is the establishment of trust relationships with = them. In which case, it should be straightforward to extend Ci2 to = support a limited number of these VSPs. As the report notes, simply = bringing Skype into the fold would cover more than 90% of users, or = around 720,000 subscribers. >=20 >=20 > To be clear, I support the goal of IP location determination for the > purpose of providing enhanced 911 services to nomadic VOIP users. I = just > don't support the proposed Ci2 because, to a large extent, it does not > meet that goal. >=20 > I certainly agree that there are better ways of doing it than current = Ci2 -- mainly, just deploying the GEOPRIV Location Configuration = Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful = than the report seems to imply. >=20 > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Sat Nov 21 20:52:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278643A6809 for ; Sat, 21 Nov 2009 20:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weapdgur4U-p for ; Sat, 21 Nov 2009 20:52:36 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id BBD8F3A65A5 for ; Sat, 21 Nov 2009 20:52:36 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:31689 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5335162AbZKVEwd convert rfc822-to-8bit (ORCPT ); Sat, 21 Nov 2009 22:52:33 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 21 Nov 2009 22:52:10 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 22 Nov 2009 12:52:29 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Sun, 22 Nov 2009 12:52:28 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcprLnb0FfD51U7mSbiizF1kGcegXAAAFGZp Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> In-Reply-To: <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:52:38 -0000 Again Francois, you fail to address the key requirement that there is NO LOCATION DEPENDABILIY offerred by location provided by end-points, this includes location that traverses end-points. There is far more of a standard for LIS to LIS communication, including the NENA TRD (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there is any form location dependability. So, having a location enabled or capable end-point without a standard for location dependability is unlikely to meet any degree of acceptability. Again ECRIT Direct goes a long way towards addressing these requirements. Cheers James ________________________________________ From: Francois D. Menard [fmenard@xittelecom.com] Sent: Saturday, November 21, 2009 10:44 PM To: Winterbottom, James Cc: Richard Barnes; John Lange; ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead Actually, ISPs also fear this quite a lot, as there is no standard for LIS to LIS communications at this time. Reduced Ci2 was proposed. The document should be posted to the CRTC web site on monday and I will circulate. At this time, many of you got it via private correspondance. We think that wholesale DSL and wholesale cable should enable ISPs to implement their own LISes without being forced to interface with the ILEC LIS in the live emergency call path. Location aware devices should become available prior to Ci2 being available. The problem is Ci2 DENIES use of location aware devices. ILECs need to be told to enable SIP LOCATION CONVEYANCE on their servers.... and forego all of this nonsense to use the public IP address as the key to look for a LIS in an ARIN IP address block... its not going to work. F. On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: > I have stayed largely out of this discussion to this point. > Ci2 had very specific criteria that simply following base ECRIT could not meet, namely the location dependability criteria. I, and a number of others, have been saying in the IETF since before ECRIT came about that a lack of location dependability was a series impediment to uptake. I have subsequently visited and talked to quite a number of regulators around the world and as things currently stand they will not allow an architecture that does not have a solution to the location dependability problem. Ci2 addresses this problem by using HELD identity extensions and a trusted third-party query, though the solution also addresses quite a number of other barriers to deployment of a base-NENA i2 solution. > > Automatic location from the network is required to support all of the architectures that I have seen, and it is this component of the Ci2 solution that is deemed to be the most expensive to implement. So unless people are professing a solution of "only user provided location" then it seems that going Ci2 or some other architecture saves little to nothing. My understanding is that there is a strict requirement from the CRTC that says that the Ci2 solution must not require user-provided location, so it seems to me that location-enabling the network is not optional, it is mandatory. > > As far as I understand it, most of the people complaining about Ci2 are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This removes the VSPs from the equation when it comes to making an emergency call, so this should alleviate most of your concerns John. > > Cheers > James > > > > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Richard Barnes [rbarnes@bbn.com] > Sent: Saturday, November 21, 2009 4:16 PM > To: John Lange > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > From my perspective the critical point of the submission is that VOIP is > declining, not growing. > > I hope you mean that "*Nomadic* VoIP is declining", and even then "Nomadic" understood in some peculiar sense that excludes soft-phones. (I'm not familiar with CRTC's specific definition, but whatever it is, it seems awkward from a technical perspective.) > > And given that Ci2 does not support services such as Skype, it fails to > service what is by far the largest, and still growing segment of the > nomadic VOIP landscape. > > That seems to me to argue for fixing the current incarnation of Ci2 rather than doing nothing. > > On the other hand, as I understand it, the major barrier to support for VSPs like Skype is the establishment of trust relationships with them. In which case, it should be straightforward to extend Ci2 to support a limited number of these VSPs. As the report notes, simply bringing Skype into the fold would cover more than 90% of users, or around 720,000 subscribers. > > > To be clear, I support the goal of IP location determination for the > purpose of providing enhanced 911 services to nomadic VOIP users. I just > don't support the proposed Ci2 because, to a large extent, it does not > meet that goal. > > I certainly agree that there are better ways of doing it than current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful than the report seems to imply. > > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fmenard@xittelecom.com Sat Nov 21 21:55:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D663A685E for ; Sat, 21 Nov 2009 21:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caL7l7reBsPf for ; Sat, 21 Nov 2009 21:55:42 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 4E9C53A684A for ; Sat, 21 Nov 2009 21:55:42 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NC5Q9-0007zU-DJ; Sun, 22 Nov 2009 00:55:37 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NC5Q6-0003f3-I6; Sun, 22 Nov 2009 00:55:37 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com> Date: Sun, 22 Nov 2009 00:55:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:55:43 -0000 Error. Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY For cable: We speak of Reverse DNS in realtime fashion for cable - a = Cable MODEM MAC address is a CIVIC address. For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 = identifiers which ISPs will know that they can bind to CIVIC addresses. There is no end-user inputted location in our proposed Reduced Ci2 = architecture. F. On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: > Again Francois, you fail to address the key requirement that there is = NO LOCATION DEPENDABILIY offerred by location provided by end-points, = this includes location that traverses end-points. There is far more of a = standard for LIS to LIS communication, including the NENA TRD = (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there = is any form location dependability. >=20 > So, having a location enabled or capable end-point without a standard = for location dependability is unlikely to meet any degree of = acceptability. Again ECRIT Direct goes a long way towards addressing = these requirements. >=20 > Cheers > James >=20 > ________________________________________ > From: Francois D. Menard [fmenard@xittelecom.com] > Sent: Saturday, November 21, 2009 10:44 PM > To: Winterbottom, James > Cc: Richard Barnes; John Lange; ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead >=20 > Actually, ISPs also fear this quite a lot, as there is no standard for = LIS to LIS communications at this time. >=20 > Reduced Ci2 was proposed. The document should be posted to the CRTC = web site on monday and I will circulate. >=20 > At this time, many of you got it via private correspondance. >=20 > We think that wholesale DSL and wholesale cable should enable ISPs to = implement their own LISes without being forced to interface with the = ILEC LIS in the live emergency call path. >=20 > Location aware devices should become available prior to Ci2 being = available. >=20 > The problem is Ci2 DENIES use of location aware devices. >=20 > ILECs need to be told to enable SIP LOCATION CONVEYANCE on their = servers.... and forego all of this nonsense to use the public IP address = as the key to look for a LIS in an ARIN IP address block... its not = going to work. >=20 > F. >=20 >=20 > On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: >=20 >> I have stayed largely out of this discussion to this point. >> Ci2 had very specific criteria that simply following base ECRIT could = not meet, namely the location dependability criteria. I, and a number of = others, have been saying in the IETF since before ECRIT came about that = a lack of location dependability was a series impediment to uptake. I = have subsequently visited and talked to quite a number of regulators = around the world and as things currently stand they will not allow an = architecture that does not have a solution to the location dependability = problem. Ci2 addresses this problem by using HELD identity extensions = and a trusted third-party query, though the solution also addresses = quite a number of other barriers to deployment of a base-NENA i2 = solution. >>=20 >> Automatic location from the network is required to support all of the = architectures that I have seen, and it is this component of the Ci2 = solution that is deemed to be the most expensive to implement. So unless = people are professing a solution of "only user provided location" then = it seems that going Ci2 or some other architecture saves little to = nothing. My understanding is that there is a strict requirement from the = CRTC that says that the Ci2 solution must not require user-provided = location, so it seems to me that location-enabling the network is not = optional, it is mandatory. >>=20 >> As far as I understand it, most of the people complaining about Ci2 = are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. = This removes the VSPs from the equation when it comes to making an = emergency call, so this should alleviate most of your concerns John. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >>=20 >> ________________________________________ >> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of = Richard Barnes [rbarnes@bbn.com] >> Sent: Saturday, November 21, 2009 4:16 PM >> To: John Lange >> Cc: ecrit >> Subject: Re: [Ecrit] Nomadic VOIP is dead >>=20 >> =46rom my perspective the critical point of the submission is that = VOIP is >> declining, not growing. >>=20 >> I hope you mean that "*Nomadic* VoIP is declining", and even then = "Nomadic" understood in some peculiar sense that excludes soft-phones. = (I'm not familiar with CRTC's specific definition, but whatever it is, = it seems awkward from a technical perspective.) >>=20 >> And given that Ci2 does not support services such as Skype, it fails = to >> service what is by far the largest, and still growing segment of the >> nomadic VOIP landscape. >>=20 >> That seems to me to argue for fixing the current incarnation of Ci2 = rather than doing nothing. >>=20 >> On the other hand, as I understand it, the major barrier to support = for VSPs like Skype is the establishment of trust relationships with = them. In which case, it should be straightforward to extend Ci2 to = support a limited number of these VSPs. As the report notes, simply = bringing Skype into the fold would cover more than 90% of users, or = around 720,000 subscribers. >>=20 >>=20 >> To be clear, I support the goal of IP location determination for the >> purpose of providing enhanced 911 services to nomadic VOIP users. I = just >> don't support the proposed Ci2 because, to a large extent, it does = not >> meet that goal. >>=20 >> I certainly agree that there are better ways of doing it than current = Ci2 -- mainly, just deploying the GEOPRIV Location Configuration = Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful = than the report seems to imply. >>=20 >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From James.Winterbottom@andrew.com Sat Nov 21 23:16:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3233A694F for ; Sat, 21 Nov 2009 23:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teqMrhndfHlq for ; Sat, 21 Nov 2009 23:16:12 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 68CC43A6949 for ; Sat, 21 Nov 2009 23:16:11 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:16449 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S64874AbZKVHQG convert rfc822-to-8bit (ORCPT ); Sun, 22 Nov 2009 01:16:06 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 22 Nov 2009 01:16:05 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 22 Nov 2009 15:16:03 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Sun, 22 Nov 2009 15:14:05 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcprOG0oYvBNFuDKSz6CChaA+edJrgACwEMd Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 07:16:13 -0000 May be I am missing something, but your previous email was suggesting that Ci2 precluded location aware devices, and I think all I did was to to state why. Are you aware of a location dependability standard that for device provided location? Cheers James ________________________________________ From: Francois D. Menard [fmenard@xittelecom.com] Sent: Saturday, November 21, 2009 11:55 PM To: Winterbottom, James Cc: Richard Barnes; John Lange; ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead Error. Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY For cable: We speak of Reverse DNS in realtime fashion for cable - a Cable MODEM MAC address is a CIVIC address. For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 identifiers which ISPs will know that they can bind to CIVIC addresses. There is no end-user inputted location in our proposed Reduced Ci2 architecture. F. On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: > Again Francois, you fail to address the key requirement that there is NO LOCATION DEPENDABILIY offerred by location provided by end-points, this includes location that traverses end-points. There is far more of a standard for LIS to LIS communication, including the NENA TRD (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there is any form location dependability. > > So, having a location enabled or capable end-point without a standard for location dependability is unlikely to meet any degree of acceptability. Again ECRIT Direct goes a long way towards addressing these requirements. > > Cheers > James > > ________________________________________ > From: Francois D. Menard [fmenard@xittelecom.com] > Sent: Saturday, November 21, 2009 10:44 PM > To: Winterbottom, James > Cc: Richard Barnes; John Lange; ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > Actually, ISPs also fear this quite a lot, as there is no standard for LIS to LIS communications at this time. > > Reduced Ci2 was proposed. The document should be posted to the CRTC web site on monday and I will circulate. > > At this time, many of you got it via private correspondance. > > We think that wholesale DSL and wholesale cable should enable ISPs to implement their own LISes without being forced to interface with the ILEC LIS in the live emergency call path. > > Location aware devices should become available prior to Ci2 being available. > > The problem is Ci2 DENIES use of location aware devices. > > ILECs need to be told to enable SIP LOCATION CONVEYANCE on their servers.... and forego all of this nonsense to use the public IP address as the key to look for a LIS in an ARIN IP address block... its not going to work. > > F. > > > On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: > >> I have stayed largely out of this discussion to this point. >> Ci2 had very specific criteria that simply following base ECRIT could not meet, namely the location dependability criteria. I, and a number of others, have been saying in the IETF since before ECRIT came about that a lack of location dependability was a series impediment to uptake. I have subsequently visited and talked to quite a number of regulators around the world and as things currently stand they will not allow an architecture that does not have a solution to the location dependability problem. Ci2 addresses this problem by using HELD identity extensions and a trusted third-party query, though the solution also addresses quite a number of other barriers to deployment of a base-NENA i2 solution. >> >> Automatic location from the network is required to support all of the architectures that I have seen, and it is this component of the Ci2 solution that is deemed to be the most expensive to implement. So unless people are professing a solution of "only user provided location" then it seems that going Ci2 or some other architecture saves little to nothing. My understanding is that there is a strict requirement from the CRTC that says that the Ci2 solution must not require user-provided location, so it seems to me that location-enabling the network is not optional, it is mandatory. >> >> As far as I understand it, most of the people complaining about Ci2 are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This removes the VSPs from the equation when it comes to making an emergency call, so this should alleviate most of your concerns John. >> >> Cheers >> James >> >> >> >> >> ________________________________________ >> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Richard Barnes [rbarnes@bbn.com] >> Sent: Saturday, November 21, 2009 4:16 PM >> To: John Lange >> Cc: ecrit >> Subject: Re: [Ecrit] Nomadic VOIP is dead >> >> From my perspective the critical point of the submission is that VOIP is >> declining, not growing. >> >> I hope you mean that "*Nomadic* VoIP is declining", and even then "Nomadic" understood in some peculiar sense that excludes soft-phones. (I'm not familiar with CRTC's specific definition, but whatever it is, it seems awkward from a technical perspective.) >> >> And given that Ci2 does not support services such as Skype, it fails to >> service what is by far the largest, and still growing segment of the >> nomadic VOIP landscape. >> >> That seems to me to argue for fixing the current incarnation of Ci2 rather than doing nothing. >> >> On the other hand, as I understand it, the major barrier to support for VSPs like Skype is the establishment of trust relationships with them. In which case, it should be straightforward to extend Ci2 to support a limited number of these VSPs. As the report notes, simply bringing Skype into the fold would cover more than 90% of users, or around 720,000 subscribers. >> >> >> To be clear, I support the goal of IP location determination for the >> purpose of providing enhanced 911 services to nomadic VOIP users. I just >> don't support the proposed Ci2 because, to a large extent, it does not >> meet that goal. >> >> I certainly agree that there are better ways of doing it than current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful than the report seems to imply. >> >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From fmenard@xittelecom.com Sun Nov 22 04:59:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FC93A689B for ; Sun, 22 Nov 2009 04:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1IPTvYEqlzL for ; Sun, 22 Nov 2009 04:59:41 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id CC24E3A6A7F for ; Sun, 22 Nov 2009 04:59:40 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCC2S-0004KE-0k; Sun, 22 Nov 2009 07:59:36 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCC2P-00066B-9l; Sun, 22 Nov 2009 07:59:34 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> Date: Sun, 22 Nov 2009 07:59:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 12:59:42 -0000 The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION 99/123 = from an ISP owned LIS, pushing PIDF-LO's from unique identifiers = acquired from ILEC through PPPoE intermediate agents pushing data over = the NNI between ILEC and ISP over RADIUS, into a RADIUS database = interfaced to an DHCP OPTION 99/123 server will work!!! f. On 2009-11-22, at 2:14 AM, Winterbottom, James wrote: > May be I am missing something, but your previous email was suggesting = that Ci2 precluded location aware devices, and I think all I did was to = to state why. Are you aware of a location dependability standard that = for device provided location? >=20 > Cheers > James >=20 >=20 >=20 > ________________________________________ > From: Francois D. Menard [fmenard@xittelecom.com] > Sent: Saturday, November 21, 2009 11:55 PM > To: Winterbottom, James > Cc: Richard Barnes; John Lange; ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead >=20 > Error. >=20 > Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY >=20 > For cable: We speak of Reverse DNS in realtime fashion for cable - a = Cable MODEM MAC address is a CIVIC address. >=20 > For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 = identifiers which ISPs will know that they can bind to CIVIC addresses. >=20 > There is no end-user inputted location in our proposed Reduced Ci2 = architecture. >=20 > F. >=20 > On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: >=20 >> Again Francois, you fail to address the key requirement that there is = NO LOCATION DEPENDABILIY offerred by location provided by end-points, = this includes location that traverses end-points. There is far more of a = standard for LIS to LIS communication, including the NENA TRD = (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there = is any form location dependability. >>=20 >> So, having a location enabled or capable end-point without a standard = for location dependability is unlikely to meet any degree of = acceptability. Again ECRIT Direct goes a long way towards addressing = these requirements. >>=20 >> Cheers >> James >>=20 >> ________________________________________ >> From: Francois D. Menard [fmenard@xittelecom.com] >> Sent: Saturday, November 21, 2009 10:44 PM >> To: Winterbottom, James >> Cc: Richard Barnes; John Lange; ecrit >> Subject: Re: [Ecrit] Nomadic VOIP is dead >>=20 >> Actually, ISPs also fear this quite a lot, as there is no standard = for LIS to LIS communications at this time. >>=20 >> Reduced Ci2 was proposed. The document should be posted to the CRTC = web site on monday and I will circulate. >>=20 >> At this time, many of you got it via private correspondance. >>=20 >> We think that wholesale DSL and wholesale cable should enable ISPs to = implement their own LISes without being forced to interface with the = ILEC LIS in the live emergency call path. >>=20 >> Location aware devices should become available prior to Ci2 being = available. >>=20 >> The problem is Ci2 DENIES use of location aware devices. >>=20 >> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their = servers.... and forego all of this nonsense to use the public IP address = as the key to look for a LIS in an ARIN IP address block... its not = going to work. >>=20 >> F. >>=20 >>=20 >> On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: >>=20 >>> I have stayed largely out of this discussion to this point. >>> Ci2 had very specific criteria that simply following base ECRIT = could not meet, namely the location dependability criteria. I, and a = number of others, have been saying in the IETF since before ECRIT came = about that a lack of location dependability was a series impediment to = uptake. I have subsequently visited and talked to quite a number of = regulators around the world and as things currently stand they will not = allow an architecture that does not have a solution to the location = dependability problem. Ci2 addresses this problem by using HELD identity = extensions and a trusted third-party query, though the solution also = addresses quite a number of other barriers to deployment of a base-NENA = i2 solution. >>>=20 >>> Automatic location from the network is required to support all of = the architectures that I have seen, and it is this component of the Ci2 = solution that is deemed to be the most expensive to implement. So unless = people are professing a solution of "only user provided location" then = it seems that going Ci2 or some other architecture saves little to = nothing. My understanding is that there is a strict requirement from the = CRTC that says that the Ci2 solution must not require user-provided = location, so it seems to me that location-enabling the network is not = optional, it is mandatory. >>>=20 >>> As far as I understand it, most of the people complaining about Ci2 = are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. = This removes the VSPs from the equation when it comes to making an = emergency call, so this should alleviate most of your concerns John. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>>=20 >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of = Richard Barnes [rbarnes@bbn.com] >>> Sent: Saturday, November 21, 2009 4:16 PM >>> To: John Lange >>> Cc: ecrit >>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>=20 >>> =46rom my perspective the critical point of the submission is that = VOIP is >>> declining, not growing. >>>=20 >>> I hope you mean that "*Nomadic* VoIP is declining", and even then = "Nomadic" understood in some peculiar sense that excludes soft-phones. = (I'm not familiar with CRTC's specific definition, but whatever it is, = it seems awkward from a technical perspective.) >>>=20 >>> And given that Ci2 does not support services such as Skype, it fails = to >>> service what is by far the largest, and still growing segment of the >>> nomadic VOIP landscape. >>>=20 >>> That seems to me to argue for fixing the current incarnation of Ci2 = rather than doing nothing. >>>=20 >>> On the other hand, as I understand it, the major barrier to support = for VSPs like Skype is the establishment of trust relationships with = them. In which case, it should be straightforward to extend Ci2 to = support a limited number of these VSPs. As the report notes, simply = bringing Skype into the fold would cover more than 90% of users, or = around 720,000 subscribers. >>>=20 >>>=20 >>> To be clear, I support the goal of IP location determination for the >>> purpose of providing enhanced 911 services to nomadic VOIP users. I = just >>> don't support the proposed Ci2 because, to a large extent, it does = not >>> meet that goal. >>>=20 >>> I certainly agree that there are better ways of doing it than = current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration = Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful = than the report seems to imply. >>>=20 >>> --Richard >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Sun Nov 22 14:07:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9133A6882 for ; Sun, 22 Nov 2009 14:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAW6+j8As3K8 for ; Sun, 22 Nov 2009 14:07:11 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id B6EAB3A67DD for ; Sun, 22 Nov 2009 14:07:11 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:59497 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S71736AbZKVWHH convert rfc822-to-8bit (ORCPT ); Sun, 22 Nov 2009 16:07:07 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 22 Nov 2009 16:07:07 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 23 Nov 2009 06:07:04 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Mon, 23 Nov 2009 06:07:10 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acprc6gWo9DrB6xORzGoEmS6W+yOswATBV/A Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> In-Reply-To: <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:07:13 -0000 Hi Francois, Let me read your proposal, but anything that requires changes to CPE is already unable to satisfy the CRTC requirements as I understand them. Cheers James > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Monday, 23 November 2009 12:00 AM > To: Winterbottom, James > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION 99/123 > from an ISP owned LIS, pushing PIDF-LO's from unique identifiers acquired > from ILEC through PPPoE intermediate agents pushing data over the NNI > between ILEC and ISP over RADIUS, into a RADIUS database interfaced to an > DHCP OPTION 99/123 server will work!!! > > f. > > On 2009-11-22, at 2:14 AM, Winterbottom, James wrote: > > > May be I am missing something, but your previous email was suggesting > that Ci2 precluded location aware devices, and I think all I did was to to > state why. Are you aware of a location dependability standard that for > device provided location? > > > > Cheers > > James > > > > > > > > ________________________________________ > > From: Francois D. Menard [fmenard@xittelecom.com] > > Sent: Saturday, November 21, 2009 11:55 PM > > To: Winterbottom, James > > Cc: Richard Barnes; John Lange; ecrit > > Subject: Re: [Ecrit] Nomadic VOIP is dead > > > > Error. > > > > Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY > > > > For cable: We speak of Reverse DNS in realtime fashion for cable - a > Cable MODEM MAC address is a CIVIC address. > > > > For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 > identifiers which ISPs will know that they can bind to CIVIC addresses. > > > > There is no end-user inputted location in our proposed Reduced Ci2 > architecture. > > > > F. > > > > On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: > > > >> Again Francois, you fail to address the key requirement that there is > NO LOCATION DEPENDABILIY offerred by location provided by end-points, this > includes location that traverses end-points. There is far more of a > standard for LIS to LIS communication, including the NENA TRD > (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there > is any form location dependability. > >> > >> So, having a location enabled or capable end-point without a standard > for location dependability is unlikely to meet any degree of > acceptability. Again ECRIT Direct goes a long way towards addressing these > requirements. > >> > >> Cheers > >> James > >> > >> ________________________________________ > >> From: Francois D. Menard [fmenard@xittelecom.com] > >> Sent: Saturday, November 21, 2009 10:44 PM > >> To: Winterbottom, James > >> Cc: Richard Barnes; John Lange; ecrit > >> Subject: Re: [Ecrit] Nomadic VOIP is dead > >> > >> Actually, ISPs also fear this quite a lot, as there is no standard for > LIS to LIS communications at this time. > >> > >> Reduced Ci2 was proposed. The document should be posted to the CRTC > web site on monday and I will circulate. > >> > >> At this time, many of you got it via private correspondance. > >> > >> We think that wholesale DSL and wholesale cable should enable ISPs to > implement their own LISes without being forced to interface with the ILEC > LIS in the live emergency call path. > >> > >> Location aware devices should become available prior to Ci2 being > available. > >> > >> The problem is Ci2 DENIES use of location aware devices. > >> > >> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their > servers.... and forego all of this nonsense to use the public IP address > as the key to look for a LIS in an ARIN IP address block... its not going > to work. > >> > >> F. > >> > >> > >> On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: > >> > >>> I have stayed largely out of this discussion to this point. > >>> Ci2 had very specific criteria that simply following base ECRIT could > not meet, namely the location dependability criteria. I, and a number of > others, have been saying in the IETF since before ECRIT came about that a > lack of location dependability was a series impediment to uptake. I have > subsequently visited and talked to quite a number of regulators around the > world and as things currently stand they will not allow an architecture > that does not have a solution to the location dependability problem. Ci2 > addresses this problem by using HELD identity extensions and a trusted > third-party query, though the solution also addresses quite a number of > other barriers to deployment of a base-NENA i2 solution. > >>> > >>> Automatic location from the network is required to support all of the > architectures that I have seen, and it is this component of the Ci2 > solution that is deemed to be the most expensive to implement. So unless > people are professing a solution of "only user provided location" then it > seems that going Ci2 or some other architecture saves little to nothing. > My understanding is that there is a strict requirement from the CRTC that > says that the Ci2 solution must not require user-provided location, so it > seems to me that location-enabling the network is not optional, it is > mandatory. > >>> > >>> As far as I understand it, most of the people complaining about Ci2 > are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This > removes the VSPs from the equation when it comes to making an emergency > call, so this should alleviate most of your concerns John. > >>> > >>> Cheers > >>> James > >>> > >>> > >>> > >>> > >>> ________________________________________ > >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes [rbarnes@bbn.com] > >>> Sent: Saturday, November 21, 2009 4:16 PM > >>> To: John Lange > >>> Cc: ecrit > >>> Subject: Re: [Ecrit] Nomadic VOIP is dead > >>> > >>> From my perspective the critical point of the submission is that VOIP > is > >>> declining, not growing. > >>> > >>> I hope you mean that "*Nomadic* VoIP is declining", and even then > "Nomadic" understood in some peculiar sense that excludes soft-phones. > (I'm not familiar with CRTC's specific definition, but whatever it is, it > seems awkward from a technical perspective.) > >>> > >>> And given that Ci2 does not support services such as Skype, it fails > to > >>> service what is by far the largest, and still growing segment of the > >>> nomadic VOIP landscape. > >>> > >>> That seems to me to argue for fixing the current incarnation of Ci2 > rather than doing nothing. > >>> > >>> On the other hand, as I understand it, the major barrier to support > for VSPs like Skype is the establishment of trust relationships with them. > In which case, it should be straightforward to extend Ci2 to support a > limited number of these VSPs. As the report notes, simply bringing Skype > into the fold would cover more than 90% of users, or around 720,000 > subscribers. > >>> > >>> > >>> To be clear, I support the goal of IP location determination for the > >>> purpose of providing enhanced 911 services to nomadic VOIP users. I > just > >>> don't support the proposed Ci2 because, to a large extent, it does not > >>> meet that goal. > >>> > >>> I certainly agree that there are better ways of doing it than current > Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols > (LCPs) -- but at the same time, Ci2 is more broadly useful than the report > seems to imply. > >>> > >>> --Richard > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > From fmenard@xittelecom.com Sun Nov 22 17:01:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C4D3A6927 for ; Sun, 22 Nov 2009 17:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqPEeI1idf8c for ; Sun, 22 Nov 2009 17:01:44 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 4A04C3A68BC for ; Sun, 22 Nov 2009 17:01:43 -0800 (PST) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCNJC-0006Pf-3N; Sun, 22 Nov 2009 20:01:38 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCNJB-0004v3-CC; Sun, 22 Nov 2009 20:01:38 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> Date: Sun, 22 Nov 2009 20:01:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:01:47 -0000 Can Canadians see $300M+ invested on an infrastructure tracking public = IP addresses for 10,000 VoIP end-points that can be upgraded to become = location aware faster than Ci2 will be implemented ? The CRTC did never require that the chosen solution not require a change = into CPEs. That's the sales pitch of the ILECs. The way I see this, we could get away with spending $2M and get the = problem fixed. Or get stuck in court review for 5 years, on the promise of something = nobody can afford to implement. F. On 2009-11-22, at 5:07 PM, Winterbottom, James wrote: > Hi Francois, >=20 > Let me read your proposal, but anything that requires changes to CPE = is already unable to satisfy the CRTC requirements as I understand them. >=20 > Cheers > James >=20 >=20 >> -----Original Message----- >> From: Francois D. Menard [mailto:fmenard@xittelecom.com] >> Sent: Monday, 23 November 2009 12:00 AM >> To: Winterbottom, James >> Cc: ecrit >> Subject: Re: [Ecrit] Nomadic VOIP is dead >>=20 >> The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION = 99/123 >> from an ISP owned LIS, pushing PIDF-LO's from unique identifiers = acquired >> from ILEC through PPPoE intermediate agents pushing data over the NNI >> between ILEC and ISP over RADIUS, into a RADIUS database interfaced = to an >> DHCP OPTION 99/123 server will work!!! >>=20 >> f. >>=20 >> On 2009-11-22, at 2:14 AM, Winterbottom, James wrote: >>=20 >>> May be I am missing something, but your previous email was = suggesting >> that Ci2 precluded location aware devices, and I think all I did was = to to >> state why. Are you aware of a location dependability standard that = for >> device provided location? >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>> ________________________________________ >>> From: Francois D. Menard [fmenard@xittelecom.com] >>> Sent: Saturday, November 21, 2009 11:55 PM >>> To: Winterbottom, James >>> Cc: Richard Barnes; John Lange; ecrit >>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>=20 >>> Error. >>>=20 >>> Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY >>>=20 >>> For cable: We speak of Reverse DNS in realtime fashion for cable - a >> Cable MODEM MAC address is a CIVIC address. >>>=20 >>> For DSL: We speak of PPPoE intermediate agents showing unique Layer = 2 >> identifiers which ISPs will know that they can bind to CIVIC = addresses. >>>=20 >>> There is no end-user inputted location in our proposed Reduced Ci2 >> architecture. >>>=20 >>> F. >>>=20 >>> On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: >>>=20 >>>> Again Francois, you fail to address the key requirement that there = is >> NO LOCATION DEPENDABILIY offerred by location provided by end-points, = this >> includes location that traverses end-points. There is far more of a >> standard for LIS to LIS communication, including the NENA TRD >> (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than = there >> is any form location dependability. >>>>=20 >>>> So, having a location enabled or capable end-point without a = standard >> for location dependability is unlikely to meet any degree of >> acceptability. Again ECRIT Direct goes a long way towards addressing = these >> requirements. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>> ________________________________________ >>>> From: Francois D. Menard [fmenard@xittelecom.com] >>>> Sent: Saturday, November 21, 2009 10:44 PM >>>> To: Winterbottom, James >>>> Cc: Richard Barnes; John Lange; ecrit >>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>=20 >>>> Actually, ISPs also fear this quite a lot, as there is no standard = for >> LIS to LIS communications at this time. >>>>=20 >>>> Reduced Ci2 was proposed. The document should be posted to the = CRTC >> web site on monday and I will circulate. >>>>=20 >>>> At this time, many of you got it via private correspondance. >>>>=20 >>>> We think that wholesale DSL and wholesale cable should enable ISPs = to >> implement their own LISes without being forced to interface with the = ILEC >> LIS in the live emergency call path. >>>>=20 >>>> Location aware devices should become available prior to Ci2 being >> available. >>>>=20 >>>> The problem is Ci2 DENIES use of location aware devices. >>>>=20 >>>> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their >> servers.... and forego all of this nonsense to use the public IP = address >> as the key to look for a LIS in an ARIN IP address block... its not = going >> to work. >>>>=20 >>>> F. >>>>=20 >>>>=20 >>>> On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: >>>>=20 >>>>> I have stayed largely out of this discussion to this point. >>>>> Ci2 had very specific criteria that simply following base ECRIT = could >> not meet, namely the location dependability criteria. I, and a number = of >> others, have been saying in the IETF since before ECRIT came about = that a >> lack of location dependability was a series impediment to uptake. I = have >> subsequently visited and talked to quite a number of regulators = around the >> world and as things currently stand they will not allow an = architecture >> that does not have a solution to the location dependability problem. = Ci2 >> addresses this problem by using HELD identity extensions and a = trusted >> third-party query, though the solution also addresses quite a number = of >> other barriers to deployment of a base-NENA i2 solution. >>>>>=20 >>>>> Automatic location from the network is required to support all of = the >> architectures that I have seen, and it is this component of the Ci2 >> solution that is deemed to be the most expensive to implement. So = unless >> people are professing a solution of "only user provided location" = then it >> seems that going Ci2 or some other architecture saves little to = nothing. >> My understanding is that there is a strict requirement from the CRTC = that >> says that the Ci2 solution must not require user-provided location, = so it >> seems to me that location-enabling the network is not optional, it is >> mandatory. >>>>>=20 >>>>> As far as I understand it, most of the people complaining about = Ci2 >> are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. = This >> removes the VSPs from the equation when it comes to making an = emergency >> call, so this should alleviate most of your concerns John. >>>>>=20 >>>>> Cheers >>>>> James >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >> Richard Barnes [rbarnes@bbn.com] >>>>> Sent: Saturday, November 21, 2009 4:16 PM >>>>> To: John Lange >>>>> Cc: ecrit >>>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>>=20 >>>>> =46rom my perspective the critical point of the submission is that = VOIP >> is >>>>> declining, not growing. >>>>>=20 >>>>> I hope you mean that "*Nomadic* VoIP is declining", and even then >> "Nomadic" understood in some peculiar sense that excludes = soft-phones. >> (I'm not familiar with CRTC's specific definition, but whatever it = is, it >> seems awkward from a technical perspective.) >>>>>=20 >>>>> And given that Ci2 does not support services such as Skype, it = fails >> to >>>>> service what is by far the largest, and still growing segment of = the >>>>> nomadic VOIP landscape. >>>>>=20 >>>>> That seems to me to argue for fixing the current incarnation of = Ci2 >> rather than doing nothing. >>>>>=20 >>>>> On the other hand, as I understand it, the major barrier to = support >> for VSPs like Skype is the establishment of trust relationships with = them. >> In which case, it should be straightforward to extend Ci2 to support = a >> limited number of these VSPs. As the report notes, simply bringing = Skype >> into the fold would cover more than 90% of users, or around 720,000 >> subscribers. >>>>>=20 >>>>>=20 >>>>> To be clear, I support the goal of IP location determination for = the >>>>> purpose of providing enhanced 911 services to nomadic VOIP users. = I >> just >>>>> don't support the proposed Ci2 because, to a large extent, it does = not >>>>> meet that goal. >>>>>=20 >>>>> I certainly agree that there are better ways of doing it than = current >> Ci2 -- mainly, just deploying the GEOPRIV Location Configuration = Protocols >> (LCPs) -- but at the same time, Ci2 is more broadly useful than the = report >> seems to imply. >>>>>=20 >>>>> --Richard >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From James.Winterbottom@andrew.com Sun Nov 22 17:08:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917A43A69C8 for ; Sun, 22 Nov 2009 17:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd0wWA9EJhsF for ; Sun, 22 Nov 2009 17:08:31 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 249103A69BA for ; Sun, 22 Nov 2009 17:08:31 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:3431 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S72676AbZKWBI1 convert rfc822-to-8bit (ORCPT ); Sun, 22 Nov 2009 19:08:27 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 22 Nov 2009 19:08:27 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 23 Nov 2009 09:08:21 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Mon, 23 Nov 2009 09:08:19 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acpr2IYhRqamqVKhRS2awrwZTRmd0wAACcog Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> In-Reply-To: <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:08:32 -0000 Let me try again. Regardless of how you deliver the location, the expensive part will be in setting up the systems to determine it in the first place. You will need to this no matter what system you put in place. So it is very very unclear to me where you see this magical cost saving coming from. I am also still quite confused over how providing a location to an end-point over DHCP solves the location veracity problem that I described previously. Perhaps you can explain in a little more detail what assurance the PSAP has that this location is actually attributable to the calling entity. Cheers James > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Monday, 23 November 2009 12:02 PM > To: Winterbottom, James > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > Can Canadians see $300M+ invested on an infrastructure tracking public IP > addresses for 10,000 VoIP end-points that can be upgraded to become > location aware faster than Ci2 will be implemented ? > > The CRTC did never require that the chosen solution not require a change > into CPEs. That's the sales pitch of the ILECs. > > The way I see this, we could get away with spending $2M and get the > problem fixed. > > Or get stuck in court review for 5 years, on the promise of something > nobody can afford to implement. > > F. > > On 2009-11-22, at 5:07 PM, Winterbottom, James wrote: > > > Hi Francois, > > > > Let me read your proposal, but anything that requires changes to CPE is > already unable to satisfy the CRTC requirements as I understand them. > > > > Cheers > > James > > > > > >> -----Original Message----- > >> From: Francois D. Menard [mailto:fmenard@xittelecom.com] > >> Sent: Monday, 23 November 2009 12:00 AM > >> To: Winterbottom, James > >> Cc: ecrit > >> Subject: Re: [Ecrit] Nomadic VOIP is dead > >> > >> The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION 99/123 > >> from an ISP owned LIS, pushing PIDF-LO's from unique identifiers > acquired > >> from ILEC through PPPoE intermediate agents pushing data over the NNI > >> between ILEC and ISP over RADIUS, into a RADIUS database interfaced to > an > >> DHCP OPTION 99/123 server will work!!! > >> > >> f. > >> > >> On 2009-11-22, at 2:14 AM, Winterbottom, James wrote: > >> > >>> May be I am missing something, but your previous email was suggesting > >> that Ci2 precluded location aware devices, and I think all I did was to > to > >> state why. Are you aware of a location dependability standard that for > >> device provided location? > >>> > >>> Cheers > >>> James > >>> > >>> > >>> > >>> ________________________________________ > >>> From: Francois D. Menard [fmenard@xittelecom.com] > >>> Sent: Saturday, November 21, 2009 11:55 PM > >>> To: Winterbottom, James > >>> Cc: Richard Barnes; John Lange; ecrit > >>> Subject: Re: [Ecrit] Nomadic VOIP is dead > >>> > >>> Error. > >>> > >>> Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY > >>> > >>> For cable: We speak of Reverse DNS in realtime fashion for cable - a > >> Cable MODEM MAC address is a CIVIC address. > >>> > >>> For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 > >> identifiers which ISPs will know that they can bind to CIVIC addresses. > >>> > >>> There is no end-user inputted location in our proposed Reduced Ci2 > >> architecture. > >>> > >>> F. > >>> > >>> On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: > >>> > >>>> Again Francois, you fail to address the key requirement that there is > >> NO LOCATION DEPENDABILIY offerred by location provided by end-points, > this > >> includes location that traverses end-points. There is far more of a > >> standard for LIS to LIS communication, including the NENA TRD > >> (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than > there > >> is any form location dependability. > >>>> > >>>> So, having a location enabled or capable end-point without a standard > >> for location dependability is unlikely to meet any degree of > >> acceptability. Again ECRIT Direct goes a long way towards addressing > these > >> requirements. > >>>> > >>>> Cheers > >>>> James > >>>> > >>>> ________________________________________ > >>>> From: Francois D. Menard [fmenard@xittelecom.com] > >>>> Sent: Saturday, November 21, 2009 10:44 PM > >>>> To: Winterbottom, James > >>>> Cc: Richard Barnes; John Lange; ecrit > >>>> Subject: Re: [Ecrit] Nomadic VOIP is dead > >>>> > >>>> Actually, ISPs also fear this quite a lot, as there is no standard > for > >> LIS to LIS communications at this time. > >>>> > >>>> Reduced Ci2 was proposed. The document should be posted to the CRTC > >> web site on monday and I will circulate. > >>>> > >>>> At this time, many of you got it via private correspondance. > >>>> > >>>> We think that wholesale DSL and wholesale cable should enable ISPs to > >> implement their own LISes without being forced to interface with the > ILEC > >> LIS in the live emergency call path. > >>>> > >>>> Location aware devices should become available prior to Ci2 being > >> available. > >>>> > >>>> The problem is Ci2 DENIES use of location aware devices. > >>>> > >>>> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their > >> servers.... and forego all of this nonsense to use the public IP > address > >> as the key to look for a LIS in an ARIN IP address block... its not > going > >> to work. > >>>> > >>>> F. > >>>> > >>>> > >>>> On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: > >>>> > >>>>> I have stayed largely out of this discussion to this point. > >>>>> Ci2 had very specific criteria that simply following base ECRIT > could > >> not meet, namely the location dependability criteria. I, and a number > of > >> others, have been saying in the IETF since before ECRIT came about that > a > >> lack of location dependability was a series impediment to uptake. I > have > >> subsequently visited and talked to quite a number of regulators around > the > >> world and as things currently stand they will not allow an architecture > >> that does not have a solution to the location dependability problem. > Ci2 > >> addresses this problem by using HELD identity extensions and a trusted > >> third-party query, though the solution also addresses quite a number of > >> other barriers to deployment of a base-NENA i2 solution. > >>>>> > >>>>> Automatic location from the network is required to support all of > the > >> architectures that I have seen, and it is this component of the Ci2 > >> solution that is deemed to be the most expensive to implement. So > unless > >> people are professing a solution of "only user provided location" then > it > >> seems that going Ci2 or some other architecture saves little to > nothing. > >> My understanding is that there is a strict requirement from the CRTC > that > >> says that the Ci2 solution must not require user-provided location, so > it > >> seems to me that location-enabling the network is not optional, it is > >> mandatory. > >>>>> > >>>>> As far as I understand it, most of the people complaining about Ci2 > >> are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. > This > >> removes the VSPs from the equation when it comes to making an emergency > >> call, so this should alleviate most of your concerns John. > >>>>> > >>>>> Cheers > >>>>> James > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of > >> Richard Barnes [rbarnes@bbn.com] > >>>>> Sent: Saturday, November 21, 2009 4:16 PM > >>>>> To: John Lange > >>>>> Cc: ecrit > >>>>> Subject: Re: [Ecrit] Nomadic VOIP is dead > >>>>> > >>>>> From my perspective the critical point of the submission is that > VOIP > >> is > >>>>> declining, not growing. > >>>>> > >>>>> I hope you mean that "*Nomadic* VoIP is declining", and even then > >> "Nomadic" understood in some peculiar sense that excludes soft-phones. > >> (I'm not familiar with CRTC's specific definition, but whatever it is, > it > >> seems awkward from a technical perspective.) > >>>>> > >>>>> And given that Ci2 does not support services such as Skype, it fails > >> to > >>>>> service what is by far the largest, and still growing segment of the > >>>>> nomadic VOIP landscape. > >>>>> > >>>>> That seems to me to argue for fixing the current incarnation of Ci2 > >> rather than doing nothing. > >>>>> > >>>>> On the other hand, as I understand it, the major barrier to support > >> for VSPs like Skype is the establishment of trust relationships with > them. > >> In which case, it should be straightforward to extend Ci2 to support a > >> limited number of these VSPs. As the report notes, simply bringing > Skype > >> into the fold would cover more than 90% of users, or around 720,000 > >> subscribers. > >>>>> > >>>>> > >>>>> To be clear, I support the goal of IP location determination for the > >>>>> purpose of providing enhanced 911 services to nomadic VOIP users. I > >> just > >>>>> don't support the proposed Ci2 because, to a large extent, it does > not > >>>>> meet that goal. > >>>>> > >>>>> I certainly agree that there are better ways of doing it than > current > >> Ci2 -- mainly, just deploying the GEOPRIV Location Configuration > Protocols > >> (LCPs) -- but at the same time, Ci2 is more broadly useful than the > report > >> seems to imply. > >>>>> > >>>>> --Richard > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > From bernard_aboba@hotmail.com Sun Nov 22 17:14:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E313A69BA for ; Sun, 22 Nov 2009 17:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5MrBityiDb6 for ; Sun, 22 Nov 2009 17:14:16 -0800 (PST) Received: from blu0-omc4-s34.blu0.hotmail.com (blu0-omc4-s34.blu0.hotmail.com [65.55.111.173]) by core3.amsl.com (Postfix) with ESMTP id E6FD73A6927 for ; Sun, 22 Nov 2009 17:14:15 -0800 (PST) Received: from BLU137-W12 ([65.55.111.136]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 17:14:12 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_fd258be9-12f0-4f8c-b3c0-09dc4482b4f6_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 22 Nov 2009 17:14:11 -0800 Importance: Normal In-Reply-To: <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site>, <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com>, <1258757367.3212.43.camel@linux-k6vx.site>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, , <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com>, <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com>, <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 01:14:12.0160 (UTC) FILETIME=[44037400:01CA6BDA] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:14:17 -0000 --_fd258be9-12f0-4f8c-b3c0-09dc4482b4f6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keep in mind that the 10=2C000 consumer endpoints doesn't include enterpris= e VOIP users. Therefore even if the consumer problem could be solved by gi= ving each of the 10=2C000 users a free cell phone that can make emergency c= alls even if there are no funds associated with the SIM=2C there will still= be multi-line PBXes for whom transmission of location information would re= present an important advance. For a while now=2C NENA has been advocating = legislation requiring enterprise customers to provide a solution to that pr= oblem=2C to which the ECRIT architecture is relevant.=20 > From: fmenard@xittelecom.com > Date: Sun=2C 22 Nov 2009 20:01:36 -0500 > To: James.Winterbottom@andrew.com > CC: ecrit@ietf.org > Subject: Re: [Ecrit] Nomadic VOIP is dead >=20 > Can Canadians see $300M+ invested on an infrastructure tracking public IP= addresses for 10=2C000 VoIP end-points that can be upgraded to become loca= tion aware faster than Ci2 will be implemented ? >=20 > The CRTC did never require that the chosen solution not require a change = into CPEs. That's the sales pitch of the ILECs. >=20 > The way I see this=2C we could get away with spending $2M and get the pro= blem fixed. >=20 > Or get stuck in court review for 5 years=2C on the promise of something n= obody can afford to implement. >=20 > F. = --_fd258be9-12f0-4f8c-b3c0-09dc4482b4f6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keep in mind that the 10=2C000 consumer endpoints doesn't include enterpris= e VOIP users. =3B Therefore even if the consumer problem could be solve= d by giving each of the 10=2C000 users a free cell phone that can make emer= gency calls even if there are no funds associated with the SIM=2C there wil= l still be multi-line PBXes for whom transmission of location information w= ould represent an important advance. =3B For a while now=2C NENA has be= en advocating legislation requiring enterprise customers to provide a solut= ion to that problem=2C to which the ECRIT architecture is relevant.
>=3B From: fmenard@xittelecom.com
>=3B Date: Sun=2C 22 Nov 2009 20:= 01:36 -0500
>=3B To: James.Winterbottom@andrew.com
>=3B CC: ecrit= @ietf.org
>=3B Subject: Re: [Ecrit] Nomadic VOIP is dead
>=3B >=3B Can Canadians see $300M+ invested on an infrastructure tracking pub= lic IP addresses for 10=2C000 VoIP end-points that can be upgraded to becom= e location aware faster than Ci2 will be implemented ?
>=3B
>=3B= The CRTC did never require that the chosen solution not require a change i= nto CPEs. That's the sales pitch of the ILECs.
>=3B
>=3B The way= I see this=2C we could get away with spending $2M and get the problem fixe= d.
>=3B
>=3B Or get stuck in court review for 5 years=2C on the = promise of something nobody can afford to implement.
>=3B
>=3B F= .

= --_fd258be9-12f0-4f8c-b3c0-09dc4482b4f6_-- From bernard_aboba@hotmail.com Sun Nov 22 17:16:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC943A6927 for ; Sun, 22 Nov 2009 17:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XX522m16FJd for ; Sun, 22 Nov 2009 17:16:06 -0800 (PST) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by core3.amsl.com (Postfix) with ESMTP id 3C44B3A6860 for ; Sun, 22 Nov 2009 17:16:06 -0800 (PST) Received: from BLU137-W29 ([65.55.111.135]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 17:16:02 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b20beaab-6596-4b21-b0f8-1f50acdc1b6d_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 22 Nov 2009 17:16:02 -0800 Importance: Normal In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site>, <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com>, <1258757367.3212.43.camel@linux-k6vx.site>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, , <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com>, <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com>, <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 01:16:02.0613 (UTC) FILETIME=[85D93E50:01CA6BDA] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:16:07 -0000 --_b20beaab-6596-4b21-b0f8-1f50acdc1b6d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C I'm missing that part as well. If the location information is obtai= ned via RADIUS and placed in a database=2C then that database can be made e= qually accessible for use with any LCP=2C including HELD. =20 > Let me try again. > Regardless of how you deliver the location=2C the expensive part will be = in setting up the systems to determine it in the first place. You will need= to this no matter what system you put in place. So it is very very unclear= to me where you see this magical cost saving coming from.=20 >=20 > I am also still quite confused over how providing a location to an end-po= int over DHCP solves the location veracity problem that I described previou= sly. Perhaps you can explain in a little more detail what assurance the PSA= P has that this location is actually attributable to the calling entity. >=20 > Cheers > James = --_b20beaab-6596-4b21-b0f8-1f50acdc1b6d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C I'm missing that part as well. =3B If the location information i= s obtained via RADIUS and placed in a database=2C then that database can be= made equally accessible for use with any LCP=2C including HELD. =3B
>=3B Let me try again.
>=3B Regardless of how you deliver the = location=2C the expensive part will be in setting up the systems to determi= ne it in the first place. You will need to this no matter what system you p= ut in place. So it is very very unclear to me where you see this magical co= st saving coming from.
>=3B
>=3B I am also still quite confused= over how providing a location to an end-point over DHCP solves the locatio= n veracity problem that I described previously. Perhaps you can explain in = a little more detail what assurance the PSAP has that this location is actu= ally attributable to the calling entity.
>=3B
>=3B Cheers
>= =3B James

= --_b20beaab-6596-4b21-b0f8-1f50acdc1b6d_-- From fmenard@xittelecom.com Sun Nov 22 19:58:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872623A6992 for ; Sun, 22 Nov 2009 19:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DONdcEss2KFe for ; Sun, 22 Nov 2009 19:58:09 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id ACC623A6827 for ; Sun, 22 Nov 2009 19:58:09 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCQ3w-0006Aw-40; Sun, 22 Nov 2009 22:58:04 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCQ3v-0007pB-Ob; Sun, 22 Nov 2009 22:58:03 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: Date: Sun, 22 Nov 2009 22:58:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <558FE440-3EEE-4AFE-8D45-F34D85F89027@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site>, <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com>, <1258757367.3212.43.camel@linux-k6vx.site>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, , <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, , , <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com>, <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com>, <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1077) Cc: james.winterbottom@andrew.com, ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:58:10 -0000 Canada's Ci2 has not been designed to solve the enterprise PBX problem. That requires a special assembly tariff where you register DIDs to a = CIVIC address and you make sure you call 9-1-1 with that DID if you want = dispatch to the right place. ILEC made a point to ignore enterprise applications, or VoIP not on the = public Internet with public IPs. This is not a SIP-based interconnection to a PSAP gateway run by = ILECs... its an Internet-based interconnection only meant to work with = Internet Public IP addresses. This is why SIPCORE LOC CONVEYANCE is the way to go.. then the IP = address is irrelevant. f. On 2009-11-22, at 8:14 PM, Bernard Aboba wrote: > Keep in mind that the 10,000 consumer endpoints doesn't include = enterprise VOIP users. Therefore even if the consumer problem could be = solved by giving each of the 10,000 users a free cell phone that can = make emergency calls even if there are no funds associated with the SIM, = there will still be multi-line PBXes for whom transmission of location = information would represent an important advance. For a while now, NENA = has been advocating legislation requiring enterprise customers to = provide a solution to that problem, to which the ECRIT architecture is = relevant.=20 >=20 > > From: fmenard@xittelecom.com > > Date: Sun, 22 Nov 2009 20:01:36 -0500 > > To: James.Winterbottom@andrew.com > > CC: ecrit@ietf.org > > Subject: Re: [Ecrit] Nomadic VOIP is dead > >=20 > > Can Canadians see $300M+ invested on an infrastructure tracking = public IP addresses for 10,000 VoIP end-points that can be upgraded to = become location aware faster than Ci2 will be implemented ? > >=20 > > The CRTC did never require that the chosen solution not require a = change into CPEs. That's the sales pitch of the ILECs. > >=20 > > The way I see this, we could get away with spending $2M and get the = problem fixed. > >=20 > > Or get stuck in court review for 5 years, on the promise of = something nobody can afford to implement. > >=20 > > F. >=20 From fmenard@xittelecom.com Sun Nov 22 20:07:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F60E3A69FE for ; Sun, 22 Nov 2009 20:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dgG7b0gwI-H for ; Sun, 22 Nov 2009 20:07:41 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id C27773A67D7 for ; Sun, 22 Nov 2009 20:07:41 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCQDB-0006fx-6k; Sun, 22 Nov 2009 23:07:37 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCQDA-0008OQ-Aj; Sun, 22 Nov 2009 23:07:37 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> Date: Sun, 22 Nov 2009 23:07:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:07:43 -0000 > Regardless of how you deliver the location, the expensive part will be = in setting up the systems to determine it in the first place. You will = need to this no matter what system you put in place. So it is very very = unclear to me where you see this magical cost saving coming from.=20 >=20 I am not sure you actually 'DETERMINE' a location. Its more like you = 'REGISTER A BINDING OF A UNIQUE IDENTIFIER WITH CIVIC' In the case of wholesale cable modem, this is the MAC address of the = cable modem. The cable modem is expected not to move. The only approved system for reporting cable modem MAC addresses is a = Reverse DNS zone transfer (private DNS) as per CRTC Decision 2007-1: http://www.crtc.gc.ca/eng/archive/2007/dt2007-1.htm We just need it realtime. For DSL wholesale, if its IP DSLAMs, DSL modems have MAC addresses and = its the same deal. For DSL wholesale, for ATM DSLAMs, then its PPPoE intermediate agent = tags shipped over RADIUS accounting to the ISP. The ISP will register the 'unique identifier' with the PPPoE logon, and = populate its LIS with it. I do not think that the LIS will be all that expensive in that case... = its a matter of putting a database which links FreeRadius to ISC DHCPD = ... all opensource stuff. We just need layer 2 identifiers which are guaranteed to be unique when = we are 'firehosed' with wholesale traffic.... we want to make sure that = there is something unique for every water droplets stream in the big = bundle of water hitting the ISP. Hopefully you see where the cost saving is coming from. Open Source. No = HELD. No BEEP. No Bell Canada patents. (Did Bell Canada report to the = IETF its intellectual property in GEOPRIV ?). > I am also still quite confused over how providing a location to an = end-point over DHCP solves the location veracity problem that I = described previously. Perhaps you can explain in a little more detail = what assurance the PSAP has that this location is actually attributable = to the calling entity. The PSAP in Canada sees diddly squat in Ci2. The ILEC does it on its = behalf. The ILEC has contractual relationships with ISPs which shield = PSAPs from any requirement to engage into veracity assessment. Please = indicate when and where PSAPs actually engage into such an undertaking = in the context of Ci2 and how this differs with ECRIT. -=3DFrancois=3D- >=20 > Cheers > James >=20 >=20 >> -----Original Message----- >> From: Francois D. Menard [mailto:fmenard@xittelecom.com] >> Sent: Monday, 23 November 2009 12:02 PM >> To: Winterbottom, James >> Cc: ecrit >> Subject: Re: [Ecrit] Nomadic VOIP is dead >>=20 >> Can Canadians see $300M+ invested on an infrastructure tracking = public IP >> addresses for 10,000 VoIP end-points that can be upgraded to become >> location aware faster than Ci2 will be implemented ? >>=20 >> The CRTC did never require that the chosen solution not require a = change >> into CPEs. That's the sales pitch of the ILECs. >>=20 >> The way I see this, we could get away with spending $2M and get the >> problem fixed. >>=20 >> Or get stuck in court review for 5 years, on the promise of something >> nobody can afford to implement. >>=20 >> F. >>=20 >> On 2009-11-22, at 5:07 PM, Winterbottom, James wrote: >>=20 >>> Hi Francois, >>>=20 >>> Let me read your proposal, but anything that requires changes to CPE = is >> already unable to satisfy the CRTC requirements as I understand them. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Francois D. Menard [mailto:fmenard@xittelecom.com] >>>> Sent: Monday, 23 November 2009 12:00 AM >>>> To: Winterbottom, James >>>> Cc: ecrit >>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>=20 >>>> The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION = 99/123 >>>> from an ISP owned LIS, pushing PIDF-LO's from unique identifiers >> acquired >>>> from ILEC through PPPoE intermediate agents pushing data over the = NNI >>>> between ILEC and ISP over RADIUS, into a RADIUS database interfaced = to >> an >>>> DHCP OPTION 99/123 server will work!!! >>>>=20 >>>> f. >>>>=20 >>>> On 2009-11-22, at 2:14 AM, Winterbottom, James wrote: >>>>=20 >>>>> May be I am missing something, but your previous email was = suggesting >>>> that Ci2 precluded location aware devices, and I think all I did = was to >> to >>>> state why. Are you aware of a location dependability standard that = for >>>> device provided location? >>>>>=20 >>>>> Cheers >>>>> James >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: Francois D. Menard [fmenard@xittelecom.com] >>>>> Sent: Saturday, November 21, 2009 11:55 PM >>>>> To: Winterbottom, James >>>>> Cc: Richard Barnes; John Lange; ecrit >>>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>>=20 >>>>> Error. >>>>>=20 >>>>> Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY >>>>>=20 >>>>> For cable: We speak of Reverse DNS in realtime fashion for cable - = a >>>> Cable MODEM MAC address is a CIVIC address. >>>>>=20 >>>>> For DSL: We speak of PPPoE intermediate agents showing unique = Layer 2 >>>> identifiers which ISPs will know that they can bind to CIVIC = addresses. >>>>>=20 >>>>> There is no end-user inputted location in our proposed Reduced Ci2 >>>> architecture. >>>>>=20 >>>>> F. >>>>>=20 >>>>> On 2009-11-21, at 11:52 PM, Winterbottom, James wrote: >>>>>=20 >>>>>> Again Francois, you fail to address the key requirement that = there is >>>> NO LOCATION DEPENDABILIY offerred by location provided by = end-points, >> this >>>> includes location that traverses end-points. There is far more of a >>>> standard for LIS to LIS communication, including the NENA TRD >>>> (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than >> there >>>> is any form location dependability. >>>>>>=20 >>>>>> So, having a location enabled or capable end-point without a = standard >>>> for location dependability is unlikely to meet any degree of >>>> acceptability. Again ECRIT Direct goes a long way towards = addressing >> these >>>> requirements. >>>>>>=20 >>>>>> Cheers >>>>>> James >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: Francois D. Menard [fmenard@xittelecom.com] >>>>>> Sent: Saturday, November 21, 2009 10:44 PM >>>>>> To: Winterbottom, James >>>>>> Cc: Richard Barnes; John Lange; ecrit >>>>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>>>=20 >>>>>> Actually, ISPs also fear this quite a lot, as there is no = standard >> for >>>> LIS to LIS communications at this time. >>>>>>=20 >>>>>> Reduced Ci2 was proposed. The document should be posted to the = CRTC >>>> web site on monday and I will circulate. >>>>>>=20 >>>>>> At this time, many of you got it via private correspondance. >>>>>>=20 >>>>>> We think that wholesale DSL and wholesale cable should enable = ISPs to >>>> implement their own LISes without being forced to interface with = the >> ILEC >>>> LIS in the live emergency call path. >>>>>>=20 >>>>>> Location aware devices should become available prior to Ci2 being >>>> available. >>>>>>=20 >>>>>> The problem is Ci2 DENIES use of location aware devices. >>>>>>=20 >>>>>> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their >>>> servers.... and forego all of this nonsense to use the public IP >> address >>>> as the key to look for a LIS in an ARIN IP address block... its not >> going >>>> to work. >>>>>>=20 >>>>>> F. >>>>>>=20 >>>>>>=20 >>>>>> On 2009-11-21, at 5:37 PM, Winterbottom, James wrote: >>>>>>=20 >>>>>>> I have stayed largely out of this discussion to this point. >>>>>>> Ci2 had very specific criteria that simply following base ECRIT >> could >>>> not meet, namely the location dependability criteria. I, and a = number >> of >>>> others, have been saying in the IETF since before ECRIT came about = that >> a >>>> lack of location dependability was a series impediment to uptake. I >> have >>>> subsequently visited and talked to quite a number of regulators = around >> the >>>> world and as things currently stand they will not allow an = architecture >>>> that does not have a solution to the location dependability = problem. >> Ci2 >>>> addresses this problem by using HELD identity extensions and a = trusted >>>> third-party query, though the solution also addresses quite a = number of >>>> other barriers to deployment of a base-NENA i2 solution. >>>>>>>=20 >>>>>>> Automatic location from the network is required to support all = of >> the >>>> architectures that I have seen, and it is this component of the Ci2 >>>> solution that is deemed to be the most expensive to implement. So >> unless >>>> people are professing a solution of "only user provided location" = then >> it >>>> seems that going Ci2 or some other architecture saves little to >> nothing. >>>> My understanding is that there is a strict requirement from the = CRTC >> that >>>> says that the Ci2 solution must not require user-provided location, = so >> it >>>> seems to me that location-enabling the network is not optional, it = is >>>> mandatory. >>>>>>>=20 >>>>>>> As far as I understand it, most of the people complaining about = Ci2 >>>> are VoIP providers, Ci2 morphs quite easily to support ECRIT = Direct. >> This >>>> removes the VSPs from the equation when it comes to making an = emergency >>>> call, so this should alleviate most of your concerns John. >>>>>>>=20 >>>>>>> Cheers >>>>>>> James >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf = Of >>>> Richard Barnes [rbarnes@bbn.com] >>>>>>> Sent: Saturday, November 21, 2009 4:16 PM >>>>>>> To: John Lange >>>>>>> Cc: ecrit >>>>>>> Subject: Re: [Ecrit] Nomadic VOIP is dead >>>>>>>=20 >>>>>>> =46rom my perspective the critical point of the submission is = that >> VOIP >>>> is >>>>>>> declining, not growing. >>>>>>>=20 >>>>>>> I hope you mean that "*Nomadic* VoIP is declining", and even = then >>>> "Nomadic" understood in some peculiar sense that excludes = soft-phones. >>>> (I'm not familiar with CRTC's specific definition, but whatever it = is, >> it >>>> seems awkward from a technical perspective.) >>>>>>>=20 >>>>>>> And given that Ci2 does not support services such as Skype, it = fails >>>> to >>>>>>> service what is by far the largest, and still growing segment of = the >>>>>>> nomadic VOIP landscape. >>>>>>>=20 >>>>>>> That seems to me to argue for fixing the current incarnation of = Ci2 >>>> rather than doing nothing. >>>>>>>=20 >>>>>>> On the other hand, as I understand it, the major barrier to = support >>>> for VSPs like Skype is the establishment of trust relationships = with >> them. >>>> In which case, it should be straightforward to extend Ci2 to = support a >>>> limited number of these VSPs. As the report notes, simply bringing >> Skype >>>> into the fold would cover more than 90% of users, or around 720,000 >>>> subscribers. >>>>>>>=20 >>>>>>>=20 >>>>>>> To be clear, I support the goal of IP location determination for = the >>>>>>> purpose of providing enhanced 911 services to nomadic VOIP = users. I >>>> just >>>>>>> don't support the proposed Ci2 because, to a large extent, it = does >> not >>>>>>> meet that goal. >>>>>>>=20 >>>>>>> I certainly agree that there are better ways of doing it than >> current >>>> Ci2 -- mainly, just deploying the GEOPRIV Location Configuration >> Protocols >>>> (LCPs) -- but at the same time, Ci2 is more broadly useful than the >> report >>>> seems to imply. >>>>>>>=20 >>>>>>> --Richard >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Sun Nov 22 20:46:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B653A6992 for ; Sun, 22 Nov 2009 20:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAC+qR5yDYpd for ; Sun, 22 Nov 2009 20:46:07 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 9D1013A6991 for ; Sun, 22 Nov 2009 20:46:07 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:51880 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5347364AbZKWEqD convert rfc822-to-8bit (ORCPT ); Sun, 22 Nov 2009 22:46:03 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 22 Nov 2009 22:46:03 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 23 Nov 2009 12:45:59 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Mon, 23 Nov 2009 12:45:57 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acpr8oOuoWDgfXVBRb+HeDTnf2ztjgABBtaw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> In-Reply-To: <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:46:08 -0000 > The PSAP in Canada sees diddly squat in Ci2. The ILEC does it on its > behalf. The ILEC has contractual relationships with ISPs which shield > PSAPs from any requirement to engage into veracity assessment. Please > indicate when and where PSAPs actually engage into such an undertaking in > the context of Ci2 and how this differs with ECRIT. > > -=Francois=- I think you are seriously misrepresenting the picture here, in particular just where the trust relationship comes into play. If I understand your approach, you will provide location directly to an end-point over DHCP, have the Target constructs a PIDF-LO and send this information off to its VSP (no checking), then have the VPS direct this to the stage-1 routing proxy, because the location has been provided by the end-point you have the stage-1 routing proxy route the cal to the PSAP. Again no checking. This mean that the caller could quite literally be anywhere on Earth, but says he is in Toronto and the system will believe. Where is the veracity provided in your solution because I can't see it. Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy. Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 routing proxy uses IP address of the call to make a TRUSTED third-party request to the LIS for the caller's location. The routing proxy then includes the location in-band to the PSAP or whatever exists between the routing proxy and the PSAP. The trust in this case comes from the fact that there are only 5 stage-1 routing proxies and they are run by the existing 911 service providers. Further more the call needs to have originated from a local ISP or the third-party request will fail. Veracity not perfect, but certainly better than the other proposal. Cheers James From fmenard@xittelecom.com Sun Nov 22 21:01:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDA83A6827 for ; Sun, 22 Nov 2009 21:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31+Ix-LOXJp1 for ; Sun, 22 Nov 2009 21:01:43 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 6D8433A67D3 for ; Sun, 22 Nov 2009 21:01:43 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCR3T-0000cN-1K; Mon, 23 Nov 2009 00:01:39 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCR3S-0003Vl-K4; Mon, 23 Nov 2009 00:01:38 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> Date: Mon, 23 Nov 2009 00:01:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:01:44 -0000 > If I understand your approach, you will provide location directly to = an end-point over DHCP, have the Target constructs a PIDF-LO and send = this information off to its VSP (no checking), This means what you are saying is that end-points cannot be trusted to = report their locations? Is this a stated assumption in ECRIT that the end-points cannot be = trusted? You are saying that OBO should aways be mandatory? You are saying that veracity needs to be assessed while a 9-1-1 call is = being established? > then have the VPS direct this to the stage-1 routing proxy, because = the location has been provided by the end-point you have the stage-1 = routing proxy route the cal to the PSAP. Again no checking. This mean = that the caller could quite literally be anywhere on Earth, but says he = is in Toronto and the system will believe. If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he is = elsewhere on Earth, he will get a DHCP 99/123 with that information. How can he be elsewhere on earth and get DHCP 99/123 from Toronto? = Because he cached it? > Where is the veracity provided in your solution because I can't see = it. We are getting in the wild wet slide of 9-1-1 requires OBO... >=20 > Canadian i2, says, VSP will send 911 call to the stage-1 routing = proxy. Stage-1 routing proxy is only accessible by registered VSPs. = Stage-1 routing proxy uses IP address of the call to make a TRUSTED = third-party request to the LIS for the caller's location Error here... the IP address is the key. Will not work in many = scenarios. This also requires that IP address be tied to a CIVIC in = what is called the ILEC HOSTED LIS. This means that we have to = constantly upload the public IP addresses of all canadians just in case = they call 9-1-1. This is a big privacy problem. > . The routing proxy then includes the location in-band to the PSAP or = whatever exists between the routing proxy and the PSAP. ok > The trust in this case comes from the fact that there are only 5 = stage-1 routing proxies and they are run by the existing 911 service = providers. Do I trust the ILEC with the IP addresses of all my customers? > Further more the call needs to have originated from a local ISP or the = third-party request will fail. Why ? > Veracity not perfect, but certainly better than the other proposal. >=20 How about adding digital signatures to DHCP 99/123 constructs that can = flow through from the PSAP MSAG to the end-points and can get sent-back = to the PSAP for authentication assessments? I am thinking of MIME = digital signatures of PIDF-LO constructs that can be stored in the = memory of end-points and can be sent back to the PSAP via the = relationship between the ILEC and the PSAP. And there will be no need that the ILEC provides a Hosted LIS and knows = the identity of customers on the Internet that may never call 9-1-1 in = their life. This is way too much of a big brother database than what is the least = acceptable. It will be fought in court. We need to re-state the concept of ECRIT as not requiring OBO... but = trust between PSAPs and End-points. That requires digital signatures of PIDF-LOs. I've been saying so for the last couple of months to many people on the = ECRIT list. I think its time I do a real IETF draft on this. Any people think its a bad idea? -=3DFrancois=3D- > Cheers > James >=20 >=20 From James.Winterbottom@andrew.com Sun Nov 22 21:42:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C233A6827 for ; Sun, 22 Nov 2009 21:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B9ANVIkbTD1 for ; Sun, 22 Nov 2009 21:42:02 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 09C823A67A7 for ; Sun, 22 Nov 2009 21:42:02 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:38164 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S73027AbZKWFl6 (ORCPT ); Sun, 22 Nov 2009 23:41:58 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 22 Nov 2009 23:41:57 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 23 Nov 2009 13:41:54 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Mon, 23 Nov 2009 13:41:52 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acpr+iZTBTK+SZDJQgGEyK1B0H7qxgAAmdOA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88A87ESISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:42:15 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88A87ESISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline. > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Monday, 23 November 2009 4:02 PM > To: Winterbottom, James > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > > If I understand your approach, you will provide location directly to an > end-point over DHCP, have the Target constructs a PIDF-LO and send this > information off to its VSP (no checking), > > This means what you are saying is that end-points cannot be trusted to > report their locations? > > Is this a stated assumption in ECRIT that the end-points cannot be > trusted? > > You are saying that OBO should aways be mandatory? [AJW] I am saying that I have spoken to quite a number (more than 4) regula= tors around the world and they will not trust location coming from end-poin= ts that cannot be verified by some other means. Martin Thomson, I and a few= others have been trying to get a means for having literal location bound t= o a specific end-point but so far this has gotten little traction. So yes, = I am saying that the only option right now is a trusted third-party request= . > You are saying that veracity needs to be assessed while a 9-1-1 call is > being established? [AJW] Trusted third-party also eliminates the need to do a veracity check a= t call time. So I only see this as another advantage. > > > then have the VPS direct this to the stage-1 routing proxy, because the > location has been provided by the end-point you have the stage-1 routing > proxy route the cal to the PSAP. Again no checking. This mean that the > caller could quite literally be anywhere on Earth, but says he is in > Toronto and the system will believe. > > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he is > elsewhere on Earth, he will get a DHCP 99/123 with that information. [AJW] Absolutely wrong. He can have a softphone and be where ever he wants = to be and this is precisely the problem. You are not providing a means to s= top this kind of malicious calling, or any means to trace the culprit. The = solution does not provide any bar to entry for the would-be attacker and do= esn't meet the requirements as I understand them to have been laid out. Tha= t is: Location must be attributable and verifiable as belonging to a specific end= -point at the time a specific call is made. Ci2, as currently proposed does= do this. > How can he be elsewhere on earth and get DHCP 99/123 from Toronto? > Because he cached it? > > > Where is the veracity provided in your solution because I can't see it. > > We are getting in the wild wet slide of 9-1-1 requires OBO... > > > > Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy. > Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 > routing proxy uses IP address of the call to make a TRUSTED third-party > request to the LIS for the caller's location > > Error here... the IP address is the key. Will not work in many scenarios= . > This also requires that IP address be tied to a CIVIC in what is called > the ILEC HOSTED LIS. This means that we have to constantly upload the > public IP addresses of all canadians just in case they call 9-1-1. This i= s > a big privacy problem. > > > . The routing proxy then includes the location in-band to the PSAP or > whatever exists between the routing proxy and the PSAP. > > ok > > > The trust in this case comes from the fact that there are only 5 stage-= 1 > routing proxies and they are run by the existing 911 service providers. > > Do I trust the ILEC with the IP addresses of all my customers? > > > Further more the call needs to have originated from a local ISP or the > third-party request will fail. > > Why ? [AJW] because if it does not, then the stage-1 routing proxy will fail to r= esolve to a known LIS and request will get default treatment. This sort of = call can then be investigated. > > > Veracity not perfect, but certainly better than the other proposal. > > > > How about adding digital signatures to DHCP 99/123 constructs that can > flow through from the PSAP MSAG to the end-points and can get sent-back t= o > the PSAP for authentication assessments? I am thinking of MIME digital > signatures of PIDF-LO constructs that can be stored in the memory of end- > points and can be sent back to the PSAP via the relationship between the > ILEC and the PSAP. > [AJW] As I have stated many times before, simply signing the location isn't= good enough. You need to bind it to the device making the call, and you ne= ed to have a way of saying that the binding was still valid when the call w= as made. Quite frankly I don't believe that this can be done in any meaning= ful way using DHCP, and to the best of my knowledge I haven't seen any prop= osal (even draft ones) that show how it can be done. My question to you, is= what is your aversion to doing this at the application layer and avoid hav= ing to change all the home routers in the path? > And there will be no need that the ILEC provides a Hosted LIS and knows > the identity of customers on the Internet that may never call 9-1-1 in > their life. [AJW] I am not a big fan of the ILEC hosted solution. As I understand it, i= t was in fact the ISPs that asked for such an option to exist. Quite frankl= y from my assessments any solution using this approach will require as much= equipment in their networks as putting a LIS in will, so they may as well = put the LIS in. > > This is way too much of a big brother database than what is the least > acceptable. > > It will be fought in court. > > We need to re-state the concept of ECRIT as not requiring OBO... but trus= t > between PSAPs and End-points. [AJW] I disagree. I actually think that the right place to put the trust is= between the ISP and the PSAP, and separate agreement exists between the en= d-point and the ISP. The ISP is then responsible for who he lets on to his = network, and what they do when they are there. > > That requires digital signatures of PIDF-LOs. > > I've been saying so for the last couple of months to many people on the > ECRIT list. I think its time I do a real IETF draft on this. [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. Che= ck out http://tools.ietf.org/html/draft-thomson-geopriv-location-dependabil= ity-04 it has been around for a very long time. I will restress my position however, that I think ECRIT Direct and Trusted = third-party requests is the right approach for emergency calling. > > Any people think its a bad idea? > > -=3DFrancois=3D- > > > Cheers > > James > > > > > --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88A87ESISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline.

 

> -----Original Message-----

> From: Francois D. Menard [mailto:fmenard@xittelecom.com]

> Sent: Monday, 23 November 200= 9 4:02 PM

> To: Winterbottom, James

> Cc: ecrit

> Subject: Re: [Ecrit] Nomadic = VOIP is dead

>

> > If I understand your approach, you will provide location directly to an

> end-point over DHCP, have the Target constructs a PIDF-LO and = send this

> information off to its VSP (no checking),

>

> This means what you are saying is that end-points cannot be trusted to

> report their locations?

>

> Is this a stated assumption in ECR= IT that the end-points cannot be

> trusted?

>

> You are saying that OBO should aways be mandatory?<= /span>

<= span style=3D'font-size:10.0pt;color:black'> 

> You are saying that veracity needs to be assessed while a 9-1-= 1 call is

> being established?

<= span style=3D'font-size:10.0pt;color:black'> 

<= span style=3D'font-size:10.0pt;color:black'> 

>

> > then have the VPS direct this to the stage-1 routing prox= y, because the

> location has been provided by the end-point you have the stage= -1 routing

> proxy route the cal to the PSAP. Again no checking. This mean = that the

> caller could quite literally be anywhere on Earth, but says he= is in

> Toronto and the system will believe.

>

> If he is in Toron= to, his ATA will get a DHCP 99/123 with that. If he is

> elsewhere on Earth, he will get a DHCP 99/123 with that information.

<= span style=3D'font-size:10.0pt;color:black'> 

<= span style=3D'font-size:10.0pt;color:black'> 

<= span style=3D'font-size:10.0pt;color:black'> 

> How can he be elsewhere on earth and get  DHCP 99/123 fro= m Toronto?

> Because he cached it?

>

> > Where is the veracity provided in your solution because I can't see it.

>

> We are getting in the wild wet slide of 9-1-1 requires OBO...<= /span>

> >

> > Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy.

> Stage-1 routing proxy is only accessible by registered VSPs. Stage-1

> routing proxy uses IP address of the call to make a TRUSTED third-party

> request to the LIS for the caller's location

>

> Error here... the IP address is the key.  Will not work i= n many scenarios.

> This also requires that IP address be tied to a CIVIC in what = is called

> the ILEC HOSTED LIS.  This means that we have to constant= ly upload the

> public IP addresses of all canadians just in case they call 9-= 1-1. This is

> a big privacy problem.

>

> > . The routing proxy then includes the location in-band to= the PSAP or

> whatever exists between the routing proxy and the PSAP.=

>

> ok

>

> > The trust in this case comes from the fact that there are only 5 stage-1

> routing proxies and they are run by the existing 911 service providers.

>

> Do I trust the ILEC with the IP addresses of all my customers?=

>

> > Further more the call needs to have originated from a loc= al ISP or the

> third-party request will fail.

>

> Why ?

<= span style=3D'font-size:10.0pt;color:black'> 

>

> > Veracity not perfect, but certainly better than the other proposal.

> >

>

> How about adding digital signatures to DHCP 99/123 constructs = that can

> flow through from the PSAP MSAG to the end-points and can get sent-back to

> the PSAP for authentication assessments?  I am thinking o= f MIME digital

> signatures of PIDF-LO constructs that can be stored in the mem= ory of end-

> points and can be sent back to the PSAP via the relationship between the

> ILEC and the PSAP.

>

<= span style=3D'font-size:10.0pt;color:black'> 

> And there will be no need that the ILEC provides a Hosted LIS = and knows

> the identity of customers on the Internet that may never call 9-1-1 in

> their life.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> This is way too much of a big brother database than what is th= e least

> acceptable.

>

> It will be fought in court.

>

> We need to re-state the concept of ECRIT as not requiring OBO... but trust

> between PSAPs and End-points.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> That requires digital signatures of PIDF-LOs.

>

> I've been saying so for the last couple of months to many peop= le on the

> ECRIT list. = I think its time I do a real IETF draft on this.

http://tools.ietf.org/html/draft-thomson-geopriv-location-dependab= ility-04 it has been around for a very long time.

ECRIT Direct and Trusted third-party requests is the right approach for emergency calling.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> Any people think its a bad idea?

>

> -=3DFrancois=3D-

>

> > Cheers

> > James

> >

> >

>

 

--_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88A87ESISPE7MB1co_-- From mlinsner@cisco.com Mon Nov 23 05:19:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2140D28C132 for ; Mon, 23 Nov 2009 05:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-1.905, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyx58G9QBzxO for ; Mon, 23 Nov 2009 05:18:58 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com (xmb-rtp-205.cisco.com [64.102.31.59]) by core3.amsl.com (Postfix) with ESMTP id ACE7628C11B for ; Mon, 23 Nov 2009 05:18:58 -0800 (PST) Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 08:18:54 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Nov 2009 08:18:53 -0500 From: Marc Linsner To: ecrit Message-ID: Thread-Topic: Trustworthy Location Information Thread-Index: AcpsP4CdasyI84f3gkWaAF7rVjugsw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341809134_105481" X-OriginalArrivalTime: 23 Nov 2009 13:18:54.0767 (UTC) FILETIME=[81AABBF0:01CA6C3F] Subject: [Ecrit] Trustworthy Location Information X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:19:00 -0000 > 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. --B_3341809134_105481 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Those pushing for complex mechanisms (=8Ctrusted third party=B9) under the guis= e of not trusting location from an end-point/end-user are simply attempting t= o protect a particular business model. -Marc- --B_3341809134_105481 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Trustworthy Location Information Those pushing for complex mechanisms (‘trusted third party’) u= nder the guise of not trusting location from an end-point/end-user are simpl= y attempting to protect a particular business model.

-Marc- --B_3341809134_105481-- From br@brianrosen.net Mon Nov 23 05:54:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02A53A68B0 for ; Mon, 23 Nov 2009 05:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uwFzRG7sBad for ; Mon, 23 Nov 2009 05:54:29 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8DD523A6A30 for ; Mon, 23 Nov 2009 05:54:29 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NCZMr-000318-Nz; Mon, 23 Nov 2009 07:54:13 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 23 Nov 2009 08:54:16 -0500 From: Brian Rosen To: James Winterbottom , "Francois D. Menard" Message-ID: Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: Acpr+iZTBTK+SZDJQgGEyK1B0H7qxgAAmdOAABH5GRw= In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341811260_129298956" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:54:41 -0000 > 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. --B_3341811260_129298956 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable That=B9s where we started with the U.S. Folks. We educated them. They are now comfortable, although they would like a signature on the location (integrity protection). Not foolproof. No system is. If you just go ask, you get fear, uncertainty, and doubt. If you educate, then most people come around to a reasonable point of view. Ci2 cant work in next generation systems. It=B9s marginally better than the current U.S. i2 system because it does supply an actual location instead of a user reported location. You can=B9t extend it to next generation. Enterprise is merely one example, there are many more. Anything using an IP address as an identifier is not accurate, and not reliable. It can be more accurate and more reliable than some mechanisms, but it=B9s fairly easily defeatable by any attacker with a modicum of knowledge. An attack with a false location requires someone to code: devices would be built to do the right thing. If you can code, you can fin= d a relay/zombie/whatever to hide your IP address and present a different location. If you are telling regulators that OBO substantially increases location veracity, you are misleading them. It improves it only marginally= , and only works for a subset of what we want it to work for. Brian On 11/23/09 12:41 AM, "James Winterbottom" wrote: > Inline. > =20 >> > -----Original Message----- >> > From: Francois D. Menard [mailto:fmenard@xittelecom.com] >> > Sent: Monday, 23 November 2009 4:02 PM >> > To: Winterbottom, James >> > Cc: ecrit >> > Subject: Re: [Ecrit] Nomadic VOIP is dead >> >=20 >>> > > If I understand your approach, you will provide location directly t= o an >> > end-point over DHCP, have the Target constructs a PIDF-LO and send thi= s >> > information off to its VSP (no checking), >> >=20 >> > This means what you are saying is that end-points cannot be trusted to >> > report their locations? >> >=20 >> > Is this a stated assumption in ECRIT that the end-points cannot be >> > trusted? >> >=20 >> > You are saying that OBO should aways be mandatory? > [AJW] I am saying that I have spoken to quite a number (more than 4) > regulators around the world and they will not trust location coming from > end-points that cannot be verified by some other means. Martin Thomson, I= and > a few others have been trying to get a means for having literal location = bound > to a specific end-point but so far this has gotten little traction. So ye= s, I > am saying that the only option right now is a trusted third-party request= . > =20 >> > You are saying that veracity needs to be assessed while a 9-1-1 call i= s >> > being established? > [AJW] Trusted third-party also eliminates the need to do a veracity check= at > call time. So I only see this as another advantage. > =20 > =20 >> >=20 >>> > > then have the VPS direct this to the stage-1 routing proxy, because= the >> > location has been provided by the end-point you have the stage-1 routi= ng >> > proxy route the cal to the PSAP. Again no checking. This mean that the >> > caller could quite literally be anywhere on Earth, but says he is in >> > Toronto and the system will believe. >> >=20 >> > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he i= s >> > elsewhere on Earth, he will get a DHCP 99/123 with that information. > =20 > [AJW] Absolutely wrong. He can have a softphone and be where ever he want= s to > be and this is precisely the problem. You are not providing a means to st= op > this kind of malicious calling, or any means to trace the culprit. The > solution does not provide any bar to entry for the would-be attacker and > doesn=B9t meet the requirements as I understand them to have been laid out.= That > is: > Location must be attributable and verifiable as belonging to a specific > end-point at the time a specific call is made. Ci2, as currently proposed= does > do this.=20 > =20 > =20 > =20 >> > How can he be elsewhere on earth and get DHCP 99/123 from Toronto? >> > Because he cached it? >> >=20 >>> > > Where is the veracity provided in your solution because I can't see= it. >> >=20 >> > We are getting in the wild wet slide of 9-1-1 requires OBO... >>> > > >>> > > Canadian i2, says, VSP will send 911 call to the stage-1 routing pr= oxy. >> > Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 >> > routing proxy uses IP address of the call to make a TRUSTED third-part= y >> > request to the LIS for the caller's location >> >=20 >> > Error here... the IP address is the key. Will not work in many scenar= ios. >> > This also requires that IP address be tied to a CIVIC in what is calle= d >> > the ILEC HOSTED LIS. This means that we have to constantly upload the >> > public IP addresses of all canadians just in case they call 9-1-1. Thi= s is >> > a big privacy problem. >> >=20 >>> > > . The routing proxy then includes the location in-band to the PSAP = or >> > whatever exists between the routing proxy and the PSAP. >> >=20 >> > ok >> >=20 >>> > > The trust in this case comes from the fact that there are only 5 st= age-1 >> > routing proxies and they are run by the existing 911 service providers= . >> >=20 >> > Do I trust the ILEC with the IP addresses of all my customers? >> >=20 >>> > > Further more the call needs to have originated from a local ISP or = the >> > third-party request will fail. >> >=20 >> > Why ? > [AJW] because if it does not, then the stage-1 routing proxy will fail to > resolve to a known LIS and request will get default treatment. This sort = of > call can then be investigated. > =20 >> >=20 >>> > > Veracity not perfect, but certainly better than the other proposal. >>> > > >> >=20 >> > How about adding digital signatures to DHCP 99/123 constructs that can >> > flow through from the PSAP MSAG to the end-points and can get sent-bac= k to >> > the PSAP for authentication assessments? I am thinking of MIME digita= l >> > signatures of PIDF-LO constructs that can be stored in the memory of e= nd- >> > points and can be sent back to the PSAP via the relationship between t= he >> > ILEC and the PSAP. >> >=20 > [AJW] As I have stated many times before, simply signing the location isn= =B9t > good enough. You need to bind it to the device making the call, and you n= eed > to have a way of saying that the binding was still valid when the call wa= s > made. Quite frankly I don=B9t believe that this can be done in any meaningf= ul > way using DHCP, and to the best of my knowledge I haven=B9t seen any propos= al > (even draft ones) that show how it can be done. My question to you, is wh= at is > your aversion to doing this at the application layer and avoid having to > change all the home routers in the path? > =20 >> > And there will be no need that the ILEC provides a Hosted LIS and know= s >> > the identity of customers on the Internet that may never call 9-1-1 in >> > their life. > [AJW] I am not a big fan of the ILEC hosted solution. As I understand it,= it > was in fact the ISPs that asked for such an option to exist. Quite frankl= y > from my assessments any solution using this approach will require as much > equipment in their networks as putting a LIS in will, so they may as well= put > the LIS in. > =20 >> >=20 >> > This is way too much of a big brother database than what is the least >> > acceptable. >> >=20 >> > It will be fought in court. >> >=20 >> > We need to re-state the concept of ECRIT as not requiring OBO... but t= rust >> > between PSAPs and End-points. > [AJW] I disagree. I actually think that the right place to put the trust = is > between the ISP and the PSAP, and separate agreement exists between the > end-point and the ISP. The ISP is then responsible for who he lets on to = his > network, and what they do when they are there. > =20 >> >=20 >> > That requires digital signatures of PIDF-LOs. >> >=20 >> > I've been saying so for the last couple of months to many people on th= e >> > ECRIT list. I think its time I do a real IETF draft on this. > [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. C= heck > out http://tools.ietf.org/html/draft-thomson-geopriv-location-dependabili= ty-04 > it has been around for a very long time. > I will restress my position however, that I think ECRIT Direct and Truste= d > third-party requests is the right approach for emergency calling. > =20 >> >=20 >> > Any people think its a bad idea? >> >=20 >> > -=3DFrancois=3D- >> >=20 >>> > > Cheers >>> > > James >>> > > >>> > > >> >=20 > =20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --B_3341811260_129298956 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] Nomadic VOIP is dead That’s where we started with the U.S. Folks.  We educated them.=  They are now comfortable, although they would like a signature on the= location (integrity protection).  Not foolproof.  No system is. <= BR>
If you just go ask, you get fear, uncertainty, and doubt.  If you educ= ate, then most people come around to a reasonable point of view.

Ci2 cant work in next generation systems.  It’s marginally bette= r than the current U.S. i2 system because it does supply an actual location = instead of a user reported location.  You can’t extend it to next= generation.   Enterprise is merely one example, there are many mo= re.

Anything using an IP address as an identifier is not accurate, and not reli= able.  It can be more accurate and more reliable than some mechanisms, = but it’s fairly easily defeatable by any attacker with a modicum of kn= owledge.   An attack with a false location requires someone to cod= e: devices would be built to do the right thing.  If you can code, you = can find a relay/zombie/whatever to hide your IP address and present a diffe= rent location.  If you are telling regulators that OBO substantially in= creases location veracity, you are misleading them.  It improves it onl= y marginally, and only works for a subset of what we want it to work for. &n= bsp;

Brian


On 11/23/09 12:41 AM, "James Winterbottom" <James.Winterbottom@andrew.com> wrote:

Inline.
 
> -----Original Message-----
> From: Francois D. Menard [mail= to:fmenard@xittelecom.com]
> Sent: Monday, 23 November 2009 4:02 PM
> To: Winterbottom, James
> Cc: ecrit
> Subject: Re: [Ecrit] Nomadic VOIP is dead
>
> > If I understand your approach, you will provide location directly= to an
> end-point over DHCP, have the Target constructs a PIDF-LO and send thi= s
> information off to its VSP (no checking),
>
> This means what you are saying is that end-points cannot be trusted to=
> report their locations?
>
> Is this a stated assumption in ECRIT that the end-points cannot be
> trusted?
>
> You are saying that OBO should aways be mandatory?
[AJW] I am saying that I have spoken to quite a number (more than 4) reg= ulators around the world and they will not trust location coming from end-po= ints that cannot be verified by some other means. Martin Thomson, I and a fe= w others have been trying to get a means for having literal location bound t= o a specific end-point but so far this has gotten little traction. So yes, I= am saying that the only option right now is a trusted third-party request.<= BR>
> You are saying that veracity needs to be assessed while a 9-1-1 call i= s
> being established?
[AJW] Trusted third-party also eliminates the need to do a veracity chec= k at call time. So I only see this as another advantage.
 
>
> > then have the VPS direct this to the stage-1 routing proxy, becau= se the
> location has been provided by the end-point you have the stage-1 routi= ng
> proxy route the cal to the PSAP. Again no checking. This mean that the=
> caller could quite literally be anywhere on Earth, but says he is in > Toronto and the system will believe.
>
> If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he i= s
> elsewhere on Earth, he will get a DHCP 99/123 with that information.  
[AJW] Absolutely wrong. He can have a softphone and be where ever he wan= ts to be and this is precisely the problem. You are not providing a means to= stop this kind of malicious calling, or any means to trace the culprit. The= solution does not provide any bar to entry for the would-be attacker and do= esn’t meet the requirements as I understand them to have been laid out= . That is:
Location must be attributable and verifiable as belonging to a specific end= -point at the time a specific call is made. Ci2, as currently proposed does = do this.

<keep going>
 
> How can he be elsewhere on earth and get  DHCP 99/123 from Toront= o?
> Because he cached it?
>
> > Where is the veracity provided in your solution because I can't s= ee it.
>
> We are getting in the wild wet slide of 9-1-1 requires OBO...
> >
> > Canadian i2, says, VSP will send 911 call to the stage-1 routing = proxy.
> Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 > routing proxy uses IP address of the call to make a TRUSTED third-part= y
> request to the LIS for the caller's location
>
> Error here... the IP address is the key.  Will not work in many s= cenarios.
> This also requires that IP address be tied to a CIVIC in what is calle= d
> the ILEC HOSTED LIS.  This means that we have to constantly uploa= d the
> public IP addresses of all canadians just in case they call 9-1-1. Thi= s is
> a big privacy problem.
>
> > . The routing proxy then includes the location in-band to the PSA= P or
> whatever exists between the routing proxy and the PSAP.
>
> ok
>
> > The trust in this case comes from the fact that there are only 5 = stage-1
> routing proxies and they are run by the existing 911 service providers= .
>
> Do I trust the ILEC with the IP addresses of all my customers?
>
> > Further more the call needs to have originated from a local ISP o= r the
> third-party request will fail.
>
> Why ?
[AJW] because if it does not, then the stage-1 routing proxy will fail t= o resolve to a known LIS and request will get default treatment. This sort o= f call can then be investigated.
>
> > Veracity not perfect, but certainly better than the other proposa= l.
> >
>
> How about adding digital signatures to DHCP 99/123 constructs that can=
> flow through from the PSAP MSAG to the end-points and can get sent-bac= k to
> the PSAP for authentication assessments?  I am thinking of MIME d= igital
> signatures of PIDF-LO constructs that can be stored in the memory of e= nd-
> points and can be sent back to the PSAP via the relationship between t= he
> ILEC and the PSAP.
>
[AJW] As I have stated many times before, simply signing the location is= n’t good enough. You need to bind it to the device making the call, an= d you need to have a way of saying that the binding was still valid when the= call was made. Quite frankly I don’t believe that this can be done in= any meaningful way using DHCP, and to the best of my knowledge I haven̵= 7;t seen any proposal (even draft ones) that show how it can be done. My que= stion to you, is what is your aversion to doing this at the application laye= r and avoid having to change all the home routers in the path?
> And there will be no need that the ILEC provides a Hosted LIS and know= s
> the identity of customers on the Internet that may never call 9-1-1 in=
> their life.
[AJW] I am not a big fan of the ILEC hosted solution. As I understand it= , it was in fact the ISPs that asked for such an option to exist. Quite fran= kly from my assessments any solution using this approach will require as muc= h equipment in their networks as putting a LIS in will, so they may as well = put the LIS in.
>
> This is way too much of a big brother database than what is the least<= BR> > acceptable.
>
> It will be fought in court.
>
> We need to re-state the concept of ECRIT as not requiring OBO... but t= rust
> between PSAPs and End-points.
[AJW] I disagree. I actually think that the right place to put the trust= is between the ISP and the PSAP, and separate agreement exists between the = end-point and the ISP. The ISP is then responsible for who he lets on to his= network, and what they do when they are there.
>
> That requires digital signatures of PIDF-LOs.
>
> I've been saying so for the last couple of months to many people on th= e
> ECRIT list.  I think its time I do a real IETF draft on this.
[AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. = Check out http://tools.ietf.org/html/draft-thomson-geopriv-location= -dependability-04 it has been around for a very long time.
I will restress my position however, that I think ECRIT Direct and Trusted = third-party requests is the right approach for emergency calling.
>
> Any people think its a bad idea?
>
> -=3DFrancois=3D-
>
> > Cheers
> > James
> >
> >
>
 

___________= ____________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit
--B_3341811260_129298956-- From john@johnlange.ca Mon Nov 23 08:13:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4DF3A67EA for ; Mon, 23 Nov 2009 08:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rFNYWBA9KWM for ; Mon, 23 Nov 2009 08:13:08 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id F19883A67A2 for ; Mon, 23 Nov 2009 08:13:07 -0800 (PST) Received: by qyk29 with SMTP id 29so2636115qyk.32 for ; Mon, 23 Nov 2009 08:12:58 -0800 (PST) Received: by 10.224.55.148 with SMTP id u20mr2553351qag.191.1258992778143; Mon, 23 Nov 2009 08:12:58 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 6sm12640972qwk.11.2009.11.23.08.12.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 08:12:57 -0800 (PST) From: John Lange To: Brian Rosen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 10:12:49 -0600 Message-Id: <1258992769.5861.112.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:13:09 -0000 When I posted the link to that report I didn't really expect it to generate so much interest and list traffic ;) Regardless of the technical discussion that has erupted, the point is simply that the cost of any solution, Ci2 or otherwise is too high to justify implementation considering the limited number of users who will benefit at this time and the significant number of users that will be left out (Skype etc). Even the argument that Ci2 should be implemented because it's a worthwhile stepping stone to next-gen systems is misleading. While it is true that there are some functional components which are similar (the LIS for example), the architecture itself is proprietary and therefore there would likely be very little of Ci2 which would not have to undergo significant changes or outright replacement should there be a move to something that looks more standards based. Even worse, once Ci2 is in place (and all that money has been spent) there will be no motivation to repeat the process and implement a proper next-gen (Ci3) solution so we'll be stuck with it. Much better to wait for something more solid to develop from the IETF while we wait to see how nomadic VOIP evolves. My crystal ball tells me that the future is mobile and that mobile data-only devices with softphones will proliferate. This will further diminish the nomadic VOIP market share. (and this is a bit off topic but my hope would be that the systems in place for cellphone/wireless 911 location can be leveraged for these devices as well. If you dial 911, the device will "intercept" the call and send you down an emergency call path rather than sending you to your softphone's VSP). -- John Lange http://www.johnlange.ca From bernard_aboba@hotmail.com Mon Nov 23 08:40:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24333A6926 for ; Mon, 23 Nov 2009 08:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qPFJY-qfBdF for ; Mon, 23 Nov 2009 08:40:05 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by core3.amsl.com (Postfix) with ESMTP id ADA773A67A2 for ; Mon, 23 Nov 2009 08:40:05 -0800 (PST) Received: from BLU137-W12 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 08:40:01 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_26421f62-3cbe-4ba4-be28-8199ee88d166_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 23 Nov 2009 08:40:01 -0800 Importance: Normal In-Reply-To: <1258992769.5861.112.camel@linux-k6vx.site> References: , <1258992769.5861.112.camel@linux-k6vx.site> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 16:40:01.0582 (UTC) FILETIME=[9A0C94E0:01CA6C5B] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:40:06 -0000 --_26421f62-3cbe-4ba4-be28-8199ee88d166_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > My crystal ball tells me that the future is mobile and that mobile > data-only devices with softphones will proliferate. This will further > diminish the nomadic VOIP market share. I agree that "mobile" is likely to rapidly displace nomadic. However=2C t= he move to "data only" has ocurred much slower than we had originally thoug= ht. For example=2C while the original designs for WiMAX were data-only=2C = it quickly became clear that building out a nationwide greenfield 4G data n= etwork was so expensive that it would be very difficult to provide coverage= competitive with existing 2 and 3G services. =20 Even where it has been possible to provide substantial coverage (such as mu= nicipal WiFi rollouts)=2C the level of interest in "data only" networks ha= s been much lower than originally projected=2C limited to only a few percen= t of the population=2C which was insufficient to get to make the services s= elf-sustaining. =20 As a result=2C recent designs have moved toward technology overlays=2C such= as overlays of 4G technology on top of existing 2G networks. In such desi= gns=2C voice traffic is typically handled with conventional technology rath= er than VOIP. =20 = --_26421f62-3cbe-4ba4-be28-8199ee88d166_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B My crystal ball tells me that the future is mobile and that mobile>=3B data-only devices with softphones will proliferate. This will furt= her
>=3B diminish the nomadic VOIP market share.

I agree that "= mobile" is likely to rapidly displace nomadic. =3B =3B However=2C t= he move to "data only" has ocurred much slower than we had originally thoug= ht. =3B For example=2C while the original designs for WiMAX were data-o= nly=2C it quickly became clear that building out a nationwide greenfield 4G= data network was so expensive that it would be very difficult to provide c= overage competitive with existing 2 and 3G services. =3B

Even w= here it has been possible to provide substantial coverage (such as municipa= l WiFi rollouts)=2C the =3B level of interest in "data only" networks h= as been much lower than originally projected=2C limited to only a few perce= nt of the population=2C which was insufficient to get to make the services = self-sustaining. =3B

As a result=2C recent designs have moved t= oward technology overlays=2C such as overlays of 4G technology on top of ex= isting 2G networks. =3B In such designs=2C voice traffic is typically h= andled with conventional technology rather than VOIP. =3B
= = --_26421f62-3cbe-4ba4-be28-8199ee88d166_-- From john@johnlange.ca Mon Nov 23 10:09:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721933A6969 for ; Mon, 23 Nov 2009 10:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxGzbgdV02Yi for ; Mon, 23 Nov 2009 10:09:38 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 860123A67D6 for ; Mon, 23 Nov 2009 10:09:38 -0800 (PST) Received: by qyk29 with SMTP id 29so2698587qyk.32 for ; Mon, 23 Nov 2009 10:09:31 -0800 (PST) Received: by 10.224.60.3 with SMTP id n3mr2624253qah.245.1258999771673; Mon, 23 Nov 2009 10:09:31 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 6sm12905485qwk.1.2009.11.23.10.09.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 10:09:30 -0800 (PST) From: John Lange To: Bernard Aboba In-Reply-To: References: ,<1258992769.5861.112.camel@linux-k6vx.site> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 12:09:24 -0600 Message-Id: <1258999764.5861.152.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:09:39 -0000 On Mon, 2009-11-23 at 08:40 -0800, Bernard Aboba wrote: > > My crystal ball tells me that the future is mobile and that mobile > > data-only devices with softphones will proliferate. This will > further > > diminish the nomadic VOIP market share. > > I agree that "mobile" is likely to rapidly displace nomadic. > However, the move to "data only" has ocurred much slower than we had > originally thought. I submit that the relatively slow uptake of data-only is due largely to the fact that the providers are clinging to voice-based business models. Devices which support VOIP over data are still rare. For example, the iPhone technically can do it but the VOIP over data applications are blocked by Apple. With Andriod finally showing real signs life on a multitude of hardware platforms, widespread use of VOIP on data-only mobile devices is inevitable. That isn't to imply that there aren't still roadblocks. For example, here in Canada, the growth of mobile data is severely restricted by the lack of competition leading to mediocre selection of devices (we just got the iPhone about a year ago) and very high data prices. -- John Lange http://www.johnlange.ca From fmenard@xittelecom.com Mon Nov 23 10:47:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88933A68AF for ; Mon, 23 Nov 2009 10:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNWR6YErlnqB for ; Mon, 23 Nov 2009 10:47:16 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id D16D43A6819 for ; Mon, 23 Nov 2009 10:47:16 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCdwM-0007hU-Gw; Mon, 23 Nov 2009 13:47:10 -0500 Received: from [205.151.16.4] (helo=[192.168.2.64]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1NCdwM-00038G-BF; Mon, 23 Nov 2009 13:47:10 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Francois Menard In-Reply-To: Date: Mon, 23 Nov 2009 13:47:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Rosen X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:47:18 -0000 > Anything using an IP address as an identifier is not accurate, and not = reliable. It can be more accurate and more reliable than some = mechanisms, but it=92s fairly easily defeatable by any attacker with a = modicum of knowledge. An attack with a false location requires someone = to code: devices would be built to do the right thing. If you can code, = you can find a relay/zombie/whatever to hide your IP address and present = a different location. If you are telling regulators that OBO = substantially increases location veracity, you are misleading them. It = improves it only marginally, and only works for a subset of what we want = it to work for. =20 >=20 Does ECRIT support OBO? f. From bernard_aboba@hotmail.com Mon Nov 23 11:01:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1620F3A69CC for ; Mon, 23 Nov 2009 11:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acz9jmNcnZ9q for ; Mon, 23 Nov 2009 11:00:59 -0800 (PST) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by core3.amsl.com (Postfix) with ESMTP id 292703A6979 for ; Mon, 23 Nov 2009 11:00:59 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.9]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:00:55 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'John Lange'" References: , <1258992769.5861.112.camel@linux-k6vx.site> <1258999764.5861.152.camel@linux-k6vx.site> In-Reply-To: <1258999764.5861.152.camel@linux-k6vx.site> Date: Mon, 23 Nov 2009 11:01:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpsaBp4TwfRzzftQwSXfQ+Vv7CdjgAAkgoQ Content-Language: en-us X-OriginalArrivalTime: 23 Nov 2009 19:00:55.0135 (UTC) FILETIME=[48C266F0:01CA6C6F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:01:00 -0000 >I submit that the relatively slow uptake of data-only is due largely to >the fact that the providers are clinging to voice-based business = models.... >widespread use of VOIP on data-only mobile devices is inevitable. While I'd agree that it's likely to happen at some point, there is no = "data only" wireless technology on the horizon that seems likely to = result in widespread deployment of wireless VOIP in the near future.=20 Today's fragmented hotspot deployments with their web portal-based = access model are not exactly "VOIP-friendly". =20 Even greenfield wireless providers with no existing voice-based business = model have failed in their introduction of "data-only" plans. Typically = this is due to unfavorable speed/power and cost/coverage tradeoffs. = This problem occurs because next generation wireless data technologies = have greatly increased power consumption and much reduced coverage = radius compared with existing technologies. Capital and maintenance = costs rise with the inverse square of the coverage ratio. So reducing = the coverage radius by 50 percent increases cost by 400 percent. = Similarly, power consumption increases more than linearly with speed. = These basic mathematical principles have had devastating effects on the = prospects of "data only" wireless networks, whether they be municipal = networks unable to provide acceptable coverage with 802.11 APs running = at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz WiMAX = pilots that have only demonstrated a 1-2 mile coverage radius. The = bottom line is that the 2.4/2.5 or 5 Ghz spectrum bands are not = hospitable to construction of viable "data only" networks. =20 It's possible that allocation of spectrum with longer propagation = characteristics (e.g. White Spaces) may help in overcoming coverage = obstacles, but that is years away. =20 >That isn't to imply that there aren't still roadblocks. For example, >here in Canada, the growth of mobile data is severely restricted by the >lack of competition leading to mediocre selection of devices (we just >got the iPhone about a year ago) and very high data prices. Here in the U.S. we have seen "data only" wireless networks offering = access for as little as $20/month fail to sign up even 5 percent of the = population. =20 From rbarnes@bbn.com Mon Nov 23 11:12:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DBE3A6A7B for ; Mon, 23 Nov 2009 11:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFRsT9qaAQE2 for ; Mon, 23 Nov 2009 11:12:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4BD0C3A6A5F for ; Mon, 23 Nov 2009 11:12:42 -0800 (PST) Received: from ros-dhcp192-1-51-18.bbn.com ([192.1.51.18]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NCeKu-0003da-Bc; Mon, 23 Nov 2009 14:12:33 -0500 Message-Id: From: Richard Barnes To: Francois Menard In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Nov 2009 14:12:32 -0500 References: X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:12:50 -0000 Sure it does, especially in the secondary/verification context that =20 James describes. It just requires the access network to *also* =20 provide location to the end host so that it (or the VSP) has some idea =20= what to do with the call. E.g., whether to send it to the Canadian =20 Stage 1 proxy or the Albanian one. --Richard On Nov 23, 2009, at 1:47 PM, Francois Menard wrote: >> Anything using an IP address as an identifier is not accurate, and =20= >> not reliable. It can be more accurate and more reliable than some =20= >> mechanisms, but it=92s fairly easily defeatable by any attacker with =20= >> a modicum of knowledge. An attack with a false location requires =20= >> someone to code: devices would be built to do the right thing. If =20= >> you can code, you can find a relay/zombie/whatever to hide your IP =20= >> address and present a different location. If you are telling =20 >> regulators that OBO substantially increases location veracity, you =20= >> are misleading them. It improves it only marginally, and only =20 >> works for a subset of what we want it to work for. >> > > Does ECRIT support OBO? > > f. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Mon Nov 23 11:17:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A07F3A68C3 for ; Mon, 23 Nov 2009 11:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QICa2ACbfKr3 for ; Mon, 23 Nov 2009 11:17:53 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 790FC3A6825 for ; Mon, 23 Nov 2009 11:17:53 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAP1uCkurR7Hu/2dsb2JhbACHbrgllxqCL4INBA X-IronPort-AV: E=Sophos;i="4.47,273,1257120000"; d="scan'208";a="52947094" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2009 19:17:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nANJHnsF008414; Mon, 23 Nov 2009 19:17:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:17:49 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.84.226]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:17:49 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Nov 2009 13:17:47 -0600 To: John Lange , Bernard Aboba From: "James M. Polk" In-Reply-To: <1258999764.5861.152.camel@linux-k6vx.site> References: <1258992769.5861.112.camel@linux-k6vx.site> <1258999764.5861.152.camel@linux-k6vx.site> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2009 19:17:49.0310 (UTC) FILETIME=[A54139E0:01CA6C71] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:17:54 -0000 At 12:09 PM 11/23/2009, John Lange wrote: >On Mon, 2009-11-23 at 08:40 -0800, Bernard Aboba wrote: > > > My crystal ball tells me that the future is mobile and that mobile > > > data-only devices with softphones will proliferate. This will > > further > > > diminish the nomadic VOIP market share. > > > > I agree that "mobile" is likely to rapidly displace nomadic. > > However, the move to "data only" has ocurred much slower than we had > > originally thought. > >I submit that the relatively slow uptake of data-only is due largely to >the fact that the providers are clinging to voice-based business models. > >Devices which support VOIP over data are still rare. For example, the >iPhone technically can do it but the VOIP over data applications are >blocked by Apple. well, this is wrong. Apple doesn't block real-time over data, AT&T does. Think about it. AT&T (like any cellular operator that has a fixed all-you-can-eat data plan) charges much much more for cellular calls than it does for its data plan. If all calls were to go over its data network, #1 this would bring its data network to its knees (something AT&T is already struggling with without voice/video traversing this part of the network (i.e., bandwidth usage and congested links)) and #2 users would choose the cheapest cellular voice plans that allow the flat rate data plan -- because most of what users use smartphones for is still calling. Apple has zero incentive to prevent calls from being data packets, whereas cellular carriers definitely do, because it impacts all the other applications that use their data network. James >With Andriod finally showing real signs life on a multitude of hardware >platforms, widespread use of VOIP on data-only mobile devices is >inevitable. > >That isn't to imply that there aren't still roadblocks. For example, >here in Canada, the growth of mobile data is severely restricted by the >lack of competition leading to mediocre selection of devices (we just >got the iPhone about a year ago) and very high data prices. > >-- >John Lange >http://www.johnlange.ca > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From bs7652@att.com Mon Nov 23 11:30:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC2028C1A0 for ; Mon, 23 Nov 2009 11:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzPCQWUNOEEx for ; Mon, 23 Nov 2009 11:30:12 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 2D2A728C19F for ; Mon, 23 Nov 2009 11:30:12 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1259004606!25784484!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 18871 invoked from network); 23 Nov 2009 19:30:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2009 19:30:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nANJU5OI010212; Mon, 23 Nov 2009 14:30:05 -0500 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id nANJTwkf010138; Mon, 23 Nov 2009 14:29:59 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:29:59 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:29:59 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 14:29:58 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA11004AC8@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Nomadic VOIP is dead thread-index: AcpscavMAGdoFO/9SQuakgQItdCmZQAAVEKA References: <1258992769.5861.112.camel@linux-k6vx.site><1258999764.5861.152.camel@linux-k6vx.site> From: "Stark, Barbara" To: "James M. Polk" , "John Lange" , "Bernard Aboba" X-OriginalArrivalTime: 23 Nov 2009 19:29:59.0303 (UTC) FILETIME=[585D5170:01CA6C73] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:30:13 -0000 http://finance.yahoo.com/news/ATT-Extends-VoIP-to-3G-bw-767580967.html?x =3D0 AT&T does not block VoIP calls on its 2G, 3G, or public Wi-Fi networks. AT&T does not prevent Apple from offering VoIP applications on the iPhone that will run over 2G or 3G. Please stick to blaming Canada. :) Barbara > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Monday, November 23, 2009 2:18 PM > To: John Lange; Bernard Aboba > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Nomadic VOIP is dead >=20 > At 12:09 PM 11/23/2009, John Lange wrote: > >On Mon, 2009-11-23 at 08:40 -0800, Bernard Aboba wrote: > > > > My crystal ball tells me that the future is mobile and that > mobile > > > > data-only devices with softphones will proliferate. This will > > > further > > > > diminish the nomadic VOIP market share. > > > > > > I agree that "mobile" is likely to rapidly displace nomadic. > > > However, the move to "data only" has ocurred much slower than we > had > > > originally thought. > > > >I submit that the relatively slow uptake of data-only is due largely > to > >the fact that the providers are clinging to voice-based business > models. > > > >Devices which support VOIP over data are still rare. For example, the > >iPhone technically can do it but the VOIP over data applications are > >blocked by Apple. >=20 > well, this is wrong. Apple doesn't block real-time over data, AT&T > does. >=20 > Think about it. AT&T (like any cellular operator that has a fixed > all-you-can-eat data plan) charges much much more for cellular calls > than it does for its data plan. If all calls were to go over its > data network, >=20 > #1 this would bring its data network to its knees (something > AT&T is already struggling with without voice/video traversing > this part of the network (i.e., bandwidth usage and congested > links)) >=20 > and >=20 > #2 users would choose the cheapest cellular voice plans that > allow the flat rate data plan -- because most of what users > use > smartphones for is still calling. >=20 > Apple has zero incentive to prevent calls from being data packets, > whereas cellular carriers definitely do, because it impacts all the > other applications that use their data network. >=20 > James >=20 >=20 > >With Andriod finally showing real signs life on a multitude of > hardware > >platforms, widespread use of VOIP on data-only mobile devices is > >inevitable. > > > >That isn't to imply that there aren't still roadblocks. For example, > >here in Canada, the growth of mobile data is severely restricted by > the > >lack of competition leading to mediocre selection of devices (we just > >got the iPhone about a year ago) and very high data prices. > > > >-- > >John Lange > >http://www.johnlange.ca > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 From fmenard@xittelecom.com Mon Nov 23 11:55:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB253A6781 for ; Mon, 23 Nov 2009 11:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFq9QZv43+CL for ; Mon, 23 Nov 2009 11:55:33 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id C598E3A6837 for ; Mon, 23 Nov 2009 11:55:29 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCf0P-0007QE-Ba; Mon, 23 Nov 2009 14:55:25 -0500 Received: from [205.151.16.4] (helo=[192.168.2.64]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1NCf0O-000214-Tp; Mon, 23 Nov 2009 14:55:25 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Francois Menard In-Reply-To: Date: Mon, 23 Nov 2009 14:55:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <242B6001-D71E-4093-A9B6-E9176B4CAFCB@xittelecom.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:55:34 -0000 > Sure it does, especially in the secondary/verification context that = James describes. It just requires the access network to *also* provide = location to the end host so that it (or the VSP) has some idea what to = do with the call. E.g., whether to send it to the Canadian Stage 1 = proxy or the Albanian one. >=20 I am referring to the access network providing location to Stage One = Proxy. Does ECRIT allows for this to happen? f. > --Richard >=20 >=20 > On Nov 23, 2009, at 1:47 PM, Francois Menard wrote: >=20 >>> Anything using an IP address as an identifier is not accurate, and = not reliable. It can be more accurate and more reliable than some = mechanisms, but it=92s fairly easily defeatable by any attacker with a = modicum of knowledge. An attack with a false location requires someone = to code: devices would be built to do the right thing. If you can code, = you can find a relay/zombie/whatever to hide your IP address and present = a different location. If you are telling regulators that OBO = substantially increases location veracity, you are misleading them. It = improves it only marginally, and only works for a subset of what we want = it to work for. >>>=20 >>=20 >> Does ECRIT support OBO? >>=20 >> f. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Mon Nov 23 12:15:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8788228C115 for ; Mon, 23 Nov 2009 12:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9d2z9P-SGjo for ; Mon, 23 Nov 2009 12:15:43 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com (xmb-rtp-205.cisco.com [64.102.31.59]) by core3.amsl.com (Postfix) with ESMTP id 497B53A6A4B for ; Mon, 23 Nov 2009 12:15:43 -0800 (PST) Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:15:37 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Nov 2009 15:15:34 -0500 From: Marc Linsner To: Bernard Aboba Message-ID: Thread-Topic: [Ecrit] wireless VOIP is dead Thread-Index: AcpsaBp4TwfRzzftQwSXfQ+Vv7CdjgAAkgoQAAPU7x4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Nov 2009 20:15:37.0990 (UTC) FILETIME=[B8BFCA60:01CA6C79] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:15:44 -0000 Bernard, What would you consider the data dongles and mifi thingies? Aren't those a data only service? My experience has been that VoIP over 3G is less than desirable due to jitter. Even the most forgiving of codecs (Skype) struggle with the jitter on 3G. -Marc- On 11/23/09 2:01 PM, "Bernard Aboba" wrote: >> I submit that the relatively slow uptake of data-only is due largely to >> the fact that the providers are clinging to voice-based business models.... >> widespread use of VOIP on data-only mobile devices is inevitable. > > While I'd agree that it's likely to happen at some point, there is no "data > only" wireless technology on the horizon that seems likely to result in > widespread deployment of wireless VOIP in the near future. > > Today's fragmented hotspot deployments with their web portal-based access > model are not exactly "VOIP-friendly". > > Even greenfield wireless providers with no existing voice-based business model > have failed in their introduction of "data-only" plans. Typically this is due > to unfavorable speed/power and cost/coverage tradeoffs. This problem occurs > because next generation wireless data technologies have greatly increased > power consumption and much reduced coverage radius compared with existing > technologies. Capital and maintenance costs rise with the inverse square of > the coverage ratio. So reducing the coverage radius by 50 percent increases > cost by 400 percent. Similarly, power consumption increases more than > linearly with speed. These basic mathematical principles have had devastating > effects on the prospects of "data only" wireless networks, whether they be > municipal networks unable to provide acceptable coverage with 802.11 APs > running at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz WiMAX > pilots that have only demonstrated a 1-2 mile coverage radius. The bottom lin > e is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospitable to > construction of viable "data only" networks. > > It's possible that allocation of spectrum with longer propagation > characteristics (e.g. White Spaces) may help in overcoming coverage obstacles, > but that is years away. > >> That isn't to imply that there aren't still roadblocks. For example, >> here in Canada, the growth of mobile data is severely restricted by the >> lack of competition leading to mediocre selection of devices (we just >> got the iPhone about a year ago) and very high data prices. > > Here in the U.S. we have seen "data only" wireless networks offering access > for as little as $20/month fail to sign up even 5 percent of the population. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Mon Nov 23 12:21:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF1F3A692B for ; Mon, 23 Nov 2009 12:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8cEDBZFNC4x for ; Mon, 23 Nov 2009 12:21:54 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com (xmb-rtp-205.cisco.com [64.102.31.59]) by core3.amsl.com (Postfix) with ESMTP id 24AA33A6908 for ; Mon, 23 Nov 2009 12:21:54 -0800 (PST) Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:21:49 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Nov 2009 15:21:48 -0500 From: Marc Linsner To: Francois Menard , Richard Barnes Message-ID: Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcpsepVKQDl5hVwNj0Sieffe8dOh0Q== In-Reply-To: <242B6001-D71E-4093-A9B6-E9176B4CAFCB@xittelecom.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Nov 2009 20:21:49.0900 (UTC) FILETIME=[966CC0C0:01CA6C7A] Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:21:55 -0000 Francois, Yes, ECRIT allows this. The general OBO topic of privacy/security is for GeoPriv. See section 6.3 at: http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-13#page-8 And http://tools.ietf.org/html/draft-ietf-ecrit-framework-10#page-19 -Marc- On 11/23/09 2:55 PM, "Francois Menard" wrote: >> Sure it does, especially in the secondary/verification context that Jame= s >> describes. It just requires the access network to *also* provide locati= on to >> the end host so that it (or the VSP) has some idea what to do with the c= all. >> E.g., whether to send it to the Canadian Stage 1 proxy or the Albanian o= ne. >>=20 >=20 > I am referring to the access network providing location to Stage One Prox= y. >=20 > Does ECRIT allows for this to happen? >=20 > f. >=20 >> --Richard >>=20 >>=20 >> On Nov 23, 2009, at 1:47 PM, Francois Menard wrote: >>=20 >>>> Anything using an IP address as an identifier is not accurate, and not >>>> reliable. It can be more accurate and more reliable than some mechani= sms, >>>> but it=B9s fairly easily defeatable by any attacker with a modicum of >>>> knowledge. An attack with a false location requires someone to code: >>>> devices would be built to do the right thing. If you can code, you ca= n >>>> find a relay/zombie/whatever to hide your IP address and present a >>>> different location. If you are telling regulators that OBO substantia= lly >>>> increases location veracity, you are misleading them. It improves it = only >>>> marginally, and only works for a subset of what we want it to work for= . >>>>=20 >>>=20 >>> Does ECRIT support OBO? >>>=20 >>> f. >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Nov 23 12:28:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7223A687F for ; Mon, 23 Nov 2009 12:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JrEilciENPW for ; Mon, 23 Nov 2009 12:28:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4B9DA3A6877 for ; Mon, 23 Nov 2009 12:28:27 -0800 (PST) Received: from ros-dhcp192-1-51-18.bbn.com ([192.1.51.18]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NCfWI-0005jo-B1; Mon, 23 Nov 2009 15:28:22 -0500 Message-Id: From: Richard Barnes To: Francois Menard In-Reply-To: <242B6001-D71E-4093-A9B6-E9176B4CAFCB@xittelecom.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Nov 2009 15:28:20 -0500 References: <242B6001-D71E-4093-A9B6-E9176B4CAFCB@xittelecom.com> X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:28:28 -0000 Yes, it allows it to happen. There's not a *requirement* that the ISP =20= provide location to anyone other than the endpoint, but neither is =20 there a *prohibition*. So it's an area where a national architecture =20= like Ci2 could elaborate. --Richard On Nov 23, 2009, at 2:55 PM, Francois Menard wrote: >> Sure it does, especially in the secondary/verification context that =20= >> James describes. It just requires the access network to *also* =20 >> provide location to the end host so that it (or the VSP) has some =20 >> idea what to do with the call. E.g., whether to send it to the =20 >> Canadian Stage 1 proxy or the Albanian one. >> > > I am referring to the access network providing location to Stage One =20= > Proxy. > > Does ECRIT allows for this to happen? > > f. > >> --Richard >> >> >> On Nov 23, 2009, at 1:47 PM, Francois Menard wrote: >> >>>> Anything using an IP address as an identifier is not accurate, =20 >>>> and not reliable. It can be more accurate and more reliable than =20= >>>> some mechanisms, but it=92s fairly easily defeatable by any =20 >>>> attacker with a modicum of knowledge. An attack with a false =20 >>>> location requires someone to code: devices would be built to do =20 >>>> the right thing. If you can code, you can find a relay/zombie/=20 >>>> whatever to hide your IP address and present a different =20 >>>> location. If you are telling regulators that OBO substantially =20 >>>> increases location veracity, you are misleading them. It =20 >>>> improves it only marginally, and only works for a subset of what =20= >>>> we want it to work for. >>>> >>> >>> Does ECRIT support OBO? >>> >>> f. >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From wonsang@cs.columbia.edu Mon Nov 23 12:53:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E91E3A6959 for ; Mon, 23 Nov 2009 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssgwCSGbh8+J for ; Mon, 23 Nov 2009 12:53:19 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 817B23A688A for ; Mon, 23 Nov 2009 12:53:19 -0800 (PST) Received: from [128.59.22.84] (ng911-desktop1.cs.columbia.edu [128.59.22.84]) (user=ws2131 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nANKrDVR015992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Nov 2009 15:53:13 -0500 (EST) Message-ID: <4B0AF639.7020501@cs.columbia.edu> Date: Mon, 23 Nov 2009 15:53:13 -0500 From: Wonsang Song User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="------------070102070104080502080101" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Subject: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:53:20 -0000 This is a multi-part message in MIME format. --------------070102070104080502080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Just wanted to send a note about a new draft on using SIP MESSAGE for emergency texting. The draft is an outcome of the collaboration between Columbia University and Verizon to build an emergency texting prototype system which allows people to use IM and SMS to "call" for emergency help. If you have comments or questions, please let me know. Thank you, Wonsang Song -------- Original Message -------- Subject: New Version Notification for draft-kim-ecrit-text-00 Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) From: IETF I-D Submission Tool To: jyk@cs.columbia.edu CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, p.boni@verizon.com, michael.g.armstrong@verizon.com A new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly submitted by Jong Yul Kim and posted to the IETF repository. Filename: draft-kim-ecrit-text Revision: 00 Title: Emergency Text Messaging using SIP MESSAGE Creation_date: 2009-11-16 WG ID: Independent Submission Number_of_pages: 11 Abstract: This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. --------------070102070104080502080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Just wanted to send a note about a new draft on using SIP MESSAGE for emergency texting.

The draft is an outcome of the collaboration between Columbia University and Verizon to build an emergency texting prototype system which allows people to use IM and SMS to "call" for emergency help.

If you have comments or questions, please let me know.

Thank you,
Wonsang Song


-------- Original Message --------
Subject: New Version Notification for draft-kim-ecrit-text-00
Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: jyk@cs.columbia.edu
CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, p.boni@verizon.com,      michael.g.armstrong@verizon.com


A new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly submitted by Jong Yul Kim and posted to the IETF repository.

Filename:  draft-kim-ecrit-text
Revision:  00
Title:  Emergency Text Messaging using SIP MESSAGE
Creation_date:  2009-11-16
WG ID:  Independent Submission
Number_of_pages: 11

Abstract:
This memo describes best current practices on how to use the SIP
MESSAGE method for emergency text messaging from citizen and visitors
to authorities.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 20, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.



The IETF Secretariat.




--------------070102070104080502080101-- From john@johnlange.ca Mon Nov 23 13:04:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0A53A66B4 for ; Mon, 23 Nov 2009 13:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZhONbiJYMem for ; Mon, 23 Nov 2009 13:04:05 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 903F93A67D2 for ; Mon, 23 Nov 2009 13:04:05 -0800 (PST) Received: by qyk29 with SMTP id 29so2786133qyk.32 for ; Mon, 23 Nov 2009 13:03:57 -0800 (PST) Received: by 10.224.86.227 with SMTP id t35mr2747720qal.121.1259010237777; Mon, 23 Nov 2009 13:03:57 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 21sm3741154qyk.12.2009.11.23.13.03.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 13:03:57 -0800 (PST) From: John Lange To: "James M. Polk" In-Reply-To: References: <1258992769.5861.112.camel@linux-k6vx.site> <1258999764.5861.152.camel@linux-k6vx.site> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 15:03:44 -0600 Message-Id: <1259010224.11322.7.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:04:06 -0000 On Mon, 2009-11-23 at 13:17 -0600, James M. Polk wrote: > well, this is wrong. Apple doesn't block real-time over data, AT&T does. Apple controls what apps are allowed in and does not allow any that can do VOIP over data. And my understanding is that jailbroke phones can do VOIP over data so the restriction is on the apps, not the network. This may have been a result of the deal with AT&T but AFAIK it's a world-wide restriction. They do allow apps with voip over wifi. I personally don't keep up on iPhone news so perhaps things have changed recently? -- John Lange http://www.johnlange.ca From john@johnlange.ca Mon Nov 23 13:12:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8018628C193 for ; Mon, 23 Nov 2009 13:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcyUVvUJBv1A for ; Mon, 23 Nov 2009 13:12:33 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id F3E7B3A6AC1 for ; Mon, 23 Nov 2009 13:12:32 -0800 (PST) Received: by qyk29 with SMTP id 29so2790002qyk.32 for ; Mon, 23 Nov 2009 13:12:25 -0800 (PST) Received: by 10.224.29.74 with SMTP id p10mr2724606qac.290.1259010745479; Mon, 23 Nov 2009 13:12:25 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 21sm3749248qyk.4.2009.11.23.13.12.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 13:12:24 -0800 (PST) From: John Lange To: Bernard Aboba In-Reply-To: References: ,<1258992769.5861.112.camel@linux-k6vx.site> <1258999764.5861.152.camel@linux-k6vx.site> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 15:12:18 -0600 Message-Id: <1259010738.11322.14.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:12:34 -0000 On Mon, 2009-11-23 at 11:01 -0800, Bernard Aboba wrote: > Here in the U.S. we have seen "data only" wireless networks offering > access for as little as $20/month fail to sign up even 5 percent of > the population. Well 5% of the US population is a significant number, but in any case, what device were they pushing with these plans and what kind of speeds/coverage did they have? If there was a great device available with a VOIP softphone and unlimited data for $20 with the coverage of a cellphone it would have some real potential. I know I'd get one. -- John Lange http://www.johnlange.ca From bernard_aboba@hotmail.com Mon Nov 23 13:36:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092433A6813 for ; Mon, 23 Nov 2009 13:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.993, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MqlLLwZKFfx for ; Mon, 23 Nov 2009 13:36:22 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 466563A6962 for ; Mon, 23 Nov 2009 13:36:22 -0800 (PST) Received: from BLU137-W36 ([65.55.111.71]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:36:18 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f3058b37-3d03-483b-a5db-413c99fcd589_" X-Originating-IP: [64.134.221.168] From: Bernard Aboba To: Date: Mon, 23 Nov 2009 13:36:18 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 21:36:18.0054 (UTC) FILETIME=[FDA6F260:01CA6C84] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:36:24 -0000 --_f3058b37-3d03-483b-a5db-413c99fcd589_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The data dongles=2C etc. are indeed "data only" devices. However=2C today = they only represent a small fraction of all wireless endpoints. It is conc= eivable that this could change with the introduction of new computing devic= es with built in WWAN chipsets (such as netbooks or tablets). But the cur= rent "attach rate" of WWAN chipsets is currently much lower than with free = wireless technologies such as WLAN=2C Bluetooth or even GPS. In the curren= t economic environment=2C those wireless chipsets are selling a lot better = than WWAN chipsets which require "data only" plans running $60+/month. =20 In terms of jitter=2C this varies considerably based on the specifics of a = particular deployment. The rapid increase in usage of smartphones has put = a lot of pressure on existing networks=2C and many are now running very clo= se to capacity. So even though we have seen some loosening of VOIP restric= tions (my understanding is that Skype use is no longer restricted to WLAN= =2C for example)=2C the user experience during peak usage times will often = not be very good.=20 I've also seen networks with self-inflicted design problems. For example= =2C sometimes the GGSN buffering is over-provisioned=2C in the mistaken bel= ief that this somehow will decrease packet loss. Instead=2C it results in = a sawtooth ramp up in delay as the queues fill=2C followed by sustained pac= ket loss as incoming packets drop until the queue can be slowly emptied. N= ot good for VOIP.=20 As to whether future technologies such as LTE can be provide a better VOIP = experience=2C I'm skeptical. In the medium term=2C LTE is most likely to b= e deployed as an "infill" technology=2C providing higher speed data access = in areas with a high density of data users. This kind of incremental deplo= yment is much more economical than attempting to create a "greenfield" 4G n= etwork=2C so it is quite likely to happen=2C paid for by all the new smartp= hone data plans. =20 The question is whether all those new smartphones and data plans will trans= ition to use of VOIP in the near future. I doubt it. As long as LTE cover= age remains spotty=2C and wireless networks remain congested=2C demand for = wireless data bandwidth will run ahead of supply. Without better handling = of congestion (such as by using some of the techniques discussed in the Tra= nsport Area=2C such as LEDBAT or Re-ECN)=2C the VOIP user experience won't = be good enough to handle a very large fraction of calls=2C even if restrict= ions on VOIP usage are removed. > Bernard=2C >=20 > What would you consider the data dongles and mifi thingies? Aren't those= a > data only service? >=20 > My experience has been that VoIP over 3G is less than desirable due to > jitter. Even the most forgiving of codecs (Skype) struggle with the jitt= er > on 3G. >=20 > -Marc- >=20 >=20 > On 11/23/09 2:01 PM=2C "Bernard Aboba" wrote: >=20 > >> I submit that the relatively slow uptake of data-only is due largely t= o > >> the fact that the providers are clinging to voice-based business model= s.... > >> widespread use of VOIP on data-only mobile devices is inevitable. > >=20 > > While I'd agree that it's likely to happen at some point=2C there is no= "data > > only" wireless technology on the horizon that seems likely to result in > > widespread deployment of wireless VOIP in the near future. > >=20 > > Today's fragmented hotspot deployments with their web portal-based acce= ss > > model are not exactly "VOIP-friendly". > >=20 > > Even greenfield wireless providers with no existing voice-based busines= s model > > have failed in their introduction of "data-only" plans. Typically this= is due > > to unfavorable speed/power and cost/coverage tradeoffs. This problem o= ccurs > > because next generation wireless data technologies have greatly increas= ed > > power consumption and much reduced coverage radius compared with existi= ng > > technologies. Capital and maintenance costs rise with the inverse squa= re of > > the coverage ratio. So reducing the coverage radius by 50 percent incr= eases > > cost by 400 percent. Similarly=2C power consumption increases more tha= n > > linearly with speed. These basic mathematical principles have had deva= stating > > effects on the prospects of "data only" wireless networks=2C whether th= ey be > > municipal networks unable to provide acceptable coverage with 802.11 AP= s > > running at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz = WiMAX > > pilots that have only demonstrated a 1-2 mile coverage radius. The bot= tom lin > > e is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospitable to > > construction of viable "data only" networks. > >=20 > > It's possible that allocation of spectrum with longer propagation > > characteristics (e.g. White Spaces) may help in overcoming coverage obs= tacles=2C > > but that is years away. > >=20 > >> That isn't to imply that there aren't still roadblocks. For example=2C > >> here in Canada=2C the growth of mobile data is severely restricted by = the > >> lack of competition leading to mediocre selection of devices (we just > >> got the iPhone about a year ago) and very high data prices. > >=20 > > Here in the U.S. we have seen "data only" wireless networks offering ac= cess > > for as little as $20/month fail to sign up even 5 percent of the popula= tion. > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 = --_f3058b37-3d03-483b-a5db-413c99fcd589_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The data dongles=2C etc. are indeed "data only" devices. =3B However=2C= today they only represent a small fraction of all wireless endpoints. = =3B It is conceivable that this could change with the introduction of new c= omputing devices with built in WWAN chipsets (such as netbooks or tablets).=  =3B =3B But the current "attach rate" of WWAN chipsets is currentl= y much lower than with free wireless technologies such as WLAN=2C Bluetooth= or even GPS. =3B In the current economic environment=2C those wireless= chipsets are selling a lot better than WWAN chipsets which require "data o= nly" plans running $60+/month. =3B

In terms of jitter=2C this v= aries considerably based on the specifics of a particular deployment. = =3B The rapid increase in usage of smartphones has put a lot of pressure on= existing networks=2C and many are now running very close to capacity. = =3B So even though we have seen some loosening of VOIP restrictions (my und= erstanding is that Skype use is no longer restricted to WLAN=2C for example= )=2C the user experience during peak usage times will often not be very goo= d.

I've also seen networks with self-inflicted design problems.&nbs= p=3B For example=2C sometimes the GGSN buffering is over-provisioned=2C in = the mistaken belief that this somehow will decrease packet loss. =3B In= stead=2C it results in a sawtooth ramp up in delay as the queues fill=2C fo= llowed by sustained packet loss as incoming packets drop until the queue ca= n be slowly emptied. =3B Not good for VOIP.

As to whether futur= e technologies such as LTE can be provide a better VOIP experience=2C I'm s= keptical. =3B In the medium term=2C LTE is most likely to be deployed a= s an "infill" technology=2C providing higher speed data access in areas wit= h a high density of data users. =3B This kind of incremental deployment= is much more economical than attempting to create a "greenfield" 4G networ= k=2C so it is quite likely to happen=2C paid for by all the new smartphone = data plans. =3B

The question is whether all those new smartphon= es and data plans will transition to use of VOIP in the near future. = =3B I doubt it. =3B As long as LTE coverage remains spotty=2C and wirel= ess networks remain congested=2C demand for wireless data bandwidth will ru= n ahead of supply. =3B Without better handling of congestion (such as b= y using some of the techniques discussed in the Transport Area=2C such as L= EDBAT or Re-ECN)=2C the VOIP user experience won't be good enough to handle= a very large fraction of calls=2C even if restrictions on VOIP usage are r= emoved.

>=3B Bernard=2C
>=3B
>=3B What would you consid= er the data dongles and mifi thingies? Aren't those a
>=3B data only = service?
>=3B
>=3B My experience has been that VoIP over 3G is l= ess than desirable due to
>=3B jitter. Even the most forgiving of cod= ecs (Skype) struggle with the jitter
>=3B on 3G.
>=3B
>=3B = -Marc-
>=3B
>=3B
>=3B On 11/23/09 2:01 PM=2C "Bernard Abob= a" <=3Bbernard_aboba@hotmail.com>=3B wrote:
>=3B
>=3B >=3B= >=3B I submit that the relatively slow uptake of data-only is due largely= to
>=3B >=3B>=3B the fact that the providers are clinging to voic= e-based business models....
>=3B >=3B>=3B widespread use of VOIP o= n data-only mobile devices is inevitable.
>=3B >=3B
>=3B >= =3B While I'd agree that it's likely to happen at some point=2C there is no= "data
>=3B >=3B only" wireless technology on the horizon that seems= likely to result in
>=3B >=3B widespread deployment of wireless VOI= P in the near future.
>=3B >=3B
>=3B >=3B Today's fragmented= hotspot deployments with their web portal-based access
>=3B >=3B mo= del are not exactly "VOIP-friendly".
>=3B >=3B
>=3B >=3B Eve= n greenfield wireless providers with no existing voice-based business model=
>=3B >=3B have failed in their introduction of "data-only" plans. = Typically this is due
>=3B >=3B to unfavorable speed/power and cost/= coverage tradeoffs. This problem occurs
>=3B >=3B because next gene= ration wireless data technologies have greatly increased
>=3B >=3B p= ower consumption and much reduced coverage radius compared with existing>=3B >=3B technologies. Capital and maintenance costs rise with the i= nverse square of
>=3B >=3B the coverage ratio. So reducing the cove= rage radius by 50 percent increases
>=3B >=3B cost by 400 percent. = Similarly=2C power consumption increases more than
>=3B >=3B linearl= y with speed. These basic mathematical principles have had devastating
= >=3B >=3B effects on the prospects of "data only" wireless networks=2C = whether they be
>=3B >=3B municipal networks unable to provide accep= table coverage with 802.11 APs
>=3B >=3B running at 2.4 or 5 Gz moun= ted on lamp-posts 600 feet apart or 2.5 Ghz WiMAX
>=3B >=3B pilots t= hat have only demonstrated a 1-2 mile coverage radius. The bottom lin
&= gt=3B >=3B e is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospita= ble to
>=3B >=3B construction of viable "data only" networks.
>= =3B >=3B
>=3B >=3B It's possible that allocation of spectrum with= longer propagation
>=3B >=3B characteristics (e.g. White Spaces) ma= y help in overcoming coverage obstacles=2C
>=3B >=3B but that is yea= rs away.
>=3B >=3B
>=3B >=3B>=3B That isn't to imply that = there aren't still roadblocks. For example=2C
>=3B >=3B>=3B here i= n Canada=2C the growth of mobile data is severely restricted by the
>= =3B >=3B>=3B lack of competition leading to mediocre selection of devic= es (we just
>=3B >=3B>=3B got the iPhone about a year ago) and ver= y high data prices.
>=3B >=3B
>=3B >=3B Here in the U.S. we = have seen "data only" wireless networks offering access
>=3B >=3B fo= r as little as $20/month fail to sign up even 5 percent of the population.<= br>>=3B >=3B
>=3B >=3B ________________________________________= _______
>=3B >=3B Ecrit mailing list
>=3B >=3B Ecrit@ietf.org=
>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit
>=3B >=3B
= --_f3058b37-3d03-483b-a5db-413c99fcd589_-- From bernard_aboba@hotmail.com Mon Nov 23 13:53:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02013A6849 for ; Mon, 23 Nov 2009 13:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvWzQ-Gf9xmm for ; Mon, 23 Nov 2009 13:53:36 -0800 (PST) Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by core3.amsl.com (Postfix) with ESMTP id 991B53A6778 for ; Mon, 23 Nov 2009 13:53:36 -0800 (PST) Received: from BLU137-W22 ([65.55.116.9]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:53:32 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1a292a23-c62d-4a29-ba4b-41978a00f3ed_" X-Originating-IP: [64.134.221.168] From: Bernard Aboba To: Date: Mon, 23 Nov 2009 13:53:32 -0800 Importance: Normal In-Reply-To: <1259010738.11322.14.camel@linux-k6vx.site> References: , , <1258992769.5861.112.camel@linux-k6vx.site>, , <1258999764.5861.152.camel@linux-k6vx.site>, , <1259010738.11322.14.camel@linux-k6vx.site> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 21:53:32.0737 (UTC) FILETIME=[665F0B10:01CA6C87] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:53:37 -0000 --_1a292a23-c62d-4a29-ba4b-41978a00f3ed_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Well 5% of the US population is a significant number=2C but in any case= =2C > what device were they pushing with these plans and what kind of > speeds/coverage did they have? >=20 > If there was a great device available with a VOIP softphone and > unlimited data for $20 with the coverage of a cellphone it would have > some real potential. >=20 > I know I'd get one. The Philadelphia municipal WiFi buildout is one example that comes to mind.= =20 With an initial estimated capital cost of $17 million=2C coverage only exte= nded=20 to 70 percent of the city and even within the covered areas=2C access was=20 often only available at the lowest rate (1 Mbps) due to the spacing between lamp posts (600 feet). =20 Covering 100% of the city at higher rates (e.g. 5.5 Mbps) would probably=20 have required quadrupling of the capital cost. Achieving payback on that= =20 kind of investment would probably have required signing up at least 15=20 percent of the population=2C but initial marketing only garnered a tepid re= sponse. The voice-oriented devices available at the time were VoWLAN handsets from manufacturers such as Belkin. At one time=2C quite a few VOIP providers=20 (including Vonage) announced their interest in offering such devices. Howe= ver=2C due to the price (most VoWLAN handsets today still cost $100 or more)=20 and convenience (ever tried to configure WPA2 or sign on to a hotspot web p= ortal with a special purpose VoWLAN handset?) VOIP providers focused instead on d= elivering=20 wireless voice using DEC 6.0 cordless phones.=20 At this point=2C smartphones are so ahead of special purpose VoWLAN handset= s that the game is effectively over. However=2C many smartphones sold via c= arriers come with a built-in data plan=2C and if you're already signed up for a cellular voice and data plan=2C the extra $20/month for muni-WiFi access lo= oks a=20 lot less attractive.=20 = --_1a292a23-c62d-4a29-ba4b-41978a00f3ed_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B Well 5% of the US population is a significant number=2C but in any c= ase=2C
>=3B what device were they pushing with these plans and what ki= nd of
>=3B speeds/coverage did they have?
>=3B
>=3B If ther= e was a great device available with a VOIP softphone and
>=3B unlimite= d data for $20 with the coverage of a cellphone it would have
>=3B som= e real potential.
>=3B
>=3B I know I'd get one.

The Phila= delphia municipal WiFi buildout is one example that comes to mind. =3B =
With an initial estimated capital cost of $17 million=2C coverage only = extended
to 70 percent of the city and even within the covered areas=2C= access was
often only available at the lowest rate (1 Mbps) due to the= spacing between
lamp posts (600 feet).  =3B

Covering 100% o= f the city at higher rates (e.g. 5.5 Mbps) would probably
have required= quadrupling of the capital cost. =3B =3B Achieving payback on that=
kind of investment would probably have required signing up at least 15=
percent of the population=2C but initial marketing only garnered a tep= id response.

The voice-oriented devices available at the time were V= oWLAN handsets from
manufacturers such as Belkin. =3B At one time=2C= quite a few VOIP providers
(including Vonage) announced their interest= in offering such devices. =3B However=2C
due to the price (most VoW= LAN handsets today still cost $100 or more)
and convenience (ever tried= to configure WPA2 or sign on to a hotspot web portal
with a special pur= pose VoWLAN handset?) VOIP providers focused instead on delivering
wire= less voice using DEC 6.0 cordless phones.

At this point=2C smartpho= nes are so ahead of special purpose VoWLAN handsets
that the game is eff= ectively over. =3B =3B However=2C many smartphones sold via carrier= s
come with a built-in data plan=2C and if you're already signed up for = a
cellular voice and data plan=2C the extra $20/month for muni-WiFi acce= ss looks a
lot less attractive.
= --_1a292a23-c62d-4a29-ba4b-41978a00f3ed_-- From drage@alcatel-lucent.com Mon Nov 23 17:35:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCC028C1C6 for ; Mon, 23 Nov 2009 17:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SSSraRUv+VB for ; Mon, 23 Nov 2009 17:34:59 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3662D28C0EC for ; Mon, 23 Nov 2009 17:34:58 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAO1Yjxq031692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 02:34:45 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 24 Nov 2009 02:34:45 +0100 From: "DRAGE, Keith (Keith)" To: Wonsang Song , "ecrit@ietf.org" Date: Tue, 24 Nov 2009 02:34:44 +0100 Thread-Topic: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] Thread-Index: Acpsfv8/2AeR/H/5TFeVVZAOXXL0QgAJufdw Message-ID: References: <4B0AF639.7020501@cs.columbia.edu> In-Reply-To: <4B0AF639.7020501@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE209B00796FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:35:00 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE209B00796FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So did I read this correctly. You are essentially saying you want to use page mode messaging to do sessio= n mode messaging? Didn't SIMPLE investigate that path and reject it and go for MSRP as the so= lution to session mode messaging? Why does emergency calling suddenly make the original decision making proce= ss in SIMPLE redundant? regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= onsang Song Sent: Monday, November 23, 2009 8:53 PM To: ecrit@ietf.org Subject: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00= ] Hi, Just wanted to send a note about a new draft on using SIP MESSAGE for emerg= ency texting. The draft is an outcome of the collaboration between Columbia University an= d Verizon to build an emergency texting prototype system which allows peopl= e to use IM and SMS to "call" for emergency help. If you have comments or questions, please let me know. Thank you, Wonsang Song -------- Original Message -------- Subject: New Version Notification for draft-kim-ecrit-text-00 Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) From: IETF I-D Submission Tool To: jyk@cs.columbia.edu CC: wonsang@cs.columbia.edu, hgs@cs.columbi= a.edu, p.boni@verizon.com, michael.g.armstrong@verizon.com A new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly subm= itted by Jong Yul Kim and posted to the IETF repository. Filename: draft-kim-ecrit-text Revision: 00 Title: Emergency Text Messaging using SIP MESSAGE Creation_date: 2009-11-16 WG ID: Independent Submission Number_of_pages: 11 Abstract: This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. --_000_EDC0A1AE77C57744B664A310A0B23AE209B00796FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So did I read this correctly.
 
You are essentially saying you want to use page mo= de=20 messaging to do session mode messaging?
 
Didn't SIMPLE investigate that path and reject it = and go=20 for MSRP as the solution to session mode messaging?
 
Why does emergency calling suddenly make the origi= nal=20 decision making process in SIMPLE redundant?
 
regards
 
Keith

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Wonsang=20 Song
Sent: Monday, November 23, 2009 8:53 PM
To:=20 ecrit@ietf.org
Subject: [Ecrit] [Fwd: New Version Notification = for=20 draft-kim-ecrit-text-00]

Hi,

Just wanted to send a note about a new draft on usi= ng=20 SIP MESSAGE for emergency texting.

The draft is an outcome of the= =20 collaboration between Columbia University and Verizon to build an emergen= cy=20 texting prototype system which allows people to use IM and SMS to "call" = for=20 emergency help.

If you have comments or questions, please let me=20 know.

Thank you,
Wonsang Song


-------- Original Mess= age=20 --------
Subject: New Version Notification for=20 draft-kim-ecrit-text-00
Date: Tue, 17 Nov 2009 11:55:17 -0800=20 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>To: jyk@cs.columbia.edu
CC: <= A=20 class=3Dmoz-txt-link-abbreviated=20 href=3D"mailto:wonsang@cs.columbia.edu">wonsang@cs.columbia.edu, = ;hgs@cs.columbia.edu, p.boni@verizon.com,=20      michael.g.armstrong@veriz= on.com


A=20 new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly subm= itted=20 by Jong Yul Kim and posted to the IETF repository.

Filename:=20  draft-kim-ecrit-text
Revision:  00
Title:  Emergency Text Messaging using SI= P=20 MESSAGE
Creation_date:=20  2009-11-16
WG ID:  Independent=20 Submission
Number_of_pages: 11

Abstract:
This memo describes= best=20 current practices on how to use the SIP
MESSAGE method for emergency t= ext=20 messaging from citizen and visitors
to authorities.

Status of t= his=20 Memo

This Internet-Draft is submitted to IETF in full conformance = with=20 the
provisions of BCP 78 and BCP 79.

Internet-Drafts are workin= g=20 documents of the Internet Engineering
Task Force (IETF), its areas, an= d its=20 working groups.  Note that
other groups may also distribute worki= ng=20 documents as Internet-
Drafts.

Internet-Drafts are draft docume= nts=20 valid for a maximum of six months
and may be updated, replaced, or=20 obsoleted by other documents at any
time.  It is inappropriate to= use=20 Internet-Drafts as reference
material or to cite them other than as "w= ork=20 in progress."

The list of current Internet-Drafts can be accessed= =20 at
http://www.ietf.org/i= etf/1id-abstracts.txt.

The=20 list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html<= /A>.

This=20 Internet-Draft will expire on May 20, 2010.

Copyright=20 Notice

Copyright (c) 2009 IETF Trust and the persons identified as= =20 the
document authors.  All rights reserved.

This document = is=20 subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IE= TF=20 Documents
(http://trustee.ietf.org/lic= ense-info)=20 in effect on the date of
publication of this document.  Please re= view=20 these documents
carefully, as they describe your rights and restrictio= ns=20 with respect
to this document.  Code Components extracted from th= is=20 document must
include Simplified BSD License text as described in Sect= ion=20 4.e of
the Trust Legal Provisions and are provided without warranty=20 as
described in the BSD License.



The IETF Secretariat.= =20




--_000_EDC0A1AE77C57744B664A310A0B23AE209B00796FRMRSSXCHMBSC3d_-- From fmenard@xittelecom.com Mon Nov 23 18:08:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854673A6AFC for ; Mon, 23 Nov 2009 18:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO49cAFL8HzS for ; Mon, 23 Nov 2009 18:08:33 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 007A43A6860 for ; Mon, 23 Nov 2009 18:08:32 -0800 (PST) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCkpP-0006x4-PK; Mon, 23 Nov 2009 21:08:28 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCkpN-0000cQ-RD; Mon, 23 Nov 2009 21:08:27 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Francois D. Menard In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> Date: Mon, 23 Nov 2009 21:08:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E @SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:08:34 -0000 > > You are saying that veracity needs to be assessed while a 9-1-1 call = is > > being established? > [AJW] Trusted third-party also eliminates the need to do a veracity = check at call time. So I only see this as another advantage. > =20 How is that different from end-to-end location download in the end-point = then? If the veracity check is not done at call time, how is veracity is being = assessed? >=20 > > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he = is > > elsewhere on Earth, he will get a DHCP 99/123 with that information. > =20 > [AJW] Absolutely wrong. He can have a softphone and be where ever he = wants to be and this is precisely the problem. You are not providing a = means to stop this kind of malicious calling, or any means to trace the = culprit. The solution does not provide any bar to entry for the would-be = attacker and doesn=92t meet the requirements as I understand them to = have been laid out. That is: > Location must be attributable and verifiable as belonging to a = specific end-point at the time a specific call is made. Ci2, as = currently proposed does do this. How are softphones different from ATAs? If he is in Singapour, he will get an IP address from Singapour, and = thus will get an DHCP location from Singapour. I do not see your point at all. Ci2 only bases its finding on the public IP address of the Call. If I = am behind VPN, we're toast. Say I am VPNing to my home and using my SIP PBX at home... which I do by = the way ;) > > > Further more the call needs to have originated from a local ISP or = the > > third-party request will fail. > > > > Why ? > [AJW] because if it does not, then the stage-1 routing proxy will fail = to resolve to a known LIS and request will get default treatment. This = sort of call can then be investigated. It will also fail in the case where an ISP is using a block of IP = addresses of another ISP, where it is impossible to register something = in ARIN. There are lots of blocks out there that are not 'clean'. This issue of involving ARIN has been over simplified by the ILECs in = Canada. > > How about adding digital signatures to DHCP 99/123 constructs that = can > > flow through from the PSAP MSAG to the end-points and can get = sent-back to > > the PSAP for authentication assessments? I am thinking of MIME = digital > > signatures of PIDF-LO constructs that can be stored in the memory of = end- > > points and can be sent back to the PSAP via the relationship between = the > > ILEC and the PSAP. > > > [AJW] As I have stated many times before, simply signing the location = isn=92t good enough. You need to bind it to the device making the call, = and you need to have a way of saying that the binding was still valid = when the call was made. Quite frankly I don=92t believe that this can be = done in any meaningful way using DHCP, and to the best of my knowledge I = haven=92t seen any proposal (even draft ones) that show how it can be = done. My question to you, is what is your aversion to doing this at the = application layer and avoid having to change all the home routers in the = path? OK, there is this new requirement 'you need to have a way to say that = the binding is valid at E-9-1-1 call time' In your statement, who is the entity referred to as 'you'. The ISP? The PSAP? The End-User? Our proposed legal requirement is not to have 'user-inputted' location. = There is no legal requirement for disallowing 'user-sent location if not = user-inputted'. I did not read this as being a requirement of ECRIT to deny end-to-end = 'user-sent but not user-inputted location'. OBO is not end-to-end. All IETF standards are supposed to be = end-to-end. Show me an OBO that will actually work and will preserve privacy. Ci2 = doesn't do any of these two basic criterias. a) if it is based on a public IP address it will not work all the time b) if it is based on a Hosted LIS, which will contain all public IP = addresses, it will not work period. > =20 > > And there will be no need that the ILEC provides a Hosted LIS and = knows > > the identity of customers on the Internet that may never call 9-1-1 = in > > their life. > [AJW] I am not a big fan of the ILEC hosted solution. As I understand = it, it was in fact the ISPs that asked for such an option to exist. = Quite frankly from my assessments any solution using this approach will = require as much equipment in their networks as putting a LIS in will, so = they may as well put the LIS in. Ci2 requires a LIS at the ILEC as well as a LIS at the ISP called a = Location Determination Platform. LDP LIS. Ci2 requires LIS to LIS communications utilizing HELD. HELD was never = designed for that. I am not even sure there is a current IETF draft which explains how to = use HELD or BEEP for that. An ISP LIS is to communicate to an ILEC LIS to retrieve location. This location could actually come over RADIUS and the wiremap only = reside in the ISP LIS. If you really want OBO, the only other option that I can see is to force = VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather = than one of the VoIP service provider and get into technical ITMPs = (Internet Traffic Management Practices). This way, no VoIP is allowed = unless granted by an ISP SIP PROXY where the OBO can be assessed by the = ISP. This seems to me as adverse to net neutrality.=20 It would be better to make end-to-end work. > > > > We need to re-state the concept of ECRIT as not requiring OBO... but = trust > > between PSAPs and End-points. > [AJW] I disagree. I actually think that the right place to put the = trust is between the ISP and the PSAP, and separate agreement exists = between the end-point and the ISP. The ISP is then responsible for who = he lets on to his network, and what they do when they are there. There is no option for such trust to exist in Ci2. There is no relationship between the ISP and the PSAP. One only exists = between the ISP and MaBell as an agent of the PSAPs. MaBell is requiring ISPs to divulge the public IP addresses of all = subscribers 24/7 just in case an E9-1-1 call ever gets made. This is the OBO proposal we have in Canada before the regulator. it = will be fought in court if ever mandated.=20 > [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed = PIDF-LOs. Check out = http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-04= it has been around for a very long time. > I will restress my position however, that I think ECRIT Direct and = Trusted third-party requests is the right approach for emergency = calling. Thanks for the pointer.=20 I fail to understand how signed PIDF-LO's, i.e. location objects that = the PSAP can reconcile at call time, as being MSAG-VALID, and failing to = reconcile at call time, can issue a dispatch knowing that it may take a = chance... do not make such information exchange 'trustable'. -=3DFrancois=3D- From James.Winterbottom@andrew.com Mon Nov 23 21:00:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C7A3A6B1D for ; Mon, 23 Nov 2009 21:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlKOfgQXwS4u for ; Mon, 23 Nov 2009 21:00:28 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id D608B3A6B38 for ; Mon, 23 Nov 2009 21:00:27 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:6030 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S81262AbZKXFAX (ORCPT ); Mon, 23 Nov 2009 23:00:23 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 23:00:22 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 24 Nov 2009 13:00:06 +0800 From: "Winterbottom, James" To: Francois D.Menard Date: Tue, 24 Nov 2009 13:00:04 +0800 Thread-Topic: [Ecrit] Nomadic VOIP is dead Thread-Index: AcpsqwaymXpn5JASQpiBmy4k6x+yigAAdRpQ Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> In-Reply-To: <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52SISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] Nomadic VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:00:42 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Please read the ECRIT Direct draft. It does not require a SIP Proxy in the = ISP. Other comments inline. > -----Original Message----- > From: Francois D.Menard [mailto:fmenard@xittelecom.com] > Sent: Tuesday, 24 November 2009 1:08 PM > To: Winterbottom, James > Cc: ecrit > Subject: Re: [Ecrit] Nomadic VOIP is dead > > > > You are saying that veracity needs to be assessed while a 9-1-1 call > is > > > being established? > > [AJW] Trusted third-party also eliminates the need to do a veracity > check at call time. So I only see this as another advantage. > > > > How is that different from end-to-end location download in the end-point > then? [AJW] Let me see. If the emergency service provider requests the location i= nformation directly from the source, versus trusting location that has trav= ersed and end-point, that as you continually point out could have been down= loaded from an open source site and modified. Hmmm!! Do you really see thes= e as being the same? I know I don't. > > If the veracity check is not done at call time, how is veracity is being > assessed? > > > > > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he > is > > > elsewhere on Earth, he will get a DHCP 99/123 with that information. > > > > [AJW] Absolutely wrong. He can have a softphone and be where ever he > wants to be and this is precisely the problem. You are not providing a > means to stop this kind of malicious calling, or any means to trace the > culprit. The solution does not provide any bar to entry for the would-be > attacker and doesn't meet the requirements as I understand them to have > been laid out. That is: > > Location must be attributable and verifiable as belonging to a specific > end-point at the time a specific call is made. Ci2, as currently proposed > does do this. > > > How are softphones different from ATAs? > > If he is in Singapour, he will get an IP address from Singapour, and thus > will get an DHCP location from Singapour. > > I do not see your point at all. [AJW] I know you don't. If you did you wouldn't be saying what you are sayi= ng. There is absolutely nothing stopping him from adding whatever location = he wants either directly into the device itself, or through the DHCP server= . There is no control in this case, and no means to check veracity, and no = bar to entry. Quite frankly anyone proposing this as a serious solution has= really not assessed the risks. The regulators that I have spoken to will n= ot support a proposal of this nature. > > Ci2 only bases its finding on the public IP address of the Call. If I am > behind VPN, we're toast. [AJW] Actually you might not be. The onus is on the VPN server end to ensur= e that you get proper connectivity for the applications you want to use. > > Say I am VPNing to my home and using my SIP PBX at home... which I do by > the way ;) [AJW] So perhaps nomadic VoIP is not as dead as you might be professing... = ;) > > > > > Further more the call needs to have originated from a local ISP or > the > > > third-party request will fail. > > > > > > Why ? > > [AJW] because if it does not, then the stage-1 routing proxy will fail > to resolve to a known LIS and request will get default treatment. This > sort of call can then be investigated. > > It will also fail in the case where an ISP is using a block of IP > addresses of another ISP, where it is impossible to register something in > ARIN. [AJW] Certainly when I was at the RIPE meeting a couple of months ago ARIN = and the APNIC guys seemed to think that this type of problem was far from i= nsurmountable. I don't propose to have a solution here, but those people th= at manage the database seemed to think that it could be solved. > > There are lots of blocks out there that are not 'clean'. > > This issue of involving ARIN has been over simplified by the ILECs in > Canada. > > > > How about adding digital signatures to DHCP 99/123 constructs that ca= n > > > flow through from the PSAP MSAG to the end-points and can get sent- > back to > > > the PSAP for authentication assessments? I am thinking of MIME > digital > > > signatures of PIDF-LO constructs that can be stored in the memory of > end- > > > points and can be sent back to the PSAP via the relationship between > the > > > ILEC and the PSAP. > > > > > [AJW] As I have stated many times before, simply signing the location > isn't good enough. You need to bind it to the device making the call, and > you need to have a way of saying that the binding was still valid when th= e > call was made. Quite frankly I don't believe that this can be done in any > meaningful way using DHCP, and to the best of my knowledge I haven't seen > any proposal (even draft ones) that show how it can be done. My question > to you, is what is your aversion to doing this at the application layer > and avoid having to change all the home routers in the path? > > OK, there is this new requirement 'you need to have a way to say that the > binding is valid at E-9-1-1 call time' > > In your statement, who is the entity referred to as 'you'. [AJW] This is not actually a new requirement it is a core requirement. The = you refers to the entity providing the location, and the entity ultimately = using the location to provide a service. > > The ISP? The PSAP? The End-User? > > Our proposed legal requirement is not to have 'user-inputted' location. > There is no legal requirement for disallowing 'user-sent location if not > user-inputted'. [AJW] Since for reasons previously stated there is no way in your proposal = to disseminate between the two, this split hair proposal that I think has v= ery little merit. Either you can verify it, or the solution can't, if you c= an't, then you should assume that it as user entered. > > I did not read this as being a requirement of ECRIT to deny end-to-end > 'user-sent but not user-inputted location'. > [AJW] I was under the impression that we were debating Ci2 and not ECRIT. H= aving said that, I believe that without a means to check location veracity = that a lot of regions will be reluctant to deploy what is currently being p= roposed. > OBO is not end-to-end. All IETF standards are supposed to be end-to-end. > [AJW] I would argue that IETF specifications are peer to peer, rather than = end to end per say. Consequently a Trusted Third-party location request is = peer to peer and so quite acceptable. > Show me an OBO that will actually work and will preserve privacy. Ci2 > doesn't do any of these two basic criterias. > [AJW] It is for exactly this reason that the term OBO is no longer used. It= is Trusted third-party, and the onus is on the trusted entity, and rules a= ssociated with that trust relationship. > a) if it is based on a public IP address it will not work all the time > b) if it is based on a Hosted LIS, which will contain all public IP > addresses, it will not work period. > > > > > > And there will be no need that the ILEC provides a Hosted LIS and > knows > > > the identity of customers on the Internet that may never call 9-1-1 i= n > > > their life. > > [AJW] I am not a big fan of the ILEC hosted solution. As I understand > it, it was in fact the ISPs that asked for such an option to exist. Quite > frankly from my assessments any solution using this approach will require > as much equipment in their networks as putting a LIS in will, so they may > as well put the LIS in. > > > Ci2 requires a LIS at the ILEC as well as a LIS at the ISP called a > Location Determination Platform. LDP LIS. > > Ci2 requires LIS to LIS communications utilizing HELD. HELD was never > designed for that. [AJW] As an original designer of HELD I can state quite categorically that = you are wrong. HELD was absolutely designed with this in mind. You might al= so care to look at: http://www.nena.org/standards/technical/voip/location-d= etermination-ip-based-emergency-services > > I am not even sure there is a current IETF draft which explains how to us= e > HELD or BEEP for that. http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-05 > > An ISP LIS is to communicate to an ILEC LIS to retrieve location. > > This location could actually come over RADIUS and the wiremap only reside > in the ISP LIS. > > If you really want OBO, the only other option that I can see is to force > VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather than > one of the VoIP service provider and get into technical ITMPs (Internet > Traffic Management Practices). This way, no VoIP is allowed unless > granted by an ISP SIP PROXY where the OBO can be assessed by the ISP. > > This seems to me as adverse to net neutrality. > [AJW] See above, this is not what is being described at all. > It would be better to make end-to-end work. > > > > > > > We need to re-state the concept of ECRIT as not requiring OBO... but > trust > > > between PSAPs and End-points. > > [AJW] I disagree. I actually think that the right place to put the trus= t > is between the ISP and the PSAP, and separate agreement exists between th= e > end-point and the ISP. The ISP is then responsible for who he lets on to > his network, and what they do when they are there. > > There is no option for such trust to exist in Ci2. > [AJW] Let's agree to disagree on this point. The ISP is providing service w= ithin the jurisdiction of a PSAP. Ci2, as I understand it, proposes that if= the ISP has a LIS, that the Stage-1 routing proxy has a VPN connection to = the LIS over which third-party requests are made. How can this VPN be estab= lished without a trust agreement being in place? > There is no relationship between the ISP and the PSAP. One only exists > between the ISP and MaBell as an agent of the PSAPs. [AJW] If Bell is operating as the agent for the PSAP then it is still repre= senting the PSAP is it not? > > MaBell is requiring ISPs to divulge the public IP addresses of all > subscribers 24/7 just in case an E9-1-1 call ever gets made. [AJW] This is not true if the ISP elects to run the LIS. Also what you are = not making clear, is that if the ISP runs a LIS there is nothing that stops= the ISP from making this location available to end-points so that they can= use it. The only thing that Ci2 says is that for now we won't use device-p= rovided location for emergency calling because we have no way to test it ve= racity. These all seem very reasonable approaches to me. > > This is the OBO proposal we have in Canada before the regulator. it will > be fought in court if ever mandated. [AJW] That would be a pity and certainly not in the best interests of the p= ublic. > > > [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. > Check out http://tools.ietf.org/html/draft-thomson-geopriv-location- > dependability-04 it has been around for a very long time. > > I will restress my position however, that I think ECRIT Direct and > Trusted third-party requests is the right approach for emergency calling. > > Thanks for the pointer. > > I fail to understand how signed PIDF-LO's, i.e. location objects that the > PSAP can reconcile at call time, as being MSAG-VALID, and failing to > reconcile at call time, can issue a dispatch knowing that it may take a > chance... do not make such information exchange 'trustable'. [AJW] I don't understand what you are trying say here. My point is that cal= ls that come with location that cannot be validated may get a completely di= fferent call handling procedure to those that can be verified. Providing a = single consistent means to verify location means that this can be done much= more efficiently. > > -=3DFrancois=3D- > --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 

Please read the ECRIT Direct draft. It does not require a SIP Proxy= in the ISP.

 

Other comments inline.

 

> -----Original Message-----

> From: Francois D.Menard [mailto:fmenard@xittelecom.com]

> Sent: Tuesday, 24 November 20= 09 1:08 PM

> To: Winterbottom, James

> Cc: ecrit

> Subject: Re: [Ecrit] Nomadic = VOIP is dead

>

> > > You are saying that veracity needs to be assessed wh= ile a 9-1-1 call

> is

> > > being established?

> > [AJW] Trusted third-party also eliminates the need to do = a veracity

> check at call time. So I only see this as another advantage.

> >

>

> How is that different from end-to-end location download in the end-point

> then?

<= span style=3D'font-size:10.0pt;color:black'> 

[AJW] Let me see. If= the emergency service provider requests the location information directly from = the source, versus trusting location that has traversed and end-point, that as = you continually point out could have been downloaded from an open source site a= nd modified. Hmmm!! Do you really see these as being the same? I know I don= 217;t.

>

> If the veracity check is not done at call time, how is veracit= y is being

> assessed?

> >

> > > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he

> is

> > > elsewhere on Earth, he will get a DHCP 99/123 with t= hat information.

> >

> > [AJW] Absolutely wrong. He can have a softphone and be wh= ere ever he

> wants to be and this is precisely the problem. You are not providing a

> means to stop this kind of malicious calling, or any means to trace the

> culprit. The solution does not provide any bar to entry for th= e would-be

> attacker and doesn’t meet the requirements as I understa= nd them to have

> been laid out. That is:

> > Location must be attributable and verifiable as belonging= to a specific

> end-point at the time a specific call is made. Ci2, as current= ly proposed

> does do this.

>

>

> How are softphones  different from ATAs?

>

> If he is in Singapour, he will get an IP address from Singapou= r, and thus

> will get an DHCP location from Singapour.

>

> I do not see your point at all.

[AJW] I know you don= ’t. If you did you wouldn’t be saying what you are saying. There is absol= utely nothing stopping him from adding whatever location he wants either directly into the device itself, or through the DHCP server. There is no control in = this case, and no means to check veracity, and no bar to entry. Quite frankly an= yone proposing this as a serious solution has really not assessed the risks. The regulators that I have spoken to will not support a proposal of this nature= .

<= span style=3D'font-size:10.0pt;color:black'> 

<= span style=3D'font-size:10.0pt;color:black'> 

>

> Ci2 only bases its finding on the public IP address of the Call.  If I am

> behind VPN, we're toast.

[AJW] Actually you m= ight not be. The onus is on the VPN server end to ensure that you get proper con= nectivity for the applications you want to use.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> Say I am VPNing to my home and using my SIP PBX at home... whi= ch I do by

> the way ;)

[AJW] So perhaps nom= adic VoIP is not as dead as you might be professing… ;)

<= span style=3D'font-size:10.0pt;color:black'> 

>

> > > > Further more the call needs to have originated = from a local ISP or

> the

> > > third-party request will fail.

> > >

> > > Why ?

> > [AJW] because if it does not, then the stage-1 routing pr= oxy will fail

> to resolve to a known LIS and request will get default treatme= nt. This

> sort of call can then be investigated.

>

> It will also fail in the case where an ISP is using a block of= IP

> addresses of another ISP, where it is impossible to register something in

> ARIN.

[AJW] Certainly when= I was at the RIPE meeting a couple of months ago ARIN and the APNIC guys seemed t= o think that this type of problem was far from insurmountable. I don’t propose to have a solution here, but those people that manage the database = seemed to think that it could be solved.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> There are lots of blocks out there that are not 'clean'.

>

> This issue of involving ARIN has been over simplified by the I= LECs in

> Canada<= /st1:place>.

>

> > > How about adding digital signatures to DHCP 99/123 constructs that can

> > > flow through from the PSAP MSAG to the end-points an= d can get sent-

> back to

> > > the PSAP for authentication assessments?  I am thinking of MIME

> digital

> > > signatures of PIDF-LO constructs that can be stored = in the memory of

> end-

> > > points and can be sent back to the PSAP via the relationship between

> the

> > > ILEC and the PSAP.

> > >

> > [AJW] As I have stated many times before, simply signing = the location

> isn’t good enough. You need to bind it to the device mak= ing the call, and

> you need to have a way of saying that the binding was still va= lid when the

> call was made. Quite frankly I don’t believe that this c= an be done in any

> meaningful way using DHCP, and to the best of my knowledge I haven’t seen

> any proposal (even draft ones) that show how it can be done. M= y question

> to you, is what is your aversion to doing this at the applicat= ion layer

> and avoid having to change all the home routers in the path?

>

> OK, there is this new requirement 'you need to have a way to s= ay that the

> binding is valid at E-9-1-1 call time'

>

> In your statement, who is the entity referred to as 'you'.

[AJW] This is not ac= tually a new requirement it is a core requirement. The you refers to the entity providing the location, and the entity ultimately using the location to pro= vide a service.

>

> The ISP? The PSAP? The End-User?

>

> Our proposed legal requirement is not to have 'user-inputted' location.

> There is no legal requirement for disallowing 'user-sent locat= ion if not

> user-inputted'.

[AJW] Since for reas= ons previously stated there is no way in your proposal to disseminate between t= he two, this split hair proposal that I think has very little merit. Either yo= u can verify it, or the solution can’t, if you can’t, then you sh= ould assume that it as user entered.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> I did not read this as being a requirement of ECRIT to deny end-to-end

> 'user-sent but not user-inputted location'.

> 

[AJW] I was under th= e impression that we were debating Ci2 and not ECRIT. Having said that, I bel= ieve that without a means to check location veracity that a lot of regions will = be reluctant to deploy what is currently being proposed.

 

 

> OBO is not end-to-end.  All IETF standards are supposed t= o be end-to-end.

>

[AJW] I would argue = that IETF specifications are peer to peer, rather than end to end per say. Conse= quently a Trusted Third-party location request is peer to peer and so quite accepta= ble.

<= span style=3D'font-size:10.0pt;color:black'> 

> Show me an OBO that will actually work and will preserve priva= cy.  Ci2

> doesn't do any of these two basic criterias.

> 

[AJW] It is for exac= tly this reason that the term OBO is no longer used. It is Trusted third-party,= and the onus is on the trusted entity, and rules associated with that trust rel= ationship.

 

> a) if it is based on a public IP address it will not work all = the time

> b) if it is based on a Hosted LIS, which will contain all publ= ic IP

> addresses, it will not work period.

>

> >

> > > And there will be no need that the ILEC provides a Hosted LIS and

> knows

> > > the identity of customers on the Internet that may n= ever call 9-1-1 in

> > > their life.

> > [AJW] I am not a big fan of the ILEC hosted solution. As = I understand

> it, it was in fact the ISPs that asked for such an option to exist. Quite

> frankly from my assessments any solution using this approach w= ill require

> as much equipment in their networks as putting a LIS in will, = so they may

> as well put the LIS in.

>

>

> Ci2 requires a LIS at the ILEC as well as a LIS at the ISP cal= led a

> Location Determination Platform.  LDP LIS.<= /p>

>

> Ci2 requires LIS to LIS communications utilizing HELD. HELD wa= s never

> designed for that.

[AJW] As an original designer of HELD I can state quite categorically that you are wrong. HELD w= as absolutely designed with this in mind. You might also care to look at: http://www.nena.org/standards/technical/voip/= location-determination-ip-based-emergency-services

 

>

> I am not even sure there is a current IETF draft which explain= s how to use

> HELD or BEEP for that.

http= ://tools.ietf.org/html/draft-thomson-geopriv-held-beep-05

<= span style=3D'font-size:10.0pt;color:black'> 

>

> An ISP LIS is to communicate to an ILEC LIS to retrieve locati= on.

>

> This location could actually come over RADIUS and the wiremap = only reside

> in the ISP LIS.

>

> If you really want OBO, the only other option that I can see i= s to force

> VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather than

> one of the VoIP service provider and get into technical ITMPs (Internet

> Traffic Management Practices).   This way, no VoIP i= s allowed unless

> granted by an ISP SIP PROXY where the OBO can be assessed by t= he ISP.

>

> This seems to me as adverse to net neutrality.

> 

[AJW] See above, thi= s is not what is being described at all.

 

 

> It would be better to make end-to-end work.

>

> > >

> > > We need to re-state the concept of ECRIT as not requ= iring OBO... but

> trust

> > > between PSAPs and End-points.

> > [AJW] I disagree. I actually think that the right place t= o put the trust

> is between the ISP and the PSAP, and separate agreement exists between the

> end-point and the ISP. The ISP is then responsible for who he = lets on to

> his network, and what they do when they are there.

>

> There is no option for such trust to exist in Ci2.

> 

[AJW] Let’s ag= ree to disagree on this point. The ISP is providing service within the jurisdictio= n of a PSAP. Ci2, as I understand it, proposes that if the ISP has a LIS, that t= he Stage-1 routing proxy has a VPN connection to the LIS over which third-part= y requests are made. How can this VPN be established without a trust agreemen= t being in place?

 

> There is no relationship between the ISP and the PSAP.  O= ne only exists

> between the ISP and MaBell as an agent of the PSAPs.

[AJW] If Bell is operating as the agent for the = PSAP then it is still representing the PSAP is it not?<= /b>

<= span style=3D'font-size:10.0pt;color:black'> 

>

> MaBell is requiring ISPs to divulge the public IP addresses of= all

> subscribers 24/7 just in case an E9-1-1 call ever gets made.

[AJW] This is not tr= ue if the ISP elects to run the LIS. Also what you are not making clear, is that = if the ISP runs a LIS there is nothing that stops the ISP from making this location available to end-points so that they can use it. The only thing th= at Ci2 says is that for now we won’t use device-provided location for emergency calling because we have no way to test it veracity. These all see= m very reasonable approaches to me.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> This is the OBO proposal we have in Canada before the regulator.&= nbsp; it will

> be fought in court if ever mandated.<= /p>

[AJW] That would be = a pity and certainly not in the best interests of the public.

>

> > [AJW] version 1.0 of HELD (5 or is it 6 years ago) had si= gned PIDF-LOs.

> Check out http://tools.ietf.org/html/draft-thomson-geopriv-location-

> dependability-04 it has been around for a very long time.

> > I will restress my position however, that I think ECRIT Direct and

> Trusted third-party requests is the right approach for emergen= cy calling.

>

> Thanks for the pointer.

>

> I fail to understand how signed PIDF-LO's, i.e. location objec= ts that the

> PSAP can reconcile at call time, as being MSAG-VALID, and fail= ing to

> reconcile at call time, can issue a dispatch knowing that it m= ay take a

> chance... do not make such information exchange 'trustable'.

[AJW] I don’t understand what you are trying say here. My point is that calls that come w= ith location that cannot be validated may get a completely different call handl= ing procedure to those that can be verified. Providing a single consistent mean= s to verify location means that this can be done much more efficiently.

<= span style=3D'font-size:10.0pt;color:black'> 

>

> -=3DFrancois=3D-

>

 

--_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52SISPE7MB1co_-- From fmenard@xittelecom.com Mon Nov 23 21:17:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4725C3A6B42 for ; Mon, 23 Nov 2009 21:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEV5E3HLaGuR for ; Mon, 23 Nov 2009 21:17:31 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 65FFF3A6B3C for ; Mon, 23 Nov 2009 21:17:30 -0800 (PST) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCnmI-0004uX-1b; Tue, 24 Nov 2009 00:17:26 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCnmH-0001fn-Th; Tue, 24 Nov 2009 00:17:26 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> Date: Tue, 24 Nov 2009 00:17:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E @SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: [Ecrit] ECRIT is not end-to-end? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:17:32 -0000 > =20 > > OBO is not end-to-end. All IETF standards are supposed to be = end-to-end. > > > [AJW] I would argue that IETF specifications are peer to peer, rather = than end to end per say. Consequently a Trusted Third-party location = request is peer to peer and so quite acceptable. OK, so if I get this right there are 5 peers in a single E-9-1-1 = transaction involving Ci2. Lets call them 1, 2, 3, 4 & 5 1) The end-point requesting emergency calls 2) The SIP proxy of the voice-over-ip service provider 3) The SIP proxy of the emergency service provider (in our case, the = ILEC) 4) The LIS of the ILEC 5) The LIS of the ISP So for veracity to be assessed=20 For every E-9-1-1 call 1 sends an invite to 2 2 sends an invite to 3 3 sends a HELD request to 4 4 sends a HELD request to 5 5 responds to 4 4 responds to 3 3 responds to 2 2 responds to 1 3 is not on the public Internet 4 is not on the public Internet 5 is not on the public Internet And all of this is peer to peer ;) I am confused! If this is superior to end-to-end, because regulators want a double = check on location because PSAPs are not willing to trust anything = downloaded to end-points, even PIDF-LO's that they can recognize MSAG = VALID... then perhaps we actually need a policy debate on their = requirement. And since you profess that I am the one saying VoIP is dead, I changed = the topic. f. From James.Winterbottom@andrew.com Mon Nov 23 21:42:49 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030E63A6862 for ; Mon, 23 Nov 2009 21:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ljG6AbzstYu for ; Mon, 23 Nov 2009 21:42:48 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 888873A6995 for ; Mon, 23 Nov 2009 21:42:47 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:29590 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S81294AbZKXFmn convert rfc822-to-8bit (ORCPT ); Mon, 23 Nov 2009 23:42:43 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 23:42:43 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 24 Nov 2009 13:42:31 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Tue, 24 Nov 2009 13:42:29 +0800 Thread-Topic: ECRIT is not end-to-end? Thread-Index: AcpsxaZxRlmBoPO9QAC099dEU1Aa8QAAhpTg Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC8C@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] ECRIT is not end-to-end? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:42:49 -0000 I think you have missed the point, and I think you call flow is mixed up, unless you are using a hosted LIS solution, which is something that I don't particularly like and is not mandated for use in Ci2. In any case, veracity of location is achieved using a third-party request from, in the ci2 case, the stage-1 routing-proxy to the ISP LIS (though I agree this could be the hosted LIS). The ISP LIS is obliged to provide the location it has for the IP address, and it is obliged to make sure that that is as correct as can be. How it determines that is a different problem. The request and response between the stage-1 routing-proxy and the ISP-LIS is a peer to peer relationship. Request and response. I will actually go one step further and say that the stage-1 routing proxy is in fact and ESRP, and that most if not all ESRPs that I am aware of are being implemented as B2BUAs, so the termination point in your end-to-end model is in fact the stage-1 routing-proxy or ESRP, making Ci2 perfectly fine. Cheers James > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Tuesday, 24 November 2009 4:17 PM > To: Winterbottom, James > Cc: ecrit > Subject: ECRIT is not end-to-end? > > > > > > OBO is not end-to-end. All IETF standards are supposed to be end-to- > end. > > > > > [AJW] I would argue that IETF specifications are peer to peer, rather > than end to end per say. Consequently a Trusted Third-party location > request is peer to peer and so quite acceptable. > > OK, so if I get this right there are 5 peers in a single E-9-1-1 > transaction involving Ci2. > > Lets call them 1, 2, 3, 4 & 5 > > 1) The end-point requesting emergency calls > > 2) The SIP proxy of the voice-over-ip service provider > > 3) The SIP proxy of the emergency service provider (in our case, the ILEC) > > 4) The LIS of the ILEC > > 5) The LIS of the ISP > > So for veracity to be assessed > > For every E-9-1-1 call > > 1 sends an invite to 2 > 2 sends an invite to 3 > 3 sends a HELD request to 4 > 4 sends a HELD request to 5 > 5 responds to 4 > 4 responds to 3 > 3 responds to 2 > 2 responds to 1 > > 3 is not on the public Internet > 4 is not on the public Internet > 5 is not on the public Internet > > And all of this is peer to peer ;) > > I am confused! > > If this is superior to end-to-end, because regulators want a double check > on location because PSAPs are not willing to trust anything downloaded to > end-points, even PIDF-LO's that they can recognize MSAG VALID... then > perhaps we actually need a policy debate on their requirement. > > And since you profess that I am the one saying VoIP is dead, I changed the > topic. > > f. > From fmenard@xittelecom.com Mon Nov 23 21:48:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D4C3A67A7 for ; Mon, 23 Nov 2009 21:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzEPDMgDQiZ4 for ; Mon, 23 Nov 2009 21:48:38 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 1309C3A67B4 for ; Mon, 23 Nov 2009 21:48:38 -0800 (PST) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCoGP-0002DD-8Q; Tue, 24 Nov 2009 00:48:33 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCoGO-00036O-Kk; Tue, 24 Nov 2009 00:48:33 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC8C@SISPE7MB1.commscope.com> Date: Tue, 24 Nov 2009 00:48:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <074FB4E1-185D-4610-9289-A993148EDDCE@xittelecom.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E @SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC8C@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] ECRIT is not end-to-end? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:48:39 -0000 > I think you have missed the point, and I think you call flow is mixed = up, unless you are using a hosted LIS solution, which is something that = I don't particularly like and is not mandated for use in Ci2. >=20 I do not believe that I am mixed up and yes, I am using the hosted LIS = call flow. BTW, hosted LIS is the only implementation of Ci2 currently costed and = promoted by the ILECs to the CRTC. While it may not be mandated, the ILECs have made it cost prohibitive = for ASPs to have their own LIS. > In any case, veracity of location is achieved using a third-party = request from, in the ci2 case, the stage-1 routing-proxy to the ISP LIS = (though I agree this could be the hosted LIS). The ISP LIS is obliged to = provide the location it has for the IP address, and it is obliged to = make sure that that is as correct as can be. How it determines that is a = different problem. Is there any other possible key than a public IP address? > The request and response between the stage-1 routing-proxy and the = ISP-LIS is a peer to peer relationship. Request and response. >=20 a peer-to-peer relationship not on the public Internet that is... > I will actually go one step further and say that the stage-1 routing = proxy is in fact and ESRP, and that most if not all ESRPs that I am = aware of are being implemented as B2BUAs, so the termination point in = your end-to-end model is in fact the stage-1 routing-proxy or ESRP, = making Ci2 perfectly fine. >=20 its not end-to-end, as the ESRP of the Stage-1 proxy is not on the = public internet in Ci2... its only accessible via direct interconnection = between a voice-over-IP service provider and the ILEC as an agent to the = PSAPs in Ci2. Do I have the call flow down path? f. > Cheers > James >=20 >=20 >> -----Original Message----- >> From: Francois D. Menard [mailto:fmenard@xittelecom.com] >> Sent: Tuesday, 24 November 2009 4:17 PM >> To: Winterbottom, James >> Cc: ecrit >> Subject: ECRIT is not end-to-end? >>=20 >>>=20 >>>> OBO is not end-to-end. All IETF standards are supposed to be = end-to- >> end. >>>>=20 >>> [AJW] I would argue that IETF specifications are peer to peer, = rather >> than end to end per say. Consequently a Trusted Third-party location >> request is peer to peer and so quite acceptable. >>=20 >> OK, so if I get this right there are 5 peers in a single E-9-1-1 >> transaction involving Ci2. >>=20 >> Lets call them 1, 2, 3, 4 & 5 >>=20 >> 1) The end-point requesting emergency calls >>=20 >> 2) The SIP proxy of the voice-over-ip service provider >>=20 >> 3) The SIP proxy of the emergency service provider (in our case, the = ILEC) >>=20 >> 4) The LIS of the ILEC >>=20 >> 5) The LIS of the ISP >>=20 >> So for veracity to be assessed >>=20 >> For every E-9-1-1 call >>=20 >> 1 sends an invite to 2 >> 2 sends an invite to 3 >> 3 sends a HELD request to 4 >> 4 sends a HELD request to 5 >> 5 responds to 4 >> 4 responds to 3 >> 3 responds to 2 >> 2 responds to 1 >>=20 >> 3 is not on the public Internet >> 4 is not on the public Internet >> 5 is not on the public Internet >>=20 >> And all of this is peer to peer ;) >>=20 >> I am confused! >>=20 >> If this is superior to end-to-end, because regulators want a double = check >> on location because PSAPs are not willing to trust anything = downloaded to >> end-points, even PIDF-LO's that they can recognize MSAG VALID... then >> perhaps we actually need a policy debate on their requirement. >>=20 >> And since you profess that I am the one saying VoIP is dead, I = changed the >> topic. >>=20 >> f. >>=20 >=20 From James.Winterbottom@andrew.com Mon Nov 23 21:56:21 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548DE3A6B4E for ; Mon, 23 Nov 2009 21:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdczg4h8Eqbu for ; Mon, 23 Nov 2009 21:56:20 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7E3DB3A6782 for ; Mon, 23 Nov 2009 21:56:20 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:31895 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S81311AbZKXF4Q (ORCPT ); Mon, 23 Nov 2009 23:56:16 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 23:56:16 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 24 Nov 2009 13:56:12 +0800 From: "Winterbottom, James" To: "Francois D. Menard" Date: Tue, 24 Nov 2009 13:56:11 +0800 Thread-Topic: ECRIT is not end-to-end? Thread-Index: AcpsydHBdbDiSoWLT1a0yge4tGtt2gAAHZ0A Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9E@SISPE7MB1.commscope.com> References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E@SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC8C@SISPE7MB1.commscope.com> <074FB4E1-185D-4610-9289-A993148EDDCE@xittelecom.com> In-Reply-To: <074FB4E1-185D-4610-9289-A993148EDDCE@xittelecom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9ESISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit Subject: Re: [Ecrit] ECRIT is not end-to-end? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:56:21 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9ESISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Can you explain the fragment below please? Cheers James > > BTW, hosted LIS is the only implementation of Ci2 currently costed and > promoted by the ILECs to the CRTC. > > While it may not be mandated, the ILECs have made it cost prohibitive fo= r > ASPs to have their own LIS. > [AJW] If the hosted LIS is the only proposal costed, then how can the ILECs= have priced ISP LIS ownership out of existence? Are there indicative connection costs being quoted? --_000_5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9ESISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 

Can you explain the fragment below please?=

 

Cheers

James

 

>

> BTW, hosted LIS is the only implementation of Ci2 currently co= sted and

> promoted by the ILECs to the CRTC.

>

> While it may not be mandated, the ILECs have made it  cos= t prohibitive for

> ASPs to have their own LIS.

>

[AJW] If the hosted = LIS is the only proposal costed, then how can the ILECs have priced ISP LIS owners= hip out of existence?

Are there indicative connection costs being quoted?

References: To: Marc Linsner MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 24 Nov 2009 10:10:30 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/11/2009 10:10:31 AM, Serialize complete at 24/11/2009 10:10:31 AM Content-Type: multipart/alternative; boundary="=_alternative 0037E52580257678_=" Cc: ecrit Subject: Re: [Ecrit] Trustworthy Location Information X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 10:10:40 -0000 This is a multipart message in MIME format. --=_alternative 0037E52580257678_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > Those pushing for complex mechanisms (?trusted third party?) under=20 > the guise of not trusting location from an end-point/end-user are=20 > simply attempting to protect a particular business model. I do hope that's a "no hat" comment, because if it wasn't it was=20 *seriously* out-of-order. Ray --=_alternative 0037E52580257678_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > Those pushing for complex mechanisms (‘trusted third party’) under
> the guise of not trusting location from an end-point/end-user are
> simply attempting to protect a particular business model.
I do hope that's a "no hat" comment, becau= se if it wasn't it was *seriously* out-of-order.

Ray
--=_alternative 0037E52580257678_=-- From fmenard@xittelecom.com Tue Nov 24 04:25:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B7128C107 for ; Tue, 24 Nov 2009 04:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esL2c-qdVJAg for ; Tue, 24 Nov 2009 04:25:24 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 128C23A6A42 for ; Tue, 24 Nov 2009 04:25:23 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCuSM-0004HZ-Ds; Tue, 24 Nov 2009 07:25:18 -0500 Received: from [207.96.236.165] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NCuSL-0001I9-PA; Tue, 24 Nov 2009 07:25:18 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9E@SISPE7MB1.commscope.com> Date: Tue, 24 Nov 2009 07:25:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1258749246.5943.62.camel@linux-k6vx.site> <8286429B-EA14-40CE-B562-25F2DEFD0921@bbn.com> <1258757367.3212.43.camel@linux-k6vx.site>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B28@SISPE7MB1.commscope.com>, <2F2F1DE2-9A14-480E-88EC-E38D5E5FBB77@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B29@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B2A@SISPE7MB1.commscope.com> <788F360A-E136-43B3-B221-18B8683DB09F@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A60C@SISPE7MB1.commscope.com> <7B863484-31B2-4B13-8DDF-1AEB9BC7EA4A@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A6F3@SISPE7MB1.commscope.com> <4117E2E3-9B1A-483C-B286-59B40343C184@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A810@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88A87E @SISPE7MB1.commscope.com> <317A9C67-AE8F-4498-B5B3-E36ECFE4D825@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC52@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC8C@SISPE7MB1.commscope.com> <074FB4E1-185D-4610-9289-A993148EDDCE@xittelecom.com> <5A55A45AE77F5941B18E5457ECAC8188011EBB88AC9E@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] ECRIT is not end-to-end? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:25:25 -0000 See: http://www.crtc.gc.ca/public/partvii/2007/8663/c12_200717738/898632.zip Bell Canada intends to charge for an ASP who is also a VISP: $10,700 per year for ISP LIS and $5400 per year for hosted LIS. Bell Aliant for the Maritimes, for or an ASP who is also a VISP: $46,100 per year for ISP LIS and $19,000 per year for hosted LIS=20 There isin't one service provider out there in Canada that can afford = this. and in the latter case, also $68 per month per subscriber as well on top = of it;) $81 per month per sub for a business case I'm trying to make happen = based on 300 subscribers in one province. At least with end-to-end location download, there is still hope that the = thing will be affordable. The ILECs did provide incentives not to have several ASPs entertain use = of their own LIS. F. On 2009-11-24, at 12:56 AM, Winterbottom, James wrote: > Hi Francois, > =20 > Can you explain the fragment below please? > =20 > Cheers > James > =20 > > > > BTW, hosted LIS is the only implementation of Ci2 currently costed = and > > promoted by the ILECs to the CRTC. > > > > While it may not be mandated, the ILECs have made it cost = prohibitive for > > ASPs to have their own LIS. > > > [AJW] If the hosted LIS is the only proposal costed, then how can the = ILECs have priced ISP LIS ownership out of existence? > Are there indicative connection costs being quoted? > =20 > =20 From rbarnes@bbn.com Tue Nov 24 06:35:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583C73A6A84 for ; Tue, 24 Nov 2009 06:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqB+J-2+y+aV for ; Tue, 24 Nov 2009 06:35:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E69083A6A7F for ; Tue, 24 Nov 2009 06:35:25 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NCwUB-0006Ph-Ad; Tue, 24 Nov 2009 09:35:19 -0500 Message-Id: <7BCE4D5F-0455-4F59-95D3-B80D003A749B@bbn.com> From: Richard Barnes To: "DRAGE, Keith (Keith)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--554238808 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 09:35:18 -0500 References: <4B0AF639.7020501@cs.columbia.edu> X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:35:27 -0000 --Apple-Mail-1--554238808 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The problem here is that SMS is a page-mode medium that's used for session-mode-style conversations (see, e.g., the iPhone SMS interface). So if you're going to gateway SMS into SIP and preserve these pseudo-sessions, you either have to do something like what this draft does, or you have to somehow have the gateway create sessions and map SMS messages into them. I'm not immediately sure which would be a better solution, but using MESSAGE seems marginally more light- weight. --Richard On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote: > So did I read this correctly. > > You are essentially saying you want to use page mode messaging to do > session mode messaging? > > Didn't SIMPLE investigate that path and reject it and go for MSRP as > the solution to session mode messaging? > > Why does emergency calling suddenly make the original decision > making process in SIMPLE redundant? > > regards > > Keith > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Wonsang Song > Sent: Monday, November 23, 2009 8:53 PM > To: ecrit@ietf.org > Subject: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit- > text-00] > > Hi, > > Just wanted to send a note about a new draft on using SIP MESSAGE > for emergency texting. > > The draft is an outcome of the collaboration between Columbia > University and Verizon to build an emergency texting prototype > system which allows people to use IM and SMS to "call" for emergency > help. > > If you have comments or questions, please let me know. > > Thank you, > Wonsang Song > > > -------- Original Message -------- > Subject: New Version Notification for draft-kim-ecrit-text-00 > Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) > From: IETF I-D Submission Tool > To: jyk@cs.columbia.edu > CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, > p.boni@verizon.com, michael.g.armstrong@verizon.com > > > A new version of I-D, draft-kim-ecrit-text-00.txt has been > successfuly submitted by Jong Yul Kim and posted to the IETF > repository. > > Filename: draft-kim-ecrit-text > Revision: 00 > Title: Emergency Text Messaging using SIP MESSAGE > Creation_date: 2009-11-16 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > This memo describes best current practices on how to use the SIP > MESSAGE method for emergency text messaging from citizen and visitors > to authorities. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 20, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-1--554238808 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The problem here is that SMS is = a page-mode medium that's used for session-mode-style conversations = (see, e.g., the iPhone SMS interface).  So if you're going to = gateway SMS into SIP and preserve these pseudo-sessions, you either have = to do something like what this draft does, or you have to somehow have = the gateway create sessions and map SMS messages into them.  I'm = not immediately sure which would be a better solution, but using MESSAGE = seems marginally more = light-weight.


--Richard




On Nov 23, 2009, at 8:34 PM, DRAGE, = Keith (Keith) wrote:

So did I read this = correctly.
 
You are essentially saying you want to use = page mode messaging to do session mode messaging?
=
 
=
Didn't SIMPLE investigate = that path and reject it and go for MSRP as the solution to session mode = messaging?
 
Why does emergency calling suddenly make = the original decision making process in SIMPLE = redundant?
 
regards
 
Keith

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Wonsang Song
Sent: Monday, November 23, = 2009 8:53 PM
To: ecrit@ietf.org
Subject: = [Ecrit] [Fwd: New Version Notification for = draft-kim-ecrit-text-00]

=
Hi,

Just wanted to send a note about a new draft on = using SIP MESSAGE for emergency texting.

The draft is an = outcome of the collaboration between Columbia University and Verizon = to build an emergency texting prototype system which allows people to = use IM and SMS to "call" for emergency help.

If you have = comments or questions, please let me know.

Thank = you,
Wonsang Song


-------- Original Message = --------
Subject: New Version Notification for = draft-kim-ecrit-text-00
Date: Tue, 17 Nov 2009 11:55:17 -0800 = (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>To: jyk@cs.columbia.edu
CC: wonsang@cs.columbia.edu, = hgs@cs.columbia.edu, p.boni@verizon.com, =      michael.g.armstrong@verizo= n.com


A new version of I-D, draft-kim-ecrit-text-00.txt = has been successfuly submitted by Jong Yul Kim and posted to the IETF = repository.

Filename: =  draft-kim-ecrit-text
Revision: =  00
Title:  Emergency Text Messaging using = SIP MESSAGE
Creation_date:  2009-11-16
WG ID:  Independent Submission
Number_of_pages: = 11

Abstract:
This memo describes best current practices on = how to use the SIP
MESSAGE method for emergency text messaging from = citizen and visitors
to authorities.

Status of this = Memo

This Internet-Draft is submitted to IETF in full conformance = with the
provisions of BCP 78 and BCP 79.

Internet-Drafts = are working documents of the Internet Engineering
Task Force = (IETF), its areas, and its working groups.  Note that
other = groups may also distribute working documents as = Internet-
Drafts.

Internet-Drafts are draft documents valid = for a maximum of six months
and may be updated, replaced, or = obsoleted by other documents at any
time.  It is inappropriate = to use Internet-Drafts as reference
material or to cite them other = than as "work in progress."

The list of current Internet-Drafts = can be accessed at
http://www.ietf.org/ie= tf/1id-abstracts.txt.

The list of Internet-Draft Shadow = Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 20, = 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and = the persons identified as the
document authors.  All rights = reserved.

This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/lice= nse-info) in effect on the date of
publication of this = document.  Please review these documents
carefully, as they = describe your rights and restrictions with respect
to this = document.  Code Components extracted from this document = must
include Simplified BSD License text as described in Section = 4.e of
the Trust Legal Provisions and are provided without warranty = as
described in the BSD License.



The IETF Secretariat. =
=




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

= --Apple-Mail-1--554238808-- From drage@alcatel-lucent.com Tue Nov 24 06:46:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57573A690D for ; Tue, 24 Nov 2009 06:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL2Sek3NpgaF for ; Tue, 24 Nov 2009 06:46:10 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 471923A6A85 for ; Tue, 24 Nov 2009 06:46:10 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAOEjYQb032185 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 15:45:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 24 Nov 2009 15:45:41 +0100 From: "DRAGE, Keith (Keith)" To: Richard Barnes Date: Tue, 24 Nov 2009 15:45:38 +0100 Thread-Topic: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] Thread-Index: AcptE2KUmGBQYNayQs6IZ8nacjiy3QAAKn7Q Message-ID: References: <4B0AF639.7020501@cs.columbia.edu> <7BCE4D5F-0455-4F59-95D3-B80D003A749B@bbn.com> In-Reply-To: <7BCE4D5F-0455-4F59-95D3-B80D003A749B@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE209C57E86FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: ecrit Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:46:12 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE209C57E86FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But... The use case under discussion here is an end entity running LOST (and there= fore presumably an IP terminal) communicating with an IP connected PSAP, an= d therefore not involving any SMS at all. Therefore for this use case, the = endpoints presumably have the full range of choice of standardised messagin= g mechanisms as defined by IETF. If you did want to extend the use case to SMS, I would also content that th= e current standardised SMS to SIP based IM mechanisms would break the solut= ion suggested here as well. (Also ignoring the fact as well that current SMS is by default deferred del= ivery (i.e. delivered in the operator's own time and when the recipient is = available, and therefore not suitable for emergency calls in the first plac= e.) Keith ________________________________ From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, November 24, 2009 2:35 PM To: DRAGE, Keith (Keith) Cc: ecrit Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-tex= t-00] The problem here is that SMS is a page-mode medium that's used for session-= mode-style conversations (see, e.g., the iPhone SMS interface). So if you'= re going to gateway SMS into SIP and preserve these pseudo-sessions, you ei= ther have to do something like what this draft does, or you have to somehow= have the gateway create sessions and map SMS messages into them. I'm not = immediately sure which would be a better solution, but using MESSAGE seems = marginally more light-weight. --Richard On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote: So did I read this correctly. You are essentially saying you want to use page mode messaging to do sessio= n mode messaging? Didn't SIMPLE investigate that path and reject it and go for MSRP as the so= lution to session mode messaging? Why does emergency calling suddenly make the original decision making proce= ss in SIMPLE redundant? regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= onsang Song Sent: Monday, November 23, 2009 8:53 PM To: ecrit@ietf.org Subject: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00= ] Hi, Just wanted to send a note about a new draft on using SIP MESSAGE for emerg= ency texting. The draft is an outcome of the collaboration between Columbia University an= d Verizon to build an emergency texting prototype system which allows peopl= e to use IM and SMS to "call" for emergency help. If you have comments or questions, please let me know. Thank you, Wonsang Song -------- Original Message -------- Subject: New Version Notification for draft-kim-ecrit-text-00 Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) From: IETF I-D Submission Tool To: jyk@cs.columbia.edu CC: wonsang@cs.columbia.edu, hgs@cs.columbi= a.edu, p.boni@verizon.com, michael.g.armstrong@verizon.com A new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly subm= itted by Jong Yul Kim and posted to the IETF repository. Filename: draft-kim-ecrit-text Revision: 00 Title: Emergency Text Messaging using SIP MESSAGE Creation_date: 2009-11-16 WG ID: Independent Submission Number_of_pages: 11 Abstract: This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_EDC0A1AE77C57744B664A310A0B23AE209C57E86FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
But...
 
The use case under discussion here is an end entit= y running=20 LOST (and therefore presumably an IP terminal) communicating with an IP=20 connected PSAP, and therefore not involving any SMS at all. Therefore for t= his=20 use case, the endpoints presumably have the full range of choice of standar= dised=20 messaging mechanisms as defined by IETF.
 
If you did want to extend the use case to SMS, I w= ould also=20 content that the current standardised SMS to SIP based IM mechanisms would = break=20 the solution suggested here as well.
 
(Also ignoring the fact as well that current SMS i= s by=20 default deferred delivery (i.e. delivered in the operator's own time and wh= en=20 the recipient is available, and therefore not suitable for emergency calls = in=20 the first place.)
 
Keith

From: Richard Barnes [mailto:rbarnes@= bbn.com]=20
Sent: Tuesday, November 24, 2009 2:35 PM
To: DRAGE, = Keith=20 (Keith)
Cc: ecrit
Subject: Re: [Ecrit] [Fwd: New Vers= ion=20 Notification for draft-kim-ecrit-text-00]

The problem here is that SMS is a page-mode medium that's used= for=20 session-mode-style conversations (see, e.g., the iPhone SMS interface).=20  So if you're going to gateway SMS into SIP and preserve these=20 pseudo-sessions, you either have to do something like what this draft doe= s, or=20 you have to somehow have the gateway create sessions and map SMS messages= into=20 them.  I'm not immediately sure which would be a better solution, bu= t=20 using MESSAGE seems marginally more light-weight.

--Richard




On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote:
So did I read this correctly.
 
You are essentially saying you want to use pag= e mode=20 messaging to do session mode messaging?
 
Didn't SIMPLE investigate that path and reject= it and=20 go for MSRP as the solution to session mode messaging?
 
Why does emergency calling suddenly make the o= riginal=20 decision making process in SIMPLE redundant?
 
regards
 
Keith

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org<= /A>]=20 On Behalf Of Wonsang Song
Sent: Monday, November 23,= 2009=20 8:53 PM
To: ecrit@ietf.org
Subject: = [Ecrit]=20 [Fwd: New Version Notification for=20 draft-kim-ecrit-text-00]

Hi,

Just wanted to send a note about a new draft on= =20 using SIP MESSAGE for emergency texting.

The draft is an outco= me of=20 the collaboration between Columbia University and Verizon to build an= =20 emergency texting prototype system which allows people to use IM and = SMS=20 to "call" for emergency help.

If you have comments or question= s,=20 please let me know.

Thank you,
Wonsang Song


----= ----=20 Original Message --------
Subject: New Version Notification for=20 draft-kim-ecrit-text-00
Date: Tue, 17 Nov 2009 11:55:17 -0800=20 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: jyk@cs.columbia.edu
CC:&nb= sp;wonsang@cs.columbia.edu,&= nbsp;hgs@cs.columbia.edu, p.boni@verizon.com,=20      michael.g.armstrong@v= erizon.com


A=20 new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly= =20 submitted by Jong Yul Kim and posted to the IETF=20 repository.

Filename:=20  draft-kim-ecrit-text
Revision:  00
Title:  Emerge= ncy Text=20 Messaging using SIP MESSAGE
Creation_date:  2009-11-16
WG ID:  Indepe= ndent=20 Submission
Number_of_pages: 11

Abstract:
This memo descr= ibes=20 best current practices on how to use the SIP
MESSAGE method for=20 emergency text messaging from citizen and visitors
to=20 authorities.

Status of this Memo

This Internet-Draft is= =20 submitted to IETF in full conformance with the
provisions of BCP 7= 8 and=20 BCP 79.

Internet-Drafts are working documents of the Internet= =20 Engineering
Task Force (IETF), its areas, and its working groups.= =20  Note that
other groups may also distribute working documents= as=20 Internet-
Drafts.

Internet-Drafts are draft documents valid= for=20 a maximum of six months
and may be updated, replaced, or obsoleted= by=20 other documents at any
time.  It is inappropriate to use=20 Internet-Drafts as reference
material or to cite them other than a= s=20 "work in progress."

The list of current Internet-Drafts can be= =20 accessed at
http://www.ietf.o= rg/ietf/1id-abstracts.txt.

The=20 list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.h= tml.

This=20 Internet-Draft will expire on May 20, 2010.

Copyright=20 Notice

Copyright (c) 2009 IETF Trust and the persons identifie= d as=20 the
document authors.  All rights reserved.

This docum= ent=20 is subject to BCP 78 and the IETF Trust's Legal
Provisions Relatin= g to=20 IETF Documents
(http://trustee.ietf.org= /license-info)=20 in effect on the date of
publication of this document.  Pleas= e=20 review these documents
carefully, as they describe your rights and= =20 restrictions with respect
to this document.  Code Components= =20 extracted from this document must
include Simplified BSD License t= ext=20 as described in Section 4.e of
the Trust Legal Provisions and are= =20 provided without warranty as
described in the BSD=20 License.



The IETF Secretariat.=20




___________= ____________________________________
Ecrit=20 mailing list
Ecrit@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ecrit

--_000_EDC0A1AE77C57744B664A310A0B23AE209C57E86FRMRSSXCHMBSC3d_-- From br@brianrosen.net Tue Nov 24 07:11:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB79C3A6A75 for ; Tue, 24 Nov 2009 07:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4-GBpgecCBG for ; Tue, 24 Nov 2009 07:11:40 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 18D823A6A7E for ; Tue, 24 Nov 2009 07:11:40 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NCx35-0001lo-FK; Tue, 24 Nov 2009 09:11:23 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 10:11:24 -0500 From: Brian Rosen To: "DRAGE, Keith (Keith)" , Richard Barnes Message-ID: Thread-Topic: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] Thread-Index: AcptE2KUmGBQYNayQs6IZ8nacjiy3QAAKn7QAAEVmHs= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:11:42 -0000 I think that it=B9s probably better to do it this way. It=B9s not clear to me that we can always create a session. It=B9s desirable t= o do so, but I=B9m not sure we can always do that. If we can=B9t always do it, then we need to use a timer to create a pseudo session, which is exactly what this draft does. The NENA requirements currently say that we accept pager mode IM, and the intention was to do it the way this draft describes. Can you explain how the existing SMS to SIP interworking standards would be in conflict with this idea? Brian On 11/24/09 9:45 AM, "DRAGE, Keith (Keith)" wrote: > But... > =20 > The use case under discussion here is an end entity running LOST (and > therefore presumably an IP terminal) communicating with an IP connected P= SAP, > and therefore not involving any SMS at all. Therefore for this use case, = the > endpoints presumably have the full range of choice of standardised messag= ing > mechanisms as defined by IETF. > =20 > If you did want to extend the use case to SMS, I would also content that = the > current standardised SMS to SIP based IM mechanisms would break the solut= ion > suggested here as well. > =20 > (Also ignoring the fact as well that current SMS is by default deferred > delivery (i.e. delivered in the operator's own time and when the recipien= t is > available, and therefore not suitable for emergency calls in the first pl= ace.) > =20 > Keith >=20 >> =20 >> =20 >>=20 >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Tuesday, November 24, 2009 2:35 PM >> To: DRAGE, Keith (Keith) >> Cc: ecrit >> Subject: Re: [Ecrit] [Fwd: New Version Notification for >> draft-kim-ecrit-text-00] >>=20 >> =20 >> The problem here is that SMS is a page-mode medium that's used for >> session-mode-style conversations (see, e.g., the iPhone SMS interface). = So >> if you're going to gateway SMS into SIP and preserve these pseudo-sessi= ons, >> you either have to do something like what this draft does, or you have = to >> somehow have the gateway create sessions and map SMS messages into them= . >> I'm not immediately sure which would be a better solution, but using ME= SSAGE >> seems marginally more light-weight. >>=20 >> =20 >> --Richard >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >> =20 >> On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote: >>=20 >> =20 >>> =20 >>> =20 >>> So did I read this correctly. >>> =20 >>> =20 >>> =20 >>> You are essentially saying you want to use page mode messaging to do >>> session mode messaging? >>> =20 >>> =20 >>> =20 >>> Didn't SIMPLE investigate that path and reject it and go for MSRP as t= he >>> solution to session mode messaging? >>> =20 >>> =20 >>> =20 >>> Why does emergency calling suddenly make the original decision making >>> process in SIMPLE redundant? >>> =20 >>> =20 >>> =20 >>> regards >>> =20 >>> =20 >>> =20 >>> Keith >>>=20 >>> =20 >>>> =20 >>>> =20 >>>>=20 >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of >>>> Wonsang Song >>>> Sent: Monday, November 23, 2009 8:53 PM >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] [Fwd: New Version Notification for >>>> draft-kim-ecrit-text-00] >>>>=20 >>>> =20 >>>> Hi, >>>>=20 >>>> Just wanted to send a note about a new draft on using SIP MESSAGE for >>>> emergency texting. >>>>=20 >>>> The draft is an outcome of the collaboration between Columbia Univers= ity >>>> and Verizon to build an emergency texting prototype system which allo= ws >>>> people to use IM and SMS to "call" for emergency help. >>>>=20 >>>> If you have comments or questions, please let me know. >>>>=20 >>>> Thank you, >>>> Wonsang Song >>>>=20 >>>>=20 >>>> -------- Original Message -------- >>>> Subject: New Version Notification for draft-kim-ecrit-text-00 >>>> Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) >>>> From: IETF I-D Submission Tool >>>> >>>> To: jyk@cs.columbia.edu >>>> CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, p.boni@verizon.com, >>>> michael.g.armstrong@verizon.com >>>>=20 >>>>=20 >>>> A new version of I-D, draft-kim-ecrit-text-00.txt has been successful= y >>>> submitted by Jong Yul Kim and posted to the IETF repository. >>>>=20 >>>> Filename: draft-kim-ecrit-text >>>> Revision: 00 >>>> Title: Emergency Text Messaging using SIP MESSAGE >>>> Creation_date: 2009-11-16 >>>> WG ID: Independent Submission >>>> Number_of_pages: 11 >>>>=20 >>>> Abstract: >>>> This memo describes best current practices on how to use the SIP >>>> MESSAGE method for emergency text messaging from citizen and visitors >>>> to authorities. >>>>=20 >>>> Status of this Memo >>>>=20 >>>> This Internet-Draft is submitted to IETF in full conformance with the >>>> provisions of BCP 78 and BCP 79. >>>>=20 >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF), its areas, and its working groups. Note that >>>> other groups may also distribute working documents as Internet- >>>> Drafts. >>>>=20 >>>> Internet-Drafts are draft documents valid for a maximum of six months >>>> and may be updated, replaced, or obsoleted by other documents at any >>>> time. It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>>=20 >>>> The list of current Internet-Drafts can be accessed at >>>> http://www.ietf.org/ietf/1id-abstracts.txt. >>>>=20 >>>> The list of Internet-Draft Shadow Directories can be accessed at >>>> http://www.ietf.org/shadow.html. >>>>=20 >>>> This Internet-Draft will expire on May 20, 2010. >>>>=20 >>>> Copyright Notice >>>>=20 >>>> Copyright (c) 2009 IETF Trust and the persons identified as the >>>> document authors. All rights reserved. >>>>=20 >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents >>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>> publication of this document. Please review these documents >>>> carefully, as they describe your rights and restrictions with respect >>>> to this document. Code Components extracted from this document must >>>> include Simplified BSD License text as described in Section 4.e of >>>> the Trust Legal Provisions and are provided without warranty as >>>> described in the BSD License. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat. >>>> =20 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From wonsang@cs.columbia.edu Tue Nov 24 09:05:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C813A6AB0 for ; Tue, 24 Nov 2009 09:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0mKk7jC0b4K for ; Tue, 24 Nov 2009 09:05:17 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 00D313A68C4 for ; Tue, 24 Nov 2009 09:05:16 -0800 (PST) Received: from [128.59.22.84] (ng911-desktop1.cs.columbia.edu [128.59.22.84]) (user=ws2131 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nAOH58r8004421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 12:05:09 -0500 (EST) Message-ID: <4B0C1245.8030507@cs.columbia.edu> Date: Tue, 24 Nov 2009 12:05:09 -0500 From: Wonsang Song User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4B0AF639.7020501@cs.columbia.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000106030506030109000909" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:05:18 -0000 This is a multi-part message in MIME format. --------------000106030506030109000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This draft does not suggest to use page mode instead of session mode for the emergency text communication. This is for the case where the endpoint is not capable of creating session or for the existing text communication methods that are lack of session, such like IM and SMS. Wonsang Song DRAGE, Keith (Keith) wrote: > So did I read this correctly. > > You are essentially saying you want to use page mode messaging to do > session mode messaging? > > Didn't SIMPLE investigate that path and reject it and go for MSRP as > the solution to session mode messaging? > > Why does emergency calling suddenly make the original decision making > process in SIMPLE redundant? > > regards > > Keith > > ------------------------------------------------------------------------ > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On > Behalf Of *Wonsang Song > *Sent:* Monday, November 23, 2009 8:53 PM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] [Fwd: New Version Notification for > draft-kim-ecrit-text-00] > > Hi, > > Just wanted to send a note about a new draft on using SIP MESSAGE > for emergency texting. > > The draft is an outcome of the collaboration between Columbia > University and Verizon to build an emergency texting prototype > system which allows people to use IM and SMS to "call" for > emergency help. > > If you have comments or questions, please let me know. > > Thank you, > Wonsang Song > > > -------- Original Message -------- > Subject: New Version Notification for draft-kim-ecrit-text-00 > Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) > From: IETF I-D Submission Tool > To: jyk@cs.columbia.edu > CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, p.boni@verizon.com, > michael.g.armstrong@verizon.com > > > A new version of I-D, draft-kim-ecrit-text-00.txt has been > successfuly submitted by Jong Yul Kim and posted to the IETF > repository. > > Filename: > draft-kim-ecrit-text > Revision: 00 > Title: Emergency Text Messaging using SIP MESSAGE > Creation_date: > 2009-11-16 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > This memo describes best current practices on how to use the SIP > MESSAGE method for emergency text messaging from citizen and visitors > to authorities. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 20, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > > > --------------000106030506030109000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This draft does not suggest to use page mode instead of session mode for the emergency text communication. This is for the case where the endpoint is not capable of creating session or for the existing text communication methods that are lack of session, such like IM and SMS.

Wonsang Song


DRAGE, Keith (Keith) wrote:
So did I read this correctly.
 
You are essentially saying you want to use page mode messaging to do session mode messaging?
 
Didn't SIMPLE investigate that path and reject it and go for MSRP as the solution to session mode messaging?
 
Why does emergency calling suddenly make the original decision making process in SIMPLE redundant?
 
regards
 
Keith

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Wonsang Song
Sent: Monday, November 23, 2009 8:53 PM
To: ecrit@ietf.org
Subject: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00]

Hi,

Just wanted to send a note about a new draft on using SIP MESSAGE for emergency texting.

The draft is an outcome of the collaboration between Columbia University and Verizon to build an emergency texting prototype system which allows people to use IM and SMS to "call" for emergency help.

If you have comments or questions, please let me know.

Thank you,
Wonsang Song


-------- Original Message --------
Subject: New Version Notification for draft-kim-ecrit-text-00
Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: jyk@cs.columbia.edu
CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu, p.boni@verizon.com,      michael.g.armstrong@verizon.com


A new version of I-D, draft-kim-ecrit-text-00.txt has been successfuly submitted by Jong Yul Kim and posted to the IETF repository.

Filename:
 draft-kim-ecrit-text
Revision:  00
Title:  Emergency Text Messaging using SIP MESSAGE
Creation_date:
 2009-11-16
WG ID:  Independent Submission
Number_of_pages: 11

Abstract:
This memo describes best current practices on how to use the SIP
MESSAGE method for emergency text messaging from citizen and visitors
to authorities.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 20, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.



The IETF Secretariat.




--------------000106030506030109000909-- From john@johnlange.ca Tue Nov 24 10:29:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0483928C140 for ; Tue, 24 Nov 2009 10:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7CzkKrFIhte for ; Tue, 24 Nov 2009 10:29:57 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id C2D9128C138 for ; Tue, 24 Nov 2009 10:29:57 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1598814qwb.31 for ; Tue, 24 Nov 2009 10:29:50 -0800 (PST) Received: by 10.224.113.210 with SMTP id b18mr3357743qaq.354.1259087390336; Tue, 24 Nov 2009 10:29:50 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 26sm15921653qwa.30.2009.11.24.10.29.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 10:29:49 -0800 (PST) From: John Lange To: ecrit Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Nov 2009 12:29:38 -0600 Message-Id: <1259087378.4619.143.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Subject: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:29:59 -0000 Recently I've been following the debate on this list regarding veracity of location which loosely translates into a larger debate about security. If I'm understanding all of this correctly, one position is that PSAPs will be resistant to solutions where the identity and location of the caller can't be assured and that this necessarily requires a trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. The other position is that the requirement for a trust relationship prevents nomadic VOIP users from accessing PSAPs when out of their home areas. Furthermore, these trusts can be circumvented so they provide only a false sense of security. Is this a fair characterization of the two positions? -- John Lange http://www.johnlange.ca From mlinsner@cisco.com Tue Nov 24 11:19:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEE43A688E for ; Tue, 24 Nov 2009 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yJlbtdxPAFi for ; Tue, 24 Nov 2009 11:19:55 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com (xmb-rtp-205.cisco.com [64.102.31.59]) by core3.amsl.com (Postfix) with ESMTP id C1BF53A6818 for ; Tue, 24 Nov 2009 11:19:55 -0800 (PST) Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:19:50 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 24 Nov 2009 14:19:48 -0500 From: Marc Linsner To: John Lange , ecrit Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptOxZp69muR34AdkuTrTfoA53n3w== In-Reply-To: <1259087378.4619.143.camel@linux-k6vx.site> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 19:19:50.0824 (UTC) FILETIME=[18188A80:01CA6D3B] Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:19:56 -0000 Why would a person requesting emergency assistance knowingly provide a false location? -Marc- On 11/24/09 1:29 PM, "John Lange" wrote: > Recently I've been following the debate on this list regarding veracity > of location which loosely translates into a larger debate about > security. > > If I'm understanding all of this correctly, one position is that PSAPs > will be resistant to solutions where the identity and location of the > caller can't be assured and that this necessarily requires a trust > relationship between VSPs and PSAPs and/or ISPs and PSAPs. > > The other position is that the requirement for a trust relationship > prevents nomadic VOIP users from accessing PSAPs when out of their home > areas. Furthermore, these trusts can be circumvented so they provide > only a false sense of security. > > Is this a fair characterization of the two positions? From fmenard@xittelecom.com Tue Nov 24 11:24:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8AA3A67DF for ; Tue, 24 Nov 2009 11:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg4QmanbBAoA for ; Tue, 24 Nov 2009 11:24:45 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 318F83A67C1 for ; Tue, 24 Nov 2009 11:24:45 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1ND10C-0002mV-4h; Tue, 24 Nov 2009 14:24:40 -0500 Received: from [205.151.16.4] (helo=[192.168.2.64]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1ND10B-0001XI-31; Tue, 24 Nov 2009 14:24:39 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois Menard In-Reply-To: <1259087378.4619.143.camel@linux-k6vx.site> Date: Tue, 24 Nov 2009 14:24:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <390138ED-880A-4032-8D0B-584BAFEDCD84@xittelecom.com> References: <1259087378.4619.143.camel@linux-k6vx.site> To: John Lange X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:24:46 -0000 I think the issue of trust is between the ILEC as an agent of the PSAP = and the end-user as a subscriber to the VISP service provider. i.e. ILECs are not willing to trust that VISPs will relay calls unless = ILECs go ahead and countervalidate with the ISP providing the service, = and then countervalidate with their own internal systems feeding the = wholesale service to the ISPs. I think that PSAPs should be mandated to trust end-points which obtain = their location from the ISPs. We could have end-points cerfied for this behaviour. It would be better than to have this weird call flow I referred to in my = previous email, which is not on the public Internet and thus out of = reach of the IETF to sanctify. F. On 2009-11-24, at 13:29, John Lange wrote: > Recently I've been following the debate on this list regarding = veracity > of location which loosely translates into a larger debate about > security. >=20 > If I'm understanding all of this correctly, one position is that PSAPs > will be resistant to solutions where the identity and location of the > caller can't be assured and that this necessarily requires a trust > relationship between VSPs and PSAPs and/or ISPs and PSAPs. >=20 > The other position is that the requirement for a trust relationship > prevents nomadic VOIP users from accessing PSAPs when out of their = home > areas. Furthermore, these trusts can be circumvented so they provide > only a false sense of security. >=20 > Is this a fair characterization of the two positions? >=20 > --=20 > John Lange > http://www.johnlange.ca >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fmenard@xittelecom.com Tue Nov 24 11:25:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAF33A67C1 for ; Tue, 24 Nov 2009 11:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16ZHLl9U3QVK for ; Tue, 24 Nov 2009 11:25:15 -0800 (PST) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 7849E3A6947 for ; Tue, 24 Nov 2009 11:25:13 -0800 (PST) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1ND10e-0002nx-5s; Tue, 24 Nov 2009 14:25:08 -0500 Received: from [205.151.16.4] (helo=[192.168.2.64]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1ND10d-0001XI-PD; Tue, 24 Nov 2009 14:25:07 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois Menard In-Reply-To: Date: Tue, 24 Nov 2009 14:25:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Linsner X-Mailer: Apple Mail (2.1077) Cc: ecrit Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:25:16 -0000 my point exactly! f. On 2009-11-24, at 14:19, Marc Linsner wrote: > Why would a person requesting emergency assistance knowingly provide a = false > location? >=20 > -Marc- >=20 > On 11/24/09 1:29 PM, "John Lange" wrote: >=20 >> Recently I've been following the debate on this list regarding = veracity >> of location which loosely translates into a larger debate about >> security. >>=20 >> If I'm understanding all of this correctly, one position is that = PSAPs >> will be resistant to solutions where the identity and location of the >> caller can't be assured and that this necessarily requires a trust >> relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>=20 >> The other position is that the requirement for a trust relationship >> prevents nomadic VOIP users from accessing PSAPs when out of their = home >> areas. Furthermore, these trusts can be circumvented so they provide >> only a false sense of security. >>=20 >> Is this a fair characterization of the two positions? >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Nov 24 11:50:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1543A688E for ; Tue, 24 Nov 2009 11:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aYbhzorm+1r for ; Tue, 24 Nov 2009 11:50:32 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 637B43A6358 for ; Tue, 24 Nov 2009 11:50:32 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1ND1Oy-0005bz-Cn; Tue, 24 Nov 2009 13:50:16 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 14:50:15 -0500 From: Brian Rosen To: Marc Linsner , John Lange , ecrit Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptOxZp69muR34AdkuTrTfoA53n3wABED7t In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:50:33 -0000 To be fair, I think the concern is an illegitimate caller falsifying location. These issues are discussed in: draft-tschofenig-ecrit-trustworthy-location, although I don't agree with its conclusions which follow a line of thinking that because we can't stop all attacks we shouldn't try to stop some. Location signing, in particular, can stop a whole class of attacks, although there are still some cut/paste and other substitution attacks it won't stop. I believe we should make attempts to falsify location hard enough that it takes a determined attacker, and forces them to use mechanisms that are infrequently used otherwise, so that we can instruct call takers when to take extra precautions. Today, for example, there are roughly no devices that would reasonably be used to make emergency calls that have completely self supported GPS. The real devices use network assisted GPS, where we have ways to check reasonability. Brian On 11/24/09 2:19 PM, "Marc Linsner" wrote: > Why would a person requesting emergency assistance knowingly provide a false > location? > > -Marc- > > On 11/24/09 1:29 PM, "John Lange" wrote: > >> Recently I've been following the debate on this list regarding veracity >> of location which loosely translates into a larger debate about >> security. >> >> If I'm understanding all of this correctly, one position is that PSAPs >> will be resistant to solutions where the identity and location of the >> caller can't be assured and that this necessarily requires a trust >> relationship between VSPs and PSAPs and/or ISPs and PSAPs. >> >> The other position is that the requirement for a trust relationship >> prevents nomadic VOIP users from accessing PSAPs when out of their home >> areas. Furthermore, these trusts can be circumvented so they provide >> only a false sense of security. >> >> Is this a fair characterization of the two positions? > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.medland@bt.com Tue Nov 24 11:55:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A6B3A693B for ; Tue, 24 Nov 2009 11:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK+ahwR0P+EG for ; Tue, 24 Nov 2009 11:55:03 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 16B333A6926 for ; Tue, 24 Nov 2009 11:55:00 -0800 (PST) Received: from E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 19:54:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Nov 2009 19:53:28 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16g From: To: , X-OriginalArrivalTime: 24 Nov 2009 19:54:55.0349 (UTC) FILETIME=[FE7D9250:01CA6D3F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:55:04 -0000 Marc, Francois, Without getting involved in the technical debate, I thought you may be = interested to see some figures about what we in UK term hoax calls, ie = people who report a non-existent incident. The information in " " below = is 3.5 years old but still illustrates the problem. =20 =20 " Hoax calls are costing the UK Fire and Rescue Service a massive = =A3230,000 a day - =A384 million a year - and the problem is potentially = putting lives in danger. =20 Approximately 50,000 hoax fire calls are responded to every year, 135 = per day, by the Fire and Rescue Service in England and Wales, whose role = includes providing emergency response to fires, road traffic incidents = and terrorism. The Economic Cost of Fire report estimates that each = hoax call costs =A31,700. This equates to a disturbing =A384 million = per year. A significant cost for the Fire and Rescue Service to absorb.=20 London Fire Brigade has the highest hoax call rate in the UK, attending = nearly twice as many call outs (9,686) as the second worse affected = brigade, Greater Manchester (5,268) and the West Midlands (4,074). =20 Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, = said: "Young people in particular need to be aware what can happen if = the fire brigade is called out under false pretences. The danger to = others involved in a real emergency and the financial drain that they = impose on a service that is there to save people's lives. " " UK emergency services use the location as one of the tests of how = reliable is the report from a caller - if the "network provided" = location (circuit switched wireline and GSM) differs appreciably from = the incident location that a caller is reporting, then it influences the = PSAP's response and questionning of the caller. It is often children who make these hoax calls in the UK - it's = difficult to understand why so I can't really answer Marc's question = directly : we need a good psychiatrist/psychologist to answer that, but = such calls are a very real problem and having reliable location = information is an important weapon in tackling these as well as for = speeding-up the handling of genuine calls. Regards=20 John -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Francois Menard Sent: 24 November 2009 19:25 To: Marc Linsner Cc: ecrit Subject: Re: [Ecrit] To trust or not to trust. Is that the question? my point exactly! f. On 2009-11-24, at 14:19, Marc Linsner wrote: > Why would a person requesting emergency assistance knowingly provide a = > false location? >=20 > -Marc- >=20 > On 11/24/09 1:29 PM, "John Lange" wrote: >=20 >> Recently I've been following the debate on this list regarding=20 >> veracity of location which loosely translates into a larger debate=20 >> about security. >>=20 >> If I'm understanding all of this correctly, one position is that=20 >> PSAPs will be resistant to solutions where the identity and location=20 >> of the caller can't be assured and that this necessarily requires a=20 >> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>=20 >> The other position is that the requirement for a trust relationship=20 >> prevents nomadic VOIP users from accessing PSAPs when out of their=20 >> home areas. Furthermore, these trusts can be circumvented so they=20 >> provide only a false sense of security. >>=20 >> Is this a fair characterization of the two positions? >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Tue Nov 24 12:18:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8765428C13F for ; Tue, 24 Nov 2009 12:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+ehchbfPh7n for ; Tue, 24 Nov 2009 12:18:15 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 6D9DA28C149 for ; Tue, 24 Nov 2009 12:18:15 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:21060 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S73826AbZKXUSJ convert rfc822-to-8bit (ORCPT ); Tue, 24 Nov 2009 14:18:09 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 24 Nov 2009 14:18:09 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 25 Nov 2009 04:18:05 +0800 From: "Winterbottom, James" To: Marc Linsner , John Lange , ecrit Date: Wed, 25 Nov 2009 04:14:23 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptOxZp69muR34AdkuTrTfoA53n3wAB6B0Y Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B35@SISPE7MB1.commscope.com> References: <1259087378.4619.143.camel@linux-k6vx.site>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:18:16 -0000 Marc, I am not worried about the person that actually requires assistance doing this. I am VERY worried that the proposed solution has no bar whatsoever to entry of someone that wants to send all responders to the wrong end of town for a thrill, or worse make it hard for them to reach a real emergency on the other end of town, or as was the case in, I think New York, a few years back snipe them on their way to the final destination. This has nothing to do with a business model, it is about eliminating or reducing a fundamental problem that you seem to be unwilling to accept exists. Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Marc Linsner [mlinsner@cisco.com] Sent: Tuesday, November 24, 2009 1:19 PM To: John Lange; ecrit Subject: Re: [Ecrit] To trust or not to trust. Is that the question? Why would a person requesting emergency assistance knowingly provide a false location? -Marc- On 11/24/09 1:29 PM, "John Lange" wrote: > Recently I've been following the debate on this list regarding veracity > of location which loosely translates into a larger debate about > security. > > If I'm understanding all of this correctly, one position is that PSAPs > will be resistant to solutions where the identity and location of the > caller can't be assured and that this necessarily requires a trust > relationship between VSPs and PSAPs and/or ISPs and PSAPs. > > The other position is that the requirement for a trust relationship > prevents nomadic VOIP users from accessing PSAPs when out of their home > areas. Furthermore, these trusts can be circumvented so they provide > only a false sense of security. > > Is this a fair characterization of the two positions? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From john@johnlange.ca Tue Nov 24 12:51:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580493A6999 for ; Tue, 24 Nov 2009 12:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dygmG0qtap6U for ; Tue, 24 Nov 2009 12:51:28 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 47EC43A6877 for ; Tue, 24 Nov 2009 12:51:28 -0800 (PST) Received: by qyk41 with SMTP id 41so3602863qyk.29 for ; Tue, 24 Nov 2009 12:51:21 -0800 (PST) Received: by 10.224.26.218 with SMTP id f26mr12998qac.106.1259095880680; Tue, 24 Nov 2009 12:51:20 -0800 (PST) Received: from ?192.168.1.100? (host-253.epicnet.ca [64.201.170.253]) by mx.google.com with ESMTPS id 23sm25294qyk.3.2009.11.24.12.51.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 12:51:20 -0800 (PST) From: John Lange To: ecrit In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Nov 2009 14:51:13 -0600 Message-Id: <1259095873.4619.232.camel@linux-k6vx.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:51:29 -0000 My questions about security and trust are with regard to mounting a large scale DOS attack on the 911 system. In a world where the line between computers and phones continues to blur, how long will it be before we see the first "bot network" on these devices? (there is a story about an iPhone worm today). In a scenario where tens of thousands of these end-points suddenly start dialling 911, being able to validate their location isn't going to help much in preventing the PSAP from being overwhelmed. So the question I'm left with is, would adding trust to this scenario prevent or mitigate the attack? Lets imagine that in the future there is a particular brand of "softphone" that becomes very popular and is running on a very large proportion of devices subscribed to a wide variety of VSPs (imagine something like skype but not tied to any specific back-end provider). A worm compromises this software (or the OS that it runs on) which allows the attacker to secretly control the softphone. Would trust be of any use? Personally I have no answer to that question which is why I pose it here on this list. The only thing I can think of is that the trust relationship might allow you to block emergency calls from these callers and mitigate the problem. That assumes you have some way of identifying the compromised hosts. I recall that nearly this exact scenario took place in the early part of this decade where compromised computers were dialing 911 using modems. Fortunately, as far as I'm aware there was never enough machines compromised at any one time to cause much of a problem. (as a side note, there is actually a patent for preventing this: http://www.freepatentsonline.com/y2006/0039540.html) My assumption would be, just like DDOS and spam, there will be no way to completely prevent it. But just like DDOS and spam, there will be enough ways to mitigate it that the world won't come crashing down. And in the meantime, the media will over-hype it and scare the crap out of everyone... -- John Lange http://www.johnlange.ca From br@brianrosen.net Tue Nov 24 13:01:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D59C3A696A for ; Tue, 24 Nov 2009 13:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Blyi+5dmUX7q for ; Tue, 24 Nov 2009 13:01:39 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2ACB03A6950 for ; Tue, 24 Nov 2009 13:01:39 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1ND2Vn-0001qr-EO; Tue, 24 Nov 2009 15:01:23 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 16:01:29 -0500 From: Brian Rosen To: John Lange , ecrit Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptSUrkIxtUlvIMSk25eknb9ozyBg== In-Reply-To: <1259095873.4619.232.camel@linux-k6vx.site> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:01:40 -0000 No, there are a couple of attacks. One is a classic DoS attack. It doesn't matter what the location is in a DoS attack. The point is to overwhelm the system with signaling messages. There are mitigation strategies for this kind of attack, but they aren't germane to this discussion. The other attack is a misdirection of responder attack. This is not "large scale". It's a call that sends responders to somewhere that there is no emergency. The call appears to be legitimate, and there aren't a huge number of them at once. Here, a bad location is harmful. Brian On 11/24/09 3:51 PM, "John Lange" wrote: > My questions about security and trust are with regard to mounting a > large scale DOS attack on the 911 system. > > In a world where the line between computers and phones continues to > blur, how long will it be before we see the first "bot network" on these > devices? (there is a story about an iPhone worm today). > > In a scenario where tens of thousands of these end-points suddenly start > dialling 911, being able to validate their location isn't going to help > much in preventing the PSAP from being overwhelmed. > > So the question I'm left with is, would adding trust to this scenario > prevent or mitigate the attack? > > Lets imagine that in the future there is a particular brand of > "softphone" that becomes very popular and is running on a very large > proportion of devices subscribed to a wide variety of VSPs (imagine > something like skype but not tied to any specific back-end provider). > > A worm compromises this software (or the OS that it runs on) which > allows the attacker to secretly control the softphone. > > Would trust be of any use? Personally I have no answer to that question > which is why I pose it here on this list. > > The only thing I can think of is that the trust relationship might allow > you to block emergency calls from these callers and mitigate the > problem. That assumes you have some way of identifying the compromised > hosts. > > I recall that nearly this exact scenario took place in the early part of > this decade where compromised computers were dialing 911 using modems. > Fortunately, as far as I'm aware there was never enough machines > compromised at any one time to cause much of a problem. (as a side note, > there is actually a patent for preventing this: > http://www.freepatentsonline.com/y2006/0039540.html) > > My assumption would be, just like DDOS and spam, there will be no way to > completely prevent it. But just like DDOS and spam, there will be enough > ways to mitigate it that the world won't come crashing down. And in the > meantime, the media will over-hype it and scare the crap out of > everyone... From bernard_aboba@hotmail.com Tue Nov 24 13:49:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1073A687F for ; Tue, 24 Nov 2009 13:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i493ArPPz8-8 for ; Tue, 24 Nov 2009 13:49:51 -0800 (PST) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id EF7E03A6821 for ; Tue, 24 Nov 2009 13:49:50 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 13:49:46 -0800 X-Originating-IP: [64.134.238.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Brian Rosen'" , "'John Lange'" , "'ecrit'" References: <1259095873.4619.232.camel@linux-k6vx.site> In-Reply-To: Date: Tue, 24 Nov 2009 13:49:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptSUrkIxtUlvIMSk25eknb9ozyBgABidYQ Content-Language: en-us x-cr-hashedpuzzle: ChjU CqaK Ld+J MDQz PmBp RGy5 RTiA RyiM SaIm TOYF WQD9 Zy0p baSY dLCZ fppE g5Nx; 3; YgByAEAAYgByAGkAYQBuAHIAbwBzAGUAbgAuAG4AZQB0ADsAZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnADsAagBvAGgAbgBAAGoAbwBoAG4AbABhAG4AZwBlAC4AYwBhAA==; Sosha1_v1; 7; {A49A4020-D5E9-4E3B-BA95-6DE5E65B6370}; YgBlAHIAbgBhAHIAZABhAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Tue, 24 Nov 2009 21:49:36 GMT; UgBFADoAIABbAEUAYwByAGkAdABdACAAVABvACAAdAByAHUAcwB0ACAAbwByACAAbgBvAHQAIAB0AG8AIAB0AHIAdQBzAHQALgAgAEkAcwAgAHQAaABhAHQAIAB0AGgAZQAgAHEAdQBlAHMAdABpAG8AbgA/AA== x-cr-puzzleid: {A49A4020-D5E9-4E3B-BA95-6DE5E65B6370} X-OriginalArrivalTime: 24 Nov 2009 21:49:46.0729 (UTC) FILETIME=[0A12B590:01CA6D50] Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:49:51 -0000 Brian said: "The other attack is a misdirection of responder attack. This is not "large scale". It's a call that sends responders to somewhere that there is no emergency. The call appears to be legitimate, and there aren't a huge number of them at once. Here, a bad location is harmful." [BA] The FBI recently issued a warning over the rapid growth in "SWATTING" attacks on the 911 system: http://www.networkworld.com/community/node/24714 So while the numbers may not be huge, the consequences are serious enough to have gotten attention. Overall, I wonder whether in a decade SWATTING will be as big an issue as SPAM is today. From br@brianrosen.net Tue Nov 24 14:37:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92D03A67D9 for ; Tue, 24 Nov 2009 14:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u44FRpqO2Bg1 for ; Tue, 24 Nov 2009 14:37:51 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3B5F63A68C3 for ; Tue, 24 Nov 2009 14:37:51 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1ND40r-0008SZ-J6; Tue, 24 Nov 2009 16:37:34 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 17:37:39 -0500 From: Brian Rosen To: Bernard Aboba , 'John Lange' , 'ecrit' Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptSUrkIxtUlvIMSk25eknb9ozyBgABidYQAAHR9s4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:37:52 -0000 Depends on how easy we make it I suppose. Today, because you can call from a "sim-less" phone which doesn't send location, or falsely enter self reported location for a VoIP phone, it's very easy. Brian On 11/24/09 4:49 PM, "Bernard Aboba" wrote: > Brian said: > > "The other attack is a misdirection of responder attack. This is not "large > scale". It's a call that sends responders to somewhere that there is no > emergency. The call appears to be legitimate, and there aren't a huge > number of them at once. Here, a bad location is harmful." > > [BA] The FBI recently issued a warning over the rapid growth in "SWATTING" > attacks on the 911 system: > http://www.networkworld.com/community/node/24714 > > So while the numbers may not be huge, the consequences are serious enough to > have gotten attention. > > Overall, I wonder whether in a decade SWATTING will be as big an issue as > SPAM is today. > > From James.Winterbottom@andrew.com Tue Nov 24 14:39:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C548E3A6917 for ; Tue, 24 Nov 2009 14:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGEb27p+yBQi for ; Tue, 24 Nov 2009 14:39:27 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DA19E3A68C3 for ; Tue, 24 Nov 2009 14:39:26 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:41434 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S81521AbZKXWjW convert rfc822-to-8bit (ORCPT ); Tue, 24 Nov 2009 16:39:22 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 24 Nov 2009 16:39:21 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 25 Nov 2009 06:39:17 +0800 From: "Winterbottom, James" To: Brian Rosen , Bernard Aboba , 'John Lange' , 'ecrit' Date: Wed, 25 Nov 2009 06:38:48 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptSUrkIxtUlvIMSk25eknb9ozyBgABidYQAAHR9s4AAApKUQ== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB8C7B3D@SISPE7MB1.commscope.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:39:27 -0000 sim-less phones can be located. Self-reported system however are a completely different kettle of fish. ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Brian Rosen [br@brianrosen.net] Sent: Tuesday, November 24, 2009 4:37 PM To: Bernard Aboba; 'John Lange'; 'ecrit' Subject: Re: [Ecrit] To trust or not to trust. Is that the question? Depends on how easy we make it I suppose. Today, because you can call from a "sim-less" phone which doesn't send location, or falsely enter self reported location for a VoIP phone, it's very easy. Brian On 11/24/09 4:49 PM, "Bernard Aboba" wrote: > Brian said: > > "The other attack is a misdirection of responder attack. This is not "large > scale". It's a call that sends responders to somewhere that there is no > emergency. The call appears to be legitimate, and there aren't a huge > number of them at once. Here, a bad location is harmful." > > [BA] The FBI recently issued a warning over the rapid growth in "SWATTING" > attacks on the 911 system: > http://www.networkworld.com/community/node/24714 > > So while the numbers may not be huge, the consequences are serious enough to > have gotten attention. > > Overall, I wonder whether in a decade SWATTING will be as big an issue as > SPAM is today. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Markus.Isomaki@nokia.com Wed Nov 25 00:51:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF533A68FB for ; Wed, 25 Nov 2009 00:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Ig+t7JWM8w for ; Wed, 25 Nov 2009 00:51:14 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E1ED33A6867 for ; Wed, 25 Nov 2009 00:51:13 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAP8ohDQ017362; Wed, 25 Nov 2009 10:51:03 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:50:45 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:50:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:50:34 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 25 Nov 2009 09:50:34 +0100 From: To: , Date: Wed, 25 Nov 2009 09:50:32 +0100 Thread-Topic: [Ecrit] wireless VOIP is dead Thread-Index: AcpshQYSsYbs/OdDSJuAM3FP8x3OgQAivkJA Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B3F72E5548B10A4A8E6F4795430F84182D31AF9C33NOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 08:50:34.0991 (UTC) FILETIME=[5A475FF0:01CA6DAC] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:51:16 -0000 --_000_B3F72E5548B10A4A8E6F4795430F84182D31AF9C33NOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, One reason for high jitter in many of the current 3G wireless networks is t= hat the link layer operates in "acknowledged mode". This means that at L2 a= packet/frame is retransmitted if it's lost for instance due to unrecoverab= le bit errors over the radio. For that particular user/connection, all the = forthcoming packets are then waiting too until the retransmission completes= . As RTTs tend to be rather high and bitrates relatively slow, this creates= a situation where the E2E delay for a number of packets suddenly peaks way= over the average. For something like VoIP all those packets are probably d= iscarded at the receiver. GGSN buffers may contribute something more to thi= s, but at least some of the network elements provide per user/connection qu= eueing, so the users are separated from each other what comes to congestion= and queuing. I'm not sure if this is going to change in newer radio system= s such as LTE except the RTT will be lower and the transmit rate higher. LTE deployment will differ between different regions too. In US (Verizon, A= TT both have ~700 MHz spectrum for LTE) and Japan the situation may actuall= y be pretty good in a few years time, in Europe it will take longer (initia= l deployments at 2.6 GHz). The operators may start offering voice service a= s a combination of LTE VoIP and Circuit Switched voice, the call handover t= echniques between the two have been standardized by 3GPP (but not tested in= the field yet). One of the interesting questions about LTE indeed is wheth= er good quality VoIP only works as offered by the access operator, since th= ey can provision the connections used for their own services, or can we mak= e access operator independent real-time services good enough too. If the bu= ffers, L2 modes etc. things that can be configured are a major issue, we ma= y need something like HOMEGATE for wide area wireless :) Markus ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Bernard Aboba Sent: 23 November, 2009 23:36 To: mlinsner@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead The data dongles, etc. are indeed "data only" devices. However, today they= only represent a small fraction of all wireless endpoints. It is conceiva= ble that this could change with the introduction of new computing devices w= ith built in WWAN chipsets (such as netbooks or tablets). But the current= "attach rate" of WWAN chipsets is currently much lower than with free wire= less technologies such as WLAN, Bluetooth or even GPS. In the current econ= omic environment, those wireless chipsets are selling a lot better than WWA= N chipsets which require "data only" plans running $60+/month. In terms of jitter, this varies considerably based on the specifics of a pa= rticular deployment. The rapid increase in usage of smartphones has put a = lot of pressure on existing networks, and many are now running very close t= o capacity. So even though we have seen some loosening of VOIP restriction= s (my understanding is that Skype use is no longer restricted to WLAN, for = example), the user experience during peak usage times will often not be ver= y good. I've also seen networks with self-inflicted design problems. For example, = sometimes the GGSN buffering is over-provisioned, in the mistaken belief th= at this somehow will decrease packet loss. Instead, it results in a sawtoo= th ramp up in delay as the queues fill, followed by sustained packet loss a= s incoming packets drop until the queue can be slowly emptied. Not good fo= r VOIP. As to whether future technologies such as LTE can be provide a better VOIP = experience, I'm skeptical. In the medium term, LTE is most likely to be de= ployed as an "infill" technology, providing higher speed data access in are= as with a high density of data users. This kind of incremental deployment = is much more economical than attempting to create a "greenfield" 4G network= , so it is quite likely to happen, paid for by all the new smartphone data = plans. The question is whether all those new smartphones and data plans will trans= ition to use of VOIP in the near future. I doubt it. As long as LTE cover= age remains spotty, and wireless networks remain congested, demand for wire= less data bandwidth will run ahead of supply. Without better handling of c= ongestion (such as by using some of the techniques discussed in the Transpo= rt Area, such as LEDBAT or Re-ECN), the VOIP user experience won't be good = enough to handle a very large fraction of calls, even if restrictions on VO= IP usage are removed. > Bernard, > > What would you consider the data dongles and mifi thingies? Aren't those = a > data only service? > > My experience has been that VoIP over 3G is less than desirable due to > jitter. Even the most forgiving of codecs (Skype) struggle with the jitte= r > on 3G. > > -Marc- > > > On 11/23/09 2:01 PM, "Bernard Aboba" wrote: > > >> I submit that the relatively slow uptake of data-only is due largely t= o > >> the fact that the providers are clinging to voice-based business model= s.... > >> widespread use of VOIP on data-only mobile devices is inevitable. > > > > While I'd agree that it's likely to happen at some point, there is no "= data > > only" wireless technology on the horizon that seems likely to result in > > widespread deployment of wireless VOIP in the near future. > > > > Today's fragmented hotspot deployments with their web portal-based acce= ss > > model are not exactly "VOIP-friendly". > > > > Even greenfield wireless providers with no existing voice-based busines= s model > > have failed in their introduction of "data-only" plans. Typically this = is due > > to unfavorable speed/power and cost/coverage tradeoffs. This problem oc= curs > > because next generation wireless data technologies have greatly increas= ed > > power consumption and much reduced coverage radius compared with existi= ng > > technologies. Capital and maintenance costs rise with the inverse squar= e of > > the coverage ratio. So reducing the coverage radius by 50 percent incre= ases > > cost by 400 percent. Similarly, power consumption increases more than > > linearly with speed. These basic mathematical principles have had devas= tating > > effects on the prospects of "data only" wireless networks, whether they= be > > municipal networks unable to provide acceptable coverage with 802.11 AP= s > > running at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz = WiMAX > > pilots that have only demonstrated a 1-2 mile coverage radius. The bott= om lin > > e is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospitable to > > construction of viable "data only" networks. > > > > It's possible that allocation of spectrum with longer propagation > > characteristics (e.g. White Spaces) may help in overcoming coverage obs= tacles, > > but that is years away. > > > >> That isn't to imply that there aren't still roadblocks. For example, > >> here in Canada, the growth of mobile data is severely restricted by th= e > >> lack of competition leading to mediocre selection of devices (we just > >> got the iPhone about a year ago) and very high data prices. > > > > Here in the U.S. we have seen "data only" wireless networks offering ac= cess > > for as little as $20/month fail to sign up even 5 percent of the popula= tion. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > --_000_B3F72E5548B10A4A8E6F4795430F84182D31AF9C33NOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bernard,
 
One reason for high jitter in many of the current 3G wirele= ss=20 networks is that the link layer operates in "acknowledged mode". This means= that=20 at L2 a packet/frame is retransmitted if it's lost for instance due to=20 unrecoverable bit errors over the radio. For that particular user/connectio= n,=20 all the forthcoming packets are then waiting too until the retransmission=20 completes. As RTTs tend to be rather high and bitrates relatively slow, thi= s=20 creates a situation where the E2E delay for a number of packets suddenly pe= aks=20 way over the average. For something like VoIP all those packets are probabl= y=20 discarded at the receiver. GGSN buffers may contribute something more to th= is,=20 but at least some of the network elements provide per user/connection= =20 queueing, so the users are separated from each other what comes to=20 congestion and queuing. I'm not sure if this is going to change in new= er radio=20 systems such as LTE except the RTT will be lower and the transmit rate= =20 higher.
 
LTE deployment will differ between different regions too. I= n US=20 (Verizon, ATT both have ~700 MHz spectrum for LTE) and Japan the situation = may=20 actually be pretty good in a few years time, in Europe it will take longer= =20 (initial deployments at 2.6 GHz). The operators may start offering voice se= rvice=20 as a combination of LTE VoIP and Circuit Switched voice, the call handover= =20 techniques between the two have been standardized by 3GPP (but not tested i= n the=20 field yet). One of the interesting questions about LTE indeed is whether go= od=20 quality VoIP only works as offered by the access operator, since they can=20 provision the connections used for their own services, or can we make acces= s=20 operator independent real-time services good enough too. If the buffers, L2= =20 modes etc. things that can be configured are a major issue, we may need=20 something like HOMEGATE for wide area wireless :)
 
Markus
 <= /DIV>
From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: 23 November, 2009 23:36
To:=20 mlinsner@cisco.com
Cc: ecrit@ietf.org
Subject: Re: [E= crit]=20 wireless VOIP is dead

The data dongles, etc. are indeed "data only" devices. =20 However, today they only represent a small fraction of all wireless=20 endpoints.  It is conceivable that this could change with the=20 introduction of new computing devices with built in WWAN chipsets (such a= s=20 netbooks or tablets).   But the current "attach rate" of WWAN=20 chipsets is currently much lower than with free wireless technologies suc= h as=20 WLAN, Bluetooth or even GPS.  In the current economic environment, t= hose=20 wireless chipsets are selling a lot better than WWAN chipsets which requi= re=20 "data only" plans running $60+/month. 

In terms of jitter, t= his=20 varies considerably based on the specifics of a particular deployment.&nb= sp;=20 The rapid increase in usage of smartphones has put a lot of pressure on=20 existing networks, and many are now running very close to capacity. = So=20 even though we have seen some loosening of VOIP restrictions (my understa= nding=20 is that Skype use is no longer restricted to WLAN, for example), the user= =20 experience during peak usage times will often not be very good.

I= 've=20 also seen networks with self-inflicted design problems.  For example= ,=20 sometimes the GGSN buffering is over-provisioned, in the mistaken belief = that=20 this somehow will decrease packet loss.  Instead, it results in a=20 sawtooth ramp up in delay as the queues fill, followed by sustained packe= t=20 loss as incoming packets drop until the queue can be slowly emptied. = ; Not=20 good for VOIP.

As to whether future technologies such as LTE can = be=20 provide a better VOIP experience, I'm skeptical.  In the medium term= , LTE=20 is most likely to be deployed as an "infill" technology, providing higher= =20 speed data access in areas with a high density of data users.  This = kind=20 of incremental deployment is much more economical than attempting to crea= te a=20 "greenfield" 4G network, so it is quite likely to happen, paid for by all= the=20 new smartphone data plans. 

The question is whether all thos= e new=20 smartphones and data plans will transition to use of VOIP in the near=20 future.  I doubt it.  As long as LTE coverage remains spotty, a= nd=20 wireless networks remain congested, demand for wireless data bandwidth wi= ll=20 run ahead of supply.  Without better handling of congestion (such as= by=20 using some of the techniques discussed in the Transport Area, such as LED= BAT=20 or Re-ECN), the VOIP user experience won't be good enough to handle a ver= y=20 large fraction of calls, even if restrictions on VOIP usage are=20 removed.

> Bernard,
>
> What would you consider th= e=20 data dongles and mifi thingies? Aren't those a
> data only=20 service?
>
> My experience has been that VoIP over 3G is les= s=20 than desirable due to
> jitter. Even the most forgiving of codecs=20 (Skype) struggle with the jitter
> on 3G.
>
>=20 -Marc-
>
>
> On 11/23/09 2:01 PM, "Bernard Aboba"=20 <bernard_aboba@hotmail.com> wrote:
>
> >> I subm= it=20 that the relatively slow uptake of data-only is due largely to
>=20 >> the fact that the providers are clinging to voice-based business= =20 models....
> >> widespread use of VOIP on data-only mobile de= vices=20 is inevitable.
> >
> > While I'd agree that it's likel= y to=20 happen at some point, there is no "data
> > only" wireless techn= ology=20 on the horizon that seems likely to result in
> > widespread=20 deployment of wireless VOIP in the near future.
> >
> >= ;=20 Today's fragmented hotspot deployments with their web portal-based=20 access
> > model are not exactly "VOIP-friendly".
> >=20
> > Even greenfield wireless providers with no existing voice-b= ased=20 business model
> > have failed in their introduction of "data-on= ly"=20 plans. Typically this is due
> > to unfavorable speed/power and= =20 cost/coverage tradeoffs. This problem occurs
> > because next=20 generation wireless data technologies have greatly increased
> >= =20 power consumption and much reduced coverage radius compared with=20 existing
> > technologies. Capital and maintenance costs rise wi= th=20 the inverse square of
> > the coverage ratio. So reducing the=20 coverage radius by 50 percent increases
> > cost by 400 percent.= =20 Similarly, power consumption increases more than
> > linearly wi= th=20 speed. These basic mathematical principles have had devastating
> &= gt;=20 effects on the prospects of "data only" wireless networks, whether they=20 be
> > municipal networks unable to provide acceptable coverage = with=20 802.11 APs
> > running at 2.4 or 5 Gz mounted on lamp-posts 600 = feet=20 apart or 2.5 Ghz WiMAX
> > pilots that have only demonstrated a = 1-2=20 mile coverage radius. The bottom lin
> > e is that the 2.4/2.5 o= r 5=20 Ghz spectrum bands are not hospitable to
> > construction of via= ble=20 "data only" networks.
> >
> > It's possible that alloc= ation=20 of spectrum with longer propagation
> > characteristics (e.g. Wh= ite=20 Spaces) may help in overcoming coverage obstacles,
> > but that = is=20 years away.
> >
> >> That isn't to imply that there= =20 aren't still roadblocks. For example,
> >> here in Canada, th= e=20 growth of mobile data is severely restricted by the
> >> lack= of=20 competition leading to mediocre selection of devices (we just
> >= ;>=20 got the iPhone about a year ago) and very high data prices.
> >= =20
> > Here in the U.S. we have seen "data only" wireless networks= =20 offering access
> > for as little as $20/month fail to sign up e= ven 5=20 percent of the population.
> >
> >=20 _______________________________________________
> > Ecrit mailin= g=20 list
> > Ecrit@ietf.org
> >=20 https://www.ietf.org/mailman/listinfo/ecrit
>
>=20
--_000_B3F72E5548B10A4A8E6F4795430F84182D31AF9C33NOKEUMSG02mgd_-- From drage@alcatel-lucent.com Wed Nov 25 04:44:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE603A6A39 for ; Wed, 25 Nov 2009 04:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ZMq-Ih05a1 for ; Wed, 25 Nov 2009 04:44:35 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 7C7623A6A0F for ; Wed, 25 Nov 2009 04:44:34 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPCiJip023124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 13:44:19 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 Nov 2009 13:44:19 +0100 From: "DRAGE, Keith (Keith)" To: Jong Yul Kim , Wonsang Song Date: Wed, 25 Nov 2009 13:44:18 +0100 Thread-Topic: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] Thread-Index: AcptTy/HJQz/KGpaRHW/x73oimw98gAcyUpw Message-ID: References: <4B0AF639.7020501@cs.columbia.edu> <4B0C1245.8030507@cs.columbia.edu> <4B0C5387.4020006@columbia.edu> In-Reply-To: <4B0C5387.4020006@columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:44:36 -0000 In the UK automatic alarm systems and other telemetry type systems are not = emergency calls. I assume that applies in many countries. The only data type system I know of which are treated as emergency calls ar= e the eCALL mechanisms being now introduced into vehicles, whereby if senso= rs in the car activate in response to say an accident, then the car automat= ically makes an emergency call. This emergency call is essentially a standa= rd cellphone emergency call with some additional marking, and is made as a = modem data call. SMS is NOT used. In regard to SMS, it was designed as a store and forward service, with the = delivery optimised to delivery over mobile phones with constraints caused b= y that. Asking if there is a technical problem with use for emergency calls= , well the answer is something like asking if I can use the postal service = for emergency calls. The service would have to be respecified, and then dep= loyed in that new specification.=20 regards Keith > -----Original Message----- > From: Jong Yul Kim [mailto:jk2520@columbia.edu]=20 > Sent: Tuesday, November 24, 2009 9:44 PM > To: Wonsang Song > Cc: DRAGE, Keith (Keith); ecrit@ietf.org > Subject: Re: [Ecrit] [Fwd: New Version Notification for=20 > draft-kim-ecrit-text-00] >=20 > Another example would be that it may be better for automatic=20 > alarm systems (burglary alarms) or telematics systems with=20 > full IP endpoints to use page-mode communications with the=20 > PSAP as these would not be the traditional human-to-human=20 > communication but a one-way communication. >=20 > Anyway, as more devices and protocols are used to ask for=20 > emergency help, there may be some that fit the page-mode=20 > model better than the session-based one. >=20 > Also, the fact that SMS is a deferred service is a big=20 > limitation to its usefulness as an emergency communication=20 > medium. But is this a technical problem? I think it's more of=20 > a motivation problem: there's no motivation for carriers to=20 > do anything else at this point since PSAPs do not answer SMS=20 > anyway. I believe this will change. >=20 > Jong Yul >=20 >=20 >=20 > Wonsang Song wrote: > > This draft does not suggest to use page mode instead of=20 > session mode=20 > > for the emergency text communication. This is for the case=20 > where the=20 > > endpoint is not capable of creating session or for the=20 > existing text=20 > > communication methods that are lack of session, such like=20 > IM and SMS. > >=20 > > Wonsang Song > >=20 > >=20 > > DRAGE, Keith (Keith) wrote: > >> So did I read this correctly. > >> =20 > >> You are essentially saying you want to use page mode=20 > messaging to do=20 > >> session mode messaging? > >> =20 > >> Didn't SIMPLE investigate that path and reject it and go=20 > for MSRP as=20 > >> the solution to session mode messaging? > >> =20 > >> Why does emergency calling suddenly make the original=20 > decision making=20 > >> process in SIMPLE redundant? > >> =20 > >> regards > >> =20 > >> Keith > >> > >> =20 > -------------------------------------------------------------- > ---------- > >> *From:* ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] *On > >> Behalf Of *Wonsang Song > >> *Sent:* Monday, November 23, 2009 8:53 PM > >> *To:* ecrit@ietf.org > >> *Subject:* [Ecrit] [Fwd: New Version Notification for > >> draft-kim-ecrit-text-00] > >> > >> Hi, > >> > >> Just wanted to send a note about a new draft on using=20 > SIP MESSAGE > >> for emergency texting. > >> > >> The draft is an outcome of the collaboration between Columbia > >> University and Verizon to build an emergency texting prototype > >> system which allows people to use IM and SMS to "call" for > >> emergency help. > >> > >> If you have comments or questions, please let me know. > >> > >> Thank you, > >> Wonsang Song > >> > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for draft-kim-ecrit-text-00 > >> Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) > >> From: IETF I-D Submission Tool > >> To: jyk@cs.columbia.edu > >> CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu,=20 > p.boni@verizon.com, > >> michael.g.armstrong@verizon.com > >> > >> > >> A new version of I-D, draft-kim-ecrit-text-00.txt has been > >> successfuly submitted by Jong Yul Kim and posted to the IETF > >> repository. > >> > >> Filename: > >> draft-kim-ecrit-text > >> Revision: 00 > >> Title: Emergency Text Messaging using SIP MESSAGE > >> Creation_date: > >> 2009-11-16 > >> WG ID: Independent Submission > >> Number_of_pages: 11 > >> > >> Abstract: > >> This memo describes best current practices on how to=20 > use the SIP > >> MESSAGE method for emergency text messaging from=20 > citizen and visitors > >> to authorities. > >> > >> Status of this Memo > >> > >> This Internet-Draft is submitted to IETF in full=20 > conformance with the > >> provisions of BCP 78 and BCP 79. > >> > >> Internet-Drafts are working documents of the Internet=20 > Engineering > >> Task Force (IETF), its areas, and its working groups. =20 > Note that > >> other groups may also distribute working documents as Internet- > >> Drafts. > >> > >> Internet-Drafts are draft documents valid for a=20 > maximum of six months > >> and may be updated, replaced, or obsoleted by other=20 > documents at any > >> time. It is inappropriate to use Internet-Drafts as reference > >> material or to cite them other than as "work in progress." > >> > >> The list of current Internet-Drafts can be accessed at > >> http://www.ietf.org/ietf/1id-abstracts.txt. > >> > >> The list of Internet-Draft Shadow Directories can be=20 > accessed at > >> http://www.ietf.org/shadow.html. > >> > >> This Internet-Draft will expire on May 20, 2010. > >> > >> Copyright Notice > >> > >> Copyright (c) 2009 IETF Trust and the persons identified as the > >> document authors. All rights reserved. > >> > >> This document is subject to BCP 78 and the IETF Trust's Legal > >> Provisions Relating to IETF Documents > >> (http://trustee.ietf.org/license-info) in effect on the date of > >> publication of this document. Please review these documents > >> carefully, as they describe your rights and=20 > restrictions with respect > >> to this document. Code Components extracted from this=20 > document must > >> include Simplified BSD License text as described in=20 > Section 4.e of > >> the Trust Legal Provisions and are provided without warranty as > >> described in the BSD License. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > = From drage@alcatel-lucent.com Wed Nov 25 04:44:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFAF3A6AB2 for ; Wed, 25 Nov 2009 04:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 273ir+l31NSP for ; Wed, 25 Nov 2009 04:44:42 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id F131B3A6AAC for ; Wed, 25 Nov 2009 04:44:41 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPCiJkK023122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 13:44:19 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 Nov 2009 13:44:19 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , Richard Barnes Date: Wed, 25 Nov 2009 13:44:18 +0100 Thread-Topic: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] Thread-Index: AcptE2KUmGBQYNayQs6IZ8nacjiy3QAAKn7QAAEVmHsAKroZEA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: ecrit Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:44:43 -0000 SMS to IM interworking has two mechanisms, full interworking (3GPP TS 24.34= 1), and encapsulation of the SMS in an IM (3GPP TS 29.311). That makes 4 scenarios: 1) SMS user communicating to IM connected PSAP using interworking. The SMS = has no mechanisms of ensuring that it is always delivered to the same inter= working gateway and therefore no pseudo session can be created in the IM. A= t the moment it would also not be possible to tie location services to a pa= rticular short message. 2) SMS user communicating to IM connected PSAP using encapsulation. Similar= considerations to 1 apply. 3) IM user connected to PSAP using SMS via interworking gateway. If the IMS= user uses the mechanism in the document, presumably it will reach the shor= t message gateway, but the gateway has no means of ensuring these are all d= elivered to the same SMS endpoint except the value that appears in the requ= est-URI. 4) IM user sending SMS encapsulated in IM message via gateway. Similar issu= es to 3). regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, November 24, 2009 3:11 PM > To: DRAGE, Keith (Keith); Richard Barnes > Cc: ecrit > Subject: Re: [Ecrit] [Fwd: New Version Notification for=20 > draft-kim-ecrit-text-00] >=20 > I think that it=B9s probably better to do it this way. >=20 > It=B9s not clear to me that we can always create a session. =20 > It=B9s desirable to do so, but I=B9m not sure we can always do=20 > that. If we can=B9t always do it, then we need to use a timer=20 > to create a pseudo session, which is exactly what this draft=20 > does. The NENA requirements currently say that we accept=20 > pager mode IM, and the intention was to do it the way this=20 > draft describes. >=20 > Can you explain how the existing SMS to SIP interworking=20 > standards would be in conflict with this idea? >=20 > Brian >=20 >=20 > On 11/24/09 9:45 AM, "DRAGE, Keith (Keith)" > wrote: >=20 > > But... > > =20 > > The use case under discussion here is an end entity running=20 > LOST (and=20 > > therefore presumably an IP terminal) communicating with an IP=20 > > connected PSAP, and therefore not involving any SMS at all.=20 > Therefore=20 > > for this use case, the endpoints presumably have the full range of=20 > > choice of standardised messaging mechanisms as defined by IETF. > > =20 > > If you did want to extend the use case to SMS, I would also content=20 > > that the current standardised SMS to SIP based IM mechanisms would=20 > > break the solution suggested here as well. > > =20 > > (Also ignoring the fact as well that current SMS is by default=20 > > deferred delivery (i.e. delivered in the operator's own=20 > time and when=20 > > the recipient is available, and therefore not suitable for=20 > emergency=20 > > calls in the first place.) > > =20 > > Keith > >=20 > >> =20 > >> =20 > >>=20 > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Tuesday, November 24, 2009 2:35 PM > >> To: DRAGE, Keith (Keith) > >> Cc: ecrit > >> Subject: Re: [Ecrit] [Fwd: New Version Notification for=20 > >> draft-kim-ecrit-text-00] > >>=20 > >> =20 > >> The problem here is that SMS is a page-mode medium that's used for > >> session-mode-style conversations (see, e.g., the iPhone=20 > SMS interface). So > >> if you're going to gateway SMS into SIP and preserve these =20 > >> pseudo-sessions, you either have to do something like what=20 > this draft=20 > >> does, or you have to somehow have the gateway create=20 > sessions and map SMS messages into them. > >> I'm not immediately sure which would be a better solution,=20 > but using=20 > >> MESSAGE seems marginally more light-weight. > >>=20 > >> =20 > >> --Richard > >> =20 > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> =20 > >> =20 > >> On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote: > >>=20 > >> =20 > >>> =20 > >>> =20 > >>> So did I read this correctly. > >>> =20 > >>> =20 > >>> =20 > >>> You are essentially saying you want to use page mode =20 > messaging to=20 > >>> do session mode messaging? > >>> =20 > >>> =20 > >>> =20 > >>> Didn't SIMPLE investigate that path and reject it and go=20 > for MSRP=20 > >>> as the solution to session mode messaging? > >>> =20 > >>> =20 > >>> =20 > >>> Why does emergency calling suddenly make the original decision=20 > >>> making process in SIMPLE redundant? > >>> =20 > >>> =20 > >>> =20 > >>> regards > >>> =20 > >>> =20 > >>> =20 > >>> Keith > >>>=20 > >>> =20 > >>>> =20 > >>>> =20 > >>>>=20 > >>>> From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On=20 > >>>> Behalf Of Wonsang Song > >>>> Sent: Monday, November 23, 2009 8:53 PM > >>>> To: ecrit@ietf.org > >>>> Subject: [Ecrit] [Fwd: New Version Notification for=20 > >>>> draft-kim-ecrit-text-00] > >>>>=20 > >>>> =20 > >>>> Hi, > >>>>=20 > >>>> Just wanted to send a note about a new draft on using=20 > SIP MESSAGE=20 > >>>> for emergency texting. > >>>>=20 > >>>> The draft is an outcome of the collaboration between Columbia=20 > >>>> University and Verizon to build an emergency texting prototype=20 > >>>> system which allows people to use IM and SMS to "call"=20 > for emergency help. > >>>>=20 > >>>> If you have comments or questions, please let me know. > >>>>=20 > >>>> Thank you, > >>>> Wonsang Song > >>>>=20 > >>>>=20 > >>>> -------- Original Message -------- > >>>> Subject: New Version Notification for draft-kim-ecrit-text-00 > >>>> Date: Tue, 17 Nov 2009 11:55:17 -0800 (PST) > >>>> From: IETF I-D Submission Tool =20 > >>>> > >>>> To: jyk@cs.columbia.edu > >>>> CC: wonsang@cs.columbia.edu, hgs@cs.columbia.edu,=20 > >>>> p.boni@verizon.com, michael.g.armstrong@verizon.com > >>>>=20 > >>>>=20 > >>>> A new version of I-D, draft-kim-ecrit-text-00.txt has been=20 > >>>> successfuly submitted by Jong Yul Kim and posted to the=20 > IETF repository. > >>>>=20 > >>>> Filename: draft-kim-ecrit-text > >>>> Revision: 00 > >>>> Title: Emergency Text Messaging using SIP MESSAGE > >>>> Creation_date: 2009-11-16 > >>>> WG ID: Independent Submission > >>>> Number_of_pages: 11 > >>>>=20 > >>>> Abstract: > >>>> This memo describes best current practices on how to=20 > use the SIP=20 > >>>> MESSAGE method for emergency text messaging from citizen and=20 > >>>> visitors to authorities. > >>>>=20 > >>>> Status of this Memo > >>>>=20 > >>>> This Internet-Draft is submitted to IETF in full=20 > conformance with=20 > >>>> the provisions of BCP 78 and BCP 79. > >>>>=20 > >>>> Internet-Drafts are working documents of the Internet =20 > Engineering > >>>> Task Force (IETF), its areas, and its working groups. Note that > >>>> other groups may also distribute working documents as Internet-=20 > >>>> Drafts. > >>>>=20 > >>>> Internet-Drafts are draft documents valid for a maximum of six=20 > >>>> months and may be updated, replaced, or obsoleted by other=20 > >>>> documents at any time. It is inappropriate to use =20 > Internet-Drafts=20 > >>>> as reference material or to cite them other than as =20 > "work in progress." > >>>>=20 > >>>> The list of current Internet-Drafts can be accessed at=20 > >>>> http://www.ietf.org/ietf/1id-abstracts.txt. > >>>>=20 > >>>> The list of Internet-Draft Shadow Directories can be=20 > accessed at=20 > >>>> http://www.ietf.org/shadow.html. > >>>>=20 > >>>> This Internet-Draft will expire on May 20, 2010. > >>>>=20 > >>>> Copyright Notice > >>>>=20 > >>>> Copyright (c) 2009 IETF Trust and the persons identified as the=20 > >>>> document authors. All rights reserved. > >>>>=20 > >>>> This document is subject to BCP 78 and the IETF Trust's Legal=20 > >>>> Provisions Relating to IETF Documents > >>>> (http://trustee.ietf.org/license-info) in effect on the date of=20 > >>>> publication of this document. Please review these documents=20 > >>>> carefully, as they describe your rights and restrictions with=20 > >>>> respect to this document. Code Components extracted from this=20 > >>>> document must include Simplified BSD License text as=20 > described in=20 > >>>> Section 4.e of the Trust Legal Provisions and are =20 > provided without=20 > >>>> warranty as described in the BSD License. > >>>>=20 > >>>>=20 > >>>>=20 > >>>> The IETF Secretariat. > >>>> =20 > >>>> =20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > = From mlinsner@cisco.com Wed Nov 25 05:52:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D9A3A63EB for ; Wed, 25 Nov 2009 05:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9v7AIyXymQG for ; Wed, 25 Nov 2009 05:52:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 624F328C235 for ; Wed, 25 Nov 2009 05:52:45 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAE/FDEuQ/uCW/2dsb2JhbACaaKMtl3yCLgaBfgSNSQ X-IronPort-AV: E=Sophos;i="4.47,286,1257120000"; d="scan'208";a="440339078" Received: from ams-core-1.cisco.com ([144.254.224.150]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2009 13:52:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAPDqdPe000102; Wed, 25 Nov 2009 13:52:39 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:52:38 +0100 Received: from [10.116.195.114] ([10.116.195.114]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:52:37 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 25 Nov 2009 08:52:35 -0500 From: Marc Linsner To: , Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16gACaI0qM= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Nov 2009 13:52:38.0420 (UTC) FILETIME=[8CAF2D40:01CA6DD6] Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:52:46 -0000 John, This begs the question, "Is *trusted*, *reliable* location the right tool t= o thwart hoax emergency calls?" It seems that *trusted* location doesn't wor= k in what is described below. When emergency calling moves to the Internet, *trusted* location can/will b= e spoofed. I'm trying to get everyone to understand that putting too much emphasis on trusted location will get you in trouble. Sure, it's a tool, it has some value, but it also opens up more attack vectors. I also have a problem with the notion that network derived location is the most accurate. This is not always the case. Also, the point below is made that responders are dispatched to where the caller states the emergency is located, not where the *trusted* location dictates. So, the human already overrides the *trusted* location. Is the value derived from *trusted* worth the cost? As Francios has reported, the cost is exponentially more that the cost of the actual VoIP service. Is this due to it's perceived (marketed) value? -Marc- On 11/24/09 2:53 PM, "john.medland@bt.com" wrote: > Marc, Francois, >=20 > Without getting involved in the technical debate, I thought you may be > interested to see some figures about what we in UK term hoax calls, ie pe= ople > who report a non-existent incident. The information in " " below is 3.5 = years > old but still illustrates the problem. > =20 > " Hoax calls are costing the UK Fire and Rescue Service a massive =A3230,00= 0 a > day - =A384 million a year - and the problem is potentially putting lives i= n > danger. =20 >=20 > Approximately 50,000 hoax fire calls are responded to every year, 135 pe= r > day, by the Fire and Rescue Service in England and Wales, whose role incl= udes > providing emergency response to fires, road traffic incidents and terrori= sm. > The Economic Cost of Fire report estimates that each hoax call costs =A31,7= 00. > This equates to a disturbing =A384 million per year. A significant cost for= the > Fire and Rescue Service to absorb. >=20 > London Fire Brigade has the highest hoax call rate in the UK, attending n= early > twice as many call outs (9,686) as the second worse affected brigade, Gre= ater > Manchester (5,268) and the West Midlands (4,074). >=20 > Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, said= : > "Young people in particular need to be aware what can happen if the fire > brigade is called out under false pretences. The danger to others involv= ed in > a real emergency and the financial drain that they impose on a service th= at is > there to save people's lives. " " >=20 >=20 > UK emergency services use the location as one of the tests of how reliabl= e is > the report from a caller - if the "network provided" location (circuit > switched wireline and GSM) differs appreciably from the incident location= that > a caller is reporting, then it influences the PSAP's response and questio= nning > of the caller. >=20 > It is often children who make these hoax calls in the UK - it's difficult= to > understand why so I can't really answer Marc's question directly : we nee= d a > good psychiatrist/psychologist to answer that, but such calls are a very = real > problem and having reliable location information is an important weapon i= n > tackling these as well as for speeding-up the handling of genuine calls. >=20 >=20 > Regards=20 >=20 > John >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Francois Menard > Sent: 24 November 2009 19:25 > To: Marc Linsner > Cc: ecrit > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? >=20 > my point exactly! >=20 > f. >=20 > On 2009-11-24, at 14:19, Marc Linsner wrote: >=20 >> Why would a person requesting emergency assistance knowingly provide a >> false location? >>=20 >> -Marc- >>=20 >> On 11/24/09 1:29 PM, "John Lange" wrote: >>=20 >>> Recently I've been following the debate on this list regarding >>> veracity of location which loosely translates into a larger debate >>> about security. >>>=20 >>> If I'm understanding all of this correctly, one position is that >>> PSAPs will be resistant to solutions where the identity and location >>> of the caller can't be assured and that this necessarily requires a >>> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>>=20 >>> The other position is that the requirement for a trust relationship >>> prevents nomadic VOIP users from accessing PSAPs when out of their >>> home areas. Furthermore, these trusts can be circumvented so they >>> provide only a false sense of security. >>>=20 >>> Is this a fair characterization of the two positions? >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From khwolf1@gmail.com Wed Nov 25 06:50:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0D53A6890 for ; Wed, 25 Nov 2009 06:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F7oqSTQrwPd for ; Wed, 25 Nov 2009 06:50:09 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 474373A6851 for ; Wed, 25 Nov 2009 06:50:09 -0800 (PST) Received: by pwi6 with SMTP id 6so5345811pwi.29 for ; Wed, 25 Nov 2009 06:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JiygFKIqzpEzJAdCnPoD6n4ifsI11iMNSZrQ+jPvXlo=; b=MQlpwu0q2HJGY7GeY09OXMSfW+X696XJczlrexaC++8sOC6HwxsTDvPrYZW6uST5ti VCMGHnzPP1gJqjrVzaeEtpV1z3SVk2q/V1CenJ+MVxy0iZaH0j2duamfASpg4Hhi2rMR 9nA5YF/5W3otoNZxl+D8jmpvBSBIaRldswnBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kLv81DuRSJ9uBaqam3UqgWdMbhQO0NcsRu+6DOU81DqMfVyuZxe/hIcdRsXc0JhXoq JaRTtE6M18s+P7vZziF2lXIwyf5wrnZdgI3V0x6Hh5qx/KyKAuVT0lC2EdiUBgo9Ogyj eYPTOZICOugfo1wpWi8otXcK2V0NH96WyhgQg= MIME-Version: 1.0 Received: by 10.140.136.21 with SMTP id j21mr455300rvd.271.1259160600843; Wed, 25 Nov 2009 06:50:00 -0800 (PST) In-Reply-To: <20091026134501.DAA7F28C0E8@core3.amsl.com> References: <20091026134501.DAA7F28C0E8@core3.amsl.com> Date: Wed, 25 Nov 2009 15:50:00 +0100 Message-ID: From: Karl Heinz Wolf To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:50:10 -0000 Hannes, I just noticed the following misleading sentence in lost-sync, Section 3.3: In this example a request is made for a specific mapping (with source=3D"authoritative.bar.example" and sourceId=3D"7e3f40b098c711dbb6060800200c9a66") that is more recent than "2006-11-01T01:00:00Z". Since a getMappingsRequest with does not only request updates of the existing mappings but also missing ones, I would suggest to make that explicit in the explanation of the example: In this example a request is made for a specific mapping (with source=3D"authoritative.bar.example" and sourceId=3D"7e3f40b098c711dbb6060800200c9a66") that is more recent than "2006-11-01T01:00:00Z" as well as any missing mapping. Would this make the example clearer? Karl heinz On Mon, Oct 26, 2009 at 2:45 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Synchronizing Location-to-Serv= ice Translation (LoST) Protocol based Service Boundaries and Mapping Elemen= ts > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Schulzrinne, H. Tschofenig > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ecrit-lost-sync-08.tx= t > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 27 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-26 > > The Location-to-Service Translation (LoST) protocol is an XML-based > protocol for mapping service identifiers and geodetic or civic > location information to service URIs and service boundaries. =A0In > particular, it can be used to determine the location-appropriate > Public Safety Answering Point (PSAP) for emergency services. > > The main data structure, the element, used for > encapsulating information about service boundaries is defined in the > LoST protocol specification and circumscribes the region within which > all locations map to the same service Uniform Resource Identifier > (URI) or set of URIs for a given service. > > This document defines an XML protocol to exchange these mappings > between two nodes. =A0This mechanism is designed for the exchange of > authoritative elements between two entities. =A0Exchanging > cached elements, i.e. non-authoritative elements, is > possible but not envisioned. =A0In any case, this document can also be > used without the LoST protocol even though the format of the > element is re-used from the LoST specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From Martin.Dawson@andrew.com Wed Nov 25 07:08:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E4628C235 for ; Wed, 25 Nov 2009 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVhi1EpZNdWD for ; Wed, 25 Nov 2009 07:08:41 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 2CAA03A6A8A for ; Wed, 25 Nov 2009 07:08:41 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:14536 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5408092AbZKYPIf convert rfc822-to-8bit (ORCPT ); Wed, 25 Nov 2009 09:08:35 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 09:08:34 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 25 Nov 2009 23:08:32 +0800 From: "Dawson, Martin" To: Marc Linsner , "john.medland@bt.com" , "fmenard@xittelecom.com" Date: Wed, 25 Nov 2009 23:08:32 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16gACaI0qMAAcuIaQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F01D64767CF@SISPE7MB1.commscope.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:08:42 -0000 Marc, You make two points: 1. There is the possibility of "spoofing" the mechanisms associated with trusted location. 2. "Network determined" location isn't necessarily the best. With respect to the first, I would genuinely appreciate your elaboration of what this "attack vector" actually looks like. I'm not talking about the alleged bot net out there generating emergency service calls. That's a horse of a completely different color. Please don't invoke any scenarios that involve a "remotely controlled" point of access within the PSAP jurisdiction. That's possible today on the PSTN; it's not something a casual, foreign, caller can do. I'm talking about a user connected to the Internet in a completely different state/country/jurisdiction initiating an emergency call that manages to be routed to the local PSAP with a location reported as being local. If the mechanism used to validate location is dereference to a local Internet provider LIS, how does the attacker actually achieve this? With respect to the claim that network determined location isn't necessarily the best, I disagree. Location is determined by virtue of taking measurements. Measurements can be made by the device and/or by the network. A purely device-based approach to determining location is not able to take advantage of whatever additional measurements the network takes (e.g. uplink timing). All decent network based location service architectures include the ability for measurements taken by the device to be provided to the server as well - including any actual location determination that the device might make. That is, the network can have access to everything the device has plus the measurements only it can make. In principle, then, a network determined location can always be at least as good as what the device can do on its own. This is why SUPL has ULP pos protocols, it is why GSM has RRLP, it is why UMTS has RRC, it is why LPP is being defined for LTE and it's why our own IP location se rvice protocols need the capabilities in the measurements draft. By the same token, and tying the two points together, it's the public network operator that offers the best assurance for the emergency network operator that the information presented by the device really is valid, sane, and representative of the real location from which the call is originating. I'd challenge you to come up with a better or more recognisable third party to provide that assurance to the recipient of location information. Your, by now chronic, counsel that nothing can be perfect therefore nothing should be done makes no more sense now than it did four years ago. No, it won't be perfect; there can't be guarantees - any more than you can guarantee that somebody isn't monitoring your cell phone call despite it having state of the art encryption, or any more than you can guarantee that the bank account site your logging onto isn't actually a spoofed site. However, I believe we can raise the level of assurance for location information to be as good as it is for these services. And that's a significant level of assurance compared to your advice of "don't bother". Regards, Martin ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Marc Linsner [mlinsner@cisco.com] Sent: Thursday, 26 November 2009 12:52 AM To: john.medland@bt.com; fmenard@xittelecom.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? John, This begs the question, "Is *trusted*, *reliable* location the right tool to thwart hoax emergency calls?" It seems that *trusted* location doesn't work in what is described below. When emergency calling moves to the Internet, *trusted* location can/will be spoofed. I'm trying to get everyone to understand that putting too much emphasis on trusted location will get you in trouble. Sure, it's a tool, it has some value, but it also opens up more attack vectors. I also have a problem with the notion that network derived location is the most accurate. This is not always the case. Also, the point below is made that responders are dispatched to where the caller states the emergency is located, not where the *trusted* location dictates. So, the human already overrides the *trusted* location. Is the value derived from *trusted* worth the cost? As Francios has reported, the cost is exponentially more that the cost of the actual VoIP service. Is this due to it's perceived (marketed) value? -Marc- On 11/24/09 2:53 PM, "john.medland@bt.com" wrote: > Marc, Francois, > > Without getting involved in the technical debate, I thought you may be > interested to see some figures about what we in UK term hoax calls, ie people > who report a non-existent incident. The information in " " below is 3.5 years > old but still illustrates the problem. > > " Hoax calls are costing the UK Fire and Rescue Service a massive £230,000 a > day - £84 million a year - and the problem is potentially putting lives in > danger. > > Approximately 50,000 hoax fire calls are responded to every year, 135 per > day, by the Fire and Rescue Service in England and Wales, whose role includes > providing emergency response to fires, road traffic incidents and terrorism. > The Economic Cost of Fire report estimates that each hoax call costs £1,700. > This equates to a disturbing £84 million per year. A significant cost for the > Fire and Rescue Service to absorb. > > London Fire Brigade has the highest hoax call rate in the UK, attending nearly > twice as many call outs (9,686) as the second worse affected brigade, Greater > Manchester (5,268) and the West Midlands (4,074). > > Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, said: > "Young people in particular need to be aware what can happen if the fire > brigade is called out under false pretences. The danger to others involved in > a real emergency and the financial drain that they impose on a service that is > there to save people's lives. " " > > > UK emergency services use the location as one of the tests of how reliable is > the report from a caller - if the "network provided" location (circuit > switched wireline and GSM) differs appreciably from the incident location that > a caller is reporting, then it influences the PSAP's response and questionning > of the caller. > > It is often children who make these hoax calls in the UK - it's difficult to > understand why so I can't really answer Marc's question directly : we need a > good psychiatrist/psychologist to answer that, but such calls are a very real > problem and having reliable location information is an important weapon in > tackling these as well as for speeding-up the handling of genuine calls. > > > Regards > > John > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Francois Menard > Sent: 24 November 2009 19:25 > To: Marc Linsner > Cc: ecrit > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? > > my point exactly! > > f. > > On 2009-11-24, at 14:19, Marc Linsner wrote: > >> Why would a person requesting emergency assistance knowingly provide a >> false location? >> >> -Marc- >> >> On 11/24/09 1:29 PM, "John Lange" wrote: >> >>> Recently I've been following the debate on this list regarding >>> veracity of location which loosely translates into a larger debate >>> about security. >>> >>> If I'm understanding all of this correctly, one position is that >>> PSAPs will be resistant to solutions where the identity and location >>> of the caller can't be assured and that this necessarily requires a >>> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>> >>> The other position is that the requirement for a trust relationship >>> prevents nomadic VOIP users from accessing PSAPs when out of their >>> home areas. Furthermore, these trusts can be circumvented so they >>> provide only a false sense of security. >>> >>> Is this a fair characterization of the two positions? >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Wed Nov 25 07:19:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9483A69C0 for ; Wed, 25 Nov 2009 07:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSOQVk6yGRgu for ; Wed, 25 Nov 2009 07:19:05 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by core3.amsl.com (Postfix) with ESMTP id 42D5D3A69A2 for ; Wed, 25 Nov 2009 07:19:05 -0800 (PST) Received: from BLU137-W32 ([65.55.116.74]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 07:19:00 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ad5d22f6-9932-4c40-9dfb-aeb3b3589cd7_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Wed, 25 Nov 2009 07:19:00 -0800 Importance: Normal In-Reply-To: References: , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 15:19:00.0723 (UTC) FILETIME=[9D93DC30:01CA6DE2] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:19:07 -0000 --_ad5d22f6-9932-4c40-9dfb-aeb3b3589cd7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In practice=2C it has proved quite tricky for voice and data to co-exist we= ll on wireless data services. I believe that it is possible with the right= L2 engineering on both the client and operator side=2C even without QoS = schemes that have not gotten much deployment (e.g. multiple CIDs/PDP contex= ts). So far=2C the question has been the level of care required to get it r= ight. For example=2C some chipset vendors do not pay attention to VOIP per= formance=2C since their chips are mostly purchased for use with bulk data t= ransmission.=20 In the case of WLAN chipsets=2C the lack of interest in VOIP has lead to a = self-fulfilling prophesy=2C resulting in selection of other technologies su= ch as DECT=2C both in consumer and even enterprise scenarios (see http://ww= w.avaya.com/usa/resource/assets/casestudies/univwashcasestudyuc3920.pdf ). = =20 In general=2C I have been disappointed in wireless services operating in th= e 2.5/2.6 Ghz band. The proximity to the 2.4 Ghz unlicensed band=2C while = allowing reuse of mass market components=2C has caused quite a few interfer= ence problems and the propagation characteristics make it difficult to achi= eve excellent coverage.=20 My overall conclusion is that "all data" wireless networks are still in the= nascient stages and that this=2C along with some of the other trends could= impede the widespread deployment of the ECRIT architecture.=20 From: Markus.Isomaki@nokia.com To: bernard_aboba@hotmail.com=3B mlinsner@cisco.com CC: ecrit@ietf.org Date: Wed=2C 25 Nov 2009 09:50:32 +0100 Subject: RE: [Ecrit] wireless VOIP is dead Hi Bernard=2C =20 One reason for high jitter in many of the current 3G wireless=20 networks is that the link layer operates in "acknowledged mode". This means= that=20 at L2 a packet/frame is retransmitted if it's lost for instance due to=20 unrecoverable bit errors over the radio. For that particular user/connectio= n=2C=20 all the forthcoming packets are then waiting too until the retransmission=20 completes. As RTTs tend to be rather high and bitrates relatively slow=2C t= his=20 creates a situation where the E2E delay for a number of packets suddenly pe= aks=20 way over the average. For something like VoIP all those packets are probabl= y=20 discarded at the receiver. GGSN buffers may contribute something more to th= is=2C=20 but at least some of the network elements provide per user/connection=20 queueing=2C so the users are separated from each other what comes to=20 congestion and queuing. I'm not sure if this is going to change in newer ra= dio=20 systems such as LTE except the RTT will be lower and the transmit rate=20 higher.=20 =20 LTE deployment will differ between different regions too. In US=20 (Verizon=2C ATT both have ~700 MHz spectrum for LTE) and Japan the situatio= n may=20 actually be pretty good in a few years time=2C in Europe it will take longe= r=20 (initial deployments at 2.6 GHz). The operators may start offering voice se= rvice=20 as a combination of LTE VoIP and Circuit Switched voice=2C the call handove= r=20 techniques between the two have been standardized by 3GPP (but not tested i= n the=20 field yet). One of the interesting questions about LTE indeed is whether go= od=20 quality VoIP only works as offered by the access operator=2C since they can= =20 provision the connections used for their own services=2C or can we make acc= ess=20 operator independent real-time services good enough too. If the buffers=2C = L2=20 modes etc. things that can be configured are a major issue=2C we may need=20 something like HOMEGATE for wide area wireless :) =20 Markus =20 =20 =20 From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba Sent: 23 November=2C 2009 23:36 To:=20 mlinsner@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit]=20 wireless VOIP is dead The data dongles=2C etc. are indeed "data only" devices. =20 However=2C today they only represent a small fraction of all wireless=20 endpoints. It is conceivable that this could change with the=20 introduction of new computing devices with built in WWAN chipsets (such a= s=20 netbooks or tablets). But the current "attach rate" of WWAN=20 chipsets is currently much lower than with free wireless technologies suc= h as=20 WLAN=2C Bluetooth or even GPS. In the current economic environment=2C th= ose=20 wireless chipsets are selling a lot better than WWAN chipsets which requi= re=20 "data only" plans running $60+/month. =20 In terms of jitter=2C this=20 varies considerably based on the specifics of a particular deployment. =20 The rapid increase in usage of smartphones has put a lot of pressure on=20 existing networks=2C and many are now running very close to capacity. So= =20 even though we have seen some loosening of VOIP restrictions (my understa= nding=20 is that Skype use is no longer restricted to WLAN=2C for example)=2C the = user=20 experience during peak usage times will often not be very good.=20 I've=20 also seen networks with self-inflicted design problems. For example=2C=20 sometimes the GGSN buffering is over-provisioned=2C in the mistaken belie= f that=20 this somehow will decrease packet loss. Instead=2C it results in a=20 sawtooth ramp up in delay as the queues fill=2C followed by sustained pac= ket=20 loss as incoming packets drop until the queue can be slowly emptied. Not= =20 good for VOIP.=20 As to whether future technologies such as LTE can be=20 provide a better VOIP experience=2C I'm skeptical. In the medium term=2C= LTE=20 is most likely to be deployed as an "infill" technology=2C providing high= er=20 speed data access in areas with a high density of data users. This kind= =20 of incremental deployment is much more economical than attempting to crea= te a=20 "greenfield" 4G network=2C so it is quite likely to happen=2C paid for by= all the=20 new smartphone data plans. =20 The question is whether all those new=20 smartphones and data plans will transition to use of VOIP in the near=20 future. I doubt it. As long as LTE coverage remains spotty=2C and=20 wireless networks remain congested=2C demand for wireless data bandwidth = will=20 run ahead of supply. Without better handling of congestion (such as by=20 using some of the techniques discussed in the Transport Area=2C such as L= EDBAT=20 or Re-ECN)=2C the VOIP user experience won't be good enough to handle a v= ery=20 large fraction of calls=2C even if restrictions on VOIP usage are=20 removed. > Bernard=2C >=20 > What would you consider the=20 data dongles and mifi thingies? Aren't those a > data only=20 service? >=20 > My experience has been that VoIP over 3G is less=20 than desirable due to > jitter. Even the most forgiving of codecs=20 (Skype) struggle with the jitter > on 3G. >=20 >=20 -Marc- >=20 >=20 > On 11/23/09 2:01 PM=2C "Bernard Aboba"=20 wrote: >=20 > >> I submit=20 that the relatively slow uptake of data-only is due largely to >=20 >> the fact that the providers are clinging to voice-based business=20 models.... > >> widespread use of VOIP on data-only mobile devices=20 is inevitable. > >=20 > > While I'd agree that it's likely to=20 happen at some point=2C there is no "data > > only" wireless technology=20 on the horizon that seems likely to result in > > widespread=20 deployment of wireless VOIP in the near future. > >=20 > >=20 Today's fragmented hotspot deployments with their web portal-based=20 access > > model are not exactly "VOIP-friendly". > >=20 =20 > > Even greenfield wireless providers with no existing voice-based=20 business model > > have failed in their introduction of "data-only"=20 plans. Typically this is due > > to unfavorable speed/power and=20 cost/coverage tradeoffs. This problem occurs > > because next=20 generation wireless data technologies have greatly increased > >=20 power consumption and much reduced coverage radius compared with=20 existing > > technologies. Capital and maintenance costs rise with=20 the inverse square of > > the coverage ratio. So reducing the=20 coverage radius by 50 percent increases > > cost by 400 percent.=20 Similarly=2C power consumption increases more than > > linearly with=20 speed. These basic mathematical principles have had devastating > >=20 effects on the prospects of "data only" wireless networks=2C whether they= =20 be > > municipal networks unable to provide acceptable coverage with=20 802.11 APs > > running at 2.4 or 5 Gz mounted on lamp-posts 600 feet=20 apart or 2.5 Ghz WiMAX > > pilots that have only demonstrated a 1-2=20 mile coverage radius. The bottom lin > > e is that the 2.4/2.5 or 5=20 Ghz spectrum bands are not hospitable to > > construction of viable=20 "data only" networks. > >=20 > > It's possible that allocation=20 of spectrum with longer propagation > > characteristics (e.g. White=20 Spaces) may help in overcoming coverage obstacles=2C > > but that is=20 years away. > >=20 > >> That isn't to imply that there=20 aren't still roadblocks. For example=2C > >> here in Canada=2C the=20 growth of mobile data is severely restricted by the > >> lack of=20 competition leading to mediocre selection of devices (we just > >>=20 got the iPhone about a year ago) and very high data prices. > >=20 =20 > > Here in the U.S. we have seen "data only" wireless networks=20 offering access > > for as little as $20/month fail to sign up even 5=20 percent of the population. > >=20 > >=20 _______________________________________________ > > Ecrit mailing=20 list > > Ecrit@ietf.org > >=20 https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 = --_ad5d22f6-9932-4c40-9dfb-aeb3b3589cd7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In practice=2C it has proved quite tricky for voice and data to co-exist we= ll on wireless data services. =3B I believe that it is possible with th= e right L2 engineering on both the client and operator side=2C =3B even= without =3B QoS schemes that have not gotten much deployment (e.g. mul= tiple CIDs/PDP contexts). So far=2C the question has been the level of care= required to get it right. =3B For example=2C some chipset vendors do n= ot pay attention to VOIP performance=2C since their chips are mostly purcha= sed for use with bulk data transmission.

In the case of WLAN chipse= ts=2C the lack of interest in VOIP has lead to a self-fulfilling prophesy= =2C resulting in selection of other technologies such as DECT=2C both in co= nsumer and even enterprise scenarios (see http://www.avaya.com/usa/resource= /assets/casestudies/univwashcasestudyuc3920.pdf ). =3B

In gener= al=2C I have been disappointed in wireless services operating in the 2.5/2.= 6 Ghz band. =3B The proximity to the 2.4 Ghz unlicensed band=2C while a= llowing reuse of mass market components=2C has caused quite a few interfere= nce problems and the propagation characteristics make it difficult to achie= ve excellent coverage.

My overall conclusion is that "all data" wir= eless networks are still in the nascient stages and that this=2C along with= some of the other trends could impede the widespread deployment of the ECR= IT architecture.

From: Markus.Isomaki@nokia= .com
To: bernard_aboba@hotmail.com=3B mlinsner@cisco.com
CC: ecrit@ie= tf.org
Date: Wed=2C 25 Nov 2009 09:50:32 +0100
Subject: RE: [Ecrit] w= ireless VOIP is dead

Hi Bernard=2C
 =3B
One reason for high jitter in many of the= current 3G wireless=20 networks is that the link layer operates in "acknowledged mode". This means= that=20 at L2 a packet/frame is retransmitted if it's lost for instance due to=20 unrecoverable bit errors over the radio. For that particular user/connectio= n=2C=20 all the forthcoming packets are then waiting too until the retransmission=20 completes. As RTTs tend to be rather high and bitrates relatively slow=2C t= his=20 creates a situation where the E2E delay for a number of packets suddenly pe= aks=20 way over the average. For something like VoIP all those packets are probabl= y=20 discarded at the receiver. GGSN buffers may contribute something more to th= is=2C=20 but at least some =3Bof the network elements provide per user/connectio= n=20 queueing=2C so the users are separated from each other what comes to=20 congestion =3Band queuing. =3BI'm not sure if this is going to ch= ange in newer radio=20 systems such as =3BLTE except the RTT will be lower and the transmit ra= te=20 higher.
 =3B
LTE deployment will differ between differ= ent regions too. In US=20 (Verizon=2C ATT both have ~700 MHz spectrum for LTE) and Japan the situatio= n may=20 actually be pretty good in a few years time=2C in Europe it will take longe= r=20 (initial deployments at 2.6 GHz). The operators may start offering voice se= rvice=20 as a combination of LTE VoIP and Circuit Switched voice=2C the call handove= r=20 techniques between the two have been standardized by 3GPP (but not tested i= n the=20 field yet). One of the interesting questions about LTE indeed is whether go= od=20 quality VoIP only works as offered by the access operator=2C since they can= =20 provision the connections used for their own services=2C or can we make acc= ess=20 operator independent real-time services good enough too. If the buffers=2C = L2=20 modes etc. things that can be configured are a major issue=2C we may need=20 something like HOMEGATE for wide area wireless :)
 =3B
Markus
 =3B

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: 23 November=2C 2009 23:36
To:=20 mlinsner@cisco.com
Cc: ecrit@ietf.org
Subject: Re: [E= crit]=20 wireless VOIP is dead

The data dongles=2C etc. are indeed "data only" devices. = =3B=20 However=2C today they only represent a small fraction of all wireless=20 endpoints. =3B It is conceivable that this could change with the=20 introduction of new computing devices with built in WWAN chipsets (such a= s=20 netbooks or tablets). =3B =3B But the current "attach rate" of WW= AN=20 chipsets is currently much lower than with free wireless technologies suc= h as=20 WLAN=2C Bluetooth or even GPS. =3B In the current economic environmen= t=2C those=20 wireless chipsets are selling a lot better than WWAN chipsets which requi= re=20 "data only" plans running $60+/month. =3B

In terms of jitter= =2C this=20 varies considerably based on the specifics of a particular deployment.&nb= sp=3B=20 The rapid increase in usage of smartphones has put a lot of pressure on=20 existing networks=2C and many are now running very close to capacity.&nbs= p=3B So=20 even though we have seen some loosening of VOIP restrictions (my understa= nding=20 is that Skype use is no longer restricted to WLAN=2C for example)=2C the = user=20 experience during peak usage times will often not be very good.

I= 've=20 also seen networks with self-inflicted design problems. =3B For examp= le=2C=20 sometimes the GGSN buffering is over-provisioned=2C in the mistaken belie= f that=20 this somehow will decrease packet loss. =3B Instead=2C it results in = a=20 sawtooth ramp up in delay as the queues fill=2C followed by sustained pac= ket=20 loss as incoming packets drop until the queue can be slowly emptied. = =3B Not=20 good for VOIP.

As to whether future technologies such as LTE can = be=20 provide a better VOIP experience=2C I'm skeptical. =3B In the medium = term=2C LTE=20 is most likely to be deployed as an "infill" technology=2C providing high= er=20 speed data access in areas with a high density of data users. =3B Thi= s kind=20 of incremental deployment is much more economical than attempting to crea= te a=20 "greenfield" 4G network=2C so it is quite likely to happen=2C paid for by= all the=20 new smartphone data plans. =3B

The question is whether all th= ose new=20 smartphones and data plans will transition to use of VOIP in the near=20 future. =3B I doubt it. =3B As long as LTE coverage remains spott= y=2C and=20 wireless networks remain congested=2C demand for wireless data bandwidth = will=20 run ahead of supply. =3B Without better handling of congestion (such = as by=20 using some of the techniques discussed in the Transport Area=2C such as L= EDBAT=20 or Re-ECN)=2C the VOIP user experience won't be good enough to handle a v= ery=20 large fraction of calls=2C even if restrictions on VOIP usage are=20 removed.

>=3B Bernard=2C
>=3B
>=3B What would you con= sider the=20 data dongles and mifi thingies? Aren't those a
>=3B data only=20 service?
>=3B
>=3B My experience has been that VoIP over 3G is= less=20 than desirable due to
>=3B jitter. Even the most forgiving of codecs= =20 (Skype) struggle with the jitter
>=3B on 3G.
>=3B
>=3B=20 -Marc-
>=3B
>=3B
>=3B On 11/23/09 2:01 PM=2C "Bernard Ab= oba"=20 <=3Bbernard_aboba@hotmail.com>=3B wrote:
>=3B
>=3B >=3B&= gt=3B I submit=20 that the relatively slow uptake of data-only is due largely to
>=3B= =20 >=3B>=3B the fact that the providers are clinging to voice-based busi= ness=20 models....
>=3B >=3B>=3B widespread use of VOIP on data-only mob= ile devices=20 is inevitable.
>=3B >=3B
>=3B >=3B While I'd agree that it= 's likely to=20 happen at some point=2C there is no "data
>=3B >=3B only" wireless= technology=20 on the horizon that seems likely to result in
>=3B >=3B widespread= =20 deployment of wireless VOIP in the near future.
>=3B >=3B
>= =3B >=3B=20 Today's fragmented hotspot deployments with their web portal-based=20 access
>=3B >=3B model are not exactly "VOIP-friendly".
>=3B = >=3B=20
>=3B >=3B Even greenfield wireless providers with no existing voi= ce-based=20 business model
>=3B >=3B have failed in their introduction of "dat= a-only"=20 plans. Typically this is due
>=3B >=3B to unfavorable speed/power = and=20 cost/coverage tradeoffs. This problem occurs
>=3B >=3B because nex= t=20 generation wireless data technologies have greatly increased
>=3B &g= t=3B=20 power consumption and much reduced coverage radius compared with=20 existing
>=3B >=3B technologies. Capital and maintenance costs ris= e with=20 the inverse square of
>=3B >=3B the coverage ratio. So reducing th= e=20 coverage radius by 50 percent increases
>=3B >=3B cost by 400 perc= ent.=20 Similarly=2C power consumption increases more than
>=3B >=3B linea= rly with=20 speed. These basic mathematical principles have had devastating
>=3B= >=3B=20 effects on the prospects of "data only" wireless networks=2C whether they= =20 be
>=3B >=3B municipal networks unable to provide acceptable cover= age with=20 802.11 APs
>=3B >=3B running at 2.4 or 5 Gz mounted on lamp-posts = 600 feet=20 apart or 2.5 Ghz WiMAX
>=3B >=3B pilots that have only demonstrate= d a 1-2=20 mile coverage radius. The bottom lin
>=3B >=3B e is that the 2.4/2= .5 or 5=20 Ghz spectrum bands are not hospitable to
>=3B >=3B construction of= viable=20 "data only" networks.
>=3B >=3B
>=3B >=3B It's possible th= at allocation=20 of spectrum with longer propagation
>=3B >=3B characteristics (e.g= . White=20 Spaces) may help in overcoming coverage obstacles=2C
>=3B >=3B but= that is=20 years away.
>=3B >=3B
>=3B >=3B>=3B That isn't to imply = that there=20 aren't still roadblocks. For example=2C
>=3B >=3B>=3B here in Ca= nada=2C the=20 growth of mobile data is severely restricted by the
>=3B >=3B>= =3B lack of=20 competition leading to mediocre selection of devices (we just
>=3B &= gt=3B>=3B=20 got the iPhone about a year ago) and very high data prices.
>=3B >= =3B=20
>=3B >=3B Here in the U.S. we have seen "data only" wireless netw= orks=20 offering access
>=3B >=3B for as little as $20/month fail to sign = up even 5=20 percent of the population.
>=3B >=3B
>=3B >=3B=20 _______________________________________________
>=3B >=3B Ecrit ma= iling=20 list
>=3B >=3B Ecrit@ietf.org
>=3B >=3B=20 https://www.ietf.org/mailman/listinfo/ecrit
>=3B
>=3B=20
= --_ad5d22f6-9932-4c40-9dfb-aeb3b3589cd7_-- From john@johnlange.ca Wed Nov 25 07:35:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D9B3A6A5A for ; Wed, 25 Nov 2009 07:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyrjqmoezkfq for ; Wed, 25 Nov 2009 07:35:18 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 30F2B3A6A63 for ; Wed, 25 Nov 2009 07:35:18 -0800 (PST) Received: by yxe4 with SMTP id 4so6784418yxe.32 for ; Wed, 25 Nov 2009 07:35:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.9.39 with SMTP id 39mr9157996ybi.35.1259163305250; Wed, 25 Nov 2009 07:35:05 -0800 (PST) X-Originating-IP: [205.200.120.72] In-Reply-To: References: Date: Wed, 25 Nov 2009 09:35:05 -0600 Message-ID: From: John Lange To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:35:19 -0000 ________________________________ > From: Markus.Isomaki@nokia.com > To: bernard_aboba@hotmail.com; mlinsner@cisco.com > CC: ecrit@ietf.org > Date: Wed, 25 Nov 2009 09:50:32 +0100 > Subject: RE: [Ecrit] wireless VOIP is dead > > Hi Bernard, > > One reason for high jitter in many of the current 3G wireless networks is > that the link layer operates in "acknowledged mode". This means that at L2 a > packet/frame is retransmitted if it's lost for instance due to unrecoverable > bit errors over the radio. For that particular user/connection, all the > forthcoming packets are then waiting too until the retransmission completes. This seems like the classic bellhead vs. nethead battle. Bellheads built the wireless network and made it "smart" at layer 2. The network therefore tries to do the work of ensuring all the data makes it from end-to-end. The "smart" network makes sure all the packets arrive at the endpoints but the delay results in them being discarded anyway. In the nethead model, it's the TCP layer (or higher if you choose UDP) that worries (or not) about the packets making it from end-to-end. Given that people use wireless data for IP based networks, does operating in ack mode make any sense? It's just redundant at the TCP layer and broken at the UDP layer. Or maybe this is just a convenient way of ensuring the network isn't good for real-time data applications like voice? -- John Lange www.johnlange.ca From bernard_aboba@hotmail.com Wed Nov 25 08:16:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD78928C26C for ; Wed, 25 Nov 2009 08:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFdn+-k5rlHm for ; Wed, 25 Nov 2009 08:16:21 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by core3.amsl.com (Postfix) with ESMTP id ADE843A6A94 for ; Wed, 25 Nov 2009 08:16:21 -0800 (PST) Received: from BLU137-W36 ([65.55.116.8]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 08:16:17 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c0a7b9a9-b900-4c17-bff7-ddab7b9b9f35_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Wed, 25 Nov 2009 08:16:16 -0800 Importance: Normal In-Reply-To: References: , , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 16:16:17.0067 (UTC) FILETIME=[9DCC57B0:01CA6DEA] Cc: ecrit@ietf.org Subject: Re: [Ecrit] wireless VOIP is dead X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:16:22 -0000 --_c0a7b9a9-b900-4c17-bff7-ddab7b9b9f35_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Given that people use wireless data for IP based networks=2C does > operating in ack mode make any sense? It's just redundant at the TCP > layer and broken at the UDP layer.=20 =20 For wireless data traffic=2C (most of which runs over TCP)=2C limited retra= nsmission maximizes throughput=2C as long as the RTT from the client to the cell towe= r is much less than the end-to-end RTT. Without retransmission=2C the packet error rate (PER) could be too high to allow TCP to function.=20 =20 For example=2C I have seen WLAN deployments with frame error rates (FER) as= high as 50 percent=2C requiring multiple retransmissions to get the PER down to= a reasonable level. This is why standards such as IEEE 802.11 specify 7 as the default = maximum number of retransmissions. =20 =20 >Or maybe this is just a convenient way of ensuring the network isn't good = for real-time=20 >data applications like voice? =20 Today=2C VOIP performance testing is relatively rare among wireless LAN chi= pset vendors. =20 This is because good results on these tests are rarely a purchase criteria = from customers.=20 The customers in turn don't care that much about wireless VOIP performance = because it's not a big revenue generator. This isn't a conspiracy=2C it's just capitali= sm at work.=20 =20 =20 =20 =20 =20 = --_c0a7b9a9-b900-4c17-bff7-ddab7b9b9f35_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Given that people use wireless data for IP based networks=2C doe= s
>=3B operating in ack mode make any sense? It's just redundant at th= e TCP
>=3B layer and broken at the UDP layer.
 =3B
For wireless data traffic=2C (most of which runs over TCP)=2C =3Blimite= d retransmission
maximizes throughput=2C as long as the RTT from the client to the cell towe= r
is much less than the end-to-end RTT. =3B =3BWithout retransmission= =2C the packet
error rate (PER) could =3Bbe too high to allow TCP to function.
 =3B
For example=2C I have =3Bseen WLAN deployments with =3Bframe error = rates (FER) as high
as 50 =3B percent=2C requiring multiple retransmissions to get the PER = down to a reasonable
level. =3B This is why standards such as IEEE 802.11 specify 7 as the d= efault maximum
number of retransmissions. =3B =3B
 =3B
>=3BOr maybe this is just a convenient way of ensuring the network isn't = good for real-time
>=3Bdata applications =3Blike voice?
 =3B
Today=2C VOIP performance testing is relatively rare among wireless LAN chi= pset vendors. =3B
This is because good results on these tests are rarely a purchase criteria = from customers.
The customers in turn don't care that much about wireless VOIP performance = because it's
not a big revenue generator. =3B This isn't a conspiracy=2C it's just c= apitalism at work.
 =3B
 =3B
 =3B

 =3B
 =3B
= --_c0a7b9a9-b900-4c17-bff7-ddab7b9b9f35_-- From mlinsner@cisco.com Wed Nov 25 08:59:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7783328C14E for ; Wed, 25 Nov 2009 08:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.902 X-Spam-Level: X-Spam-Status: No, score=-7.902 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grgWWqVIXoud for ; Wed, 25 Nov 2009 08:59:50 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5043F28C232 for ; Wed, 25 Nov 2009 08:59:49 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4AAJvxDEuQ/uCWe2dsb2JhbACaaIEwAQELCyQGoWKJFgiOQoIlBQQGDgiBaASNSQ X-IronPort-AV: E=Sophos;i="4.47,287,1257120000"; d="scan'208";a="55206068" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2009 16:59:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAPGxbaG020900; Wed, 25 Nov 2009 16:59:38 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 17:59:37 +0100 Received: from [10.116.195.114] ([10.116.195.114]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 17:59:36 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 25 Nov 2009 11:59:31 -0500 From: Marc Linsner To: "Dawson, Martin" , "john.medland@bt.com" , "fmenard@xittelecom.com" Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16gACaI0qMAAcuIaQAEu8h9 In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D64767CF@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Nov 2009 16:59:37.0083 (UTC) FILETIME=[AB874CB0:01CA6DF0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17030.007 X-TM-AS-Result: No--9.823200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:59:51 -0000 Martin, You conveniently ignored a couple more points I made. - If trusted location is utopia, why are "Hoax calls are costing the UK Fir= e and Rescue Service a massive =A3230,000 a day - =A384 million a year" ??? - The promotion of trusted location *could* include some marketing. To answer your questions. Trusted Location attack vector. Even after excluding all the use cases, yo= u forgot the replay attack. Network determined location. Example: Would an emergency responder in Chicago be able to provide a quicker response with location: 1) from the network - 41 52.735N, 87 38.168W or 2) from the caller - NW corner of the 105th floor of the Willis Tower Oh, another point you missed. I do/did admit that trusted location has value, but it must be put into the context of *ALL* attacks on a PSAP and it's value determined in accordance with it's cost. That cost includes the business case of the Internet access provider (IAP). Forcing the IAP to implement mechanisms/devices that don't add value to their business model does not bode well for a future where accessing the Internet is suppose to get easier, not harder. The IAP providing location is cost delta 2, providing trusted location is 2 to the Nth power. "Trusted" location vs location adds zero value to a normal/legitimate calle= r requesting emergency assistance. Hence trusted location is a tool to mitigate attacks, but given the big picture cost delta between location and trusted location, is it worth the cost? -Marc- On 11/25/09 10:08 AM, "Dawson, Martin" wrote: > Marc, >=20 > You make two points: >=20 > 1. There is the possibility of "spoofing" the mechanisms associated with > trusted location. > 2. "Network determined" location isn't necessarily the best. >=20 > With respect to the first, I would genuinely appreciate your elaboration = of > what this "attack vector" actually looks like. I'm not talking about the > alleged bot net out there generating emergency service calls. That's a ho= rse > of a completely different color. Please don't invoke any scenarios that > involve a "remotely controlled" point of access within the PSAP jurisdict= ion. > That's possible today on the PSTN; it's not something a casual, foreign, > caller can do. I'm talking about a user connected to the Internet in a > completely different state/country/jurisdiction initiating an emergency c= all > that manages to be routed to the local PSAP with a location reported as b= eing > local. If the mechanism used to validate location is dereference to a loc= al > Internet provider LIS, how does the attacker actually achieve this? >=20 > With respect to the claim that network determined location isn't necessar= ily > the best, I disagree. Location is determined by virtue of taking measurem= ents. > Measurements can be made by the device and/or by the network. A purely > device-based approach to determining location is not able to take advanta= ge of > whatever additional measurements the network takes (e.g. uplink timing). = All > decent network based location service architectures include the ability f= or > measurements taken by the device to be provided to the server as well - > including any actual location determination that the device might make. T= hat > is, the network can have access to everything the device has plus the > measurements only it can make. In principle, then, a network determined > location can always be at least as good as what the device can do on its = own. > This is why SUPL has ULP pos protocols, it is why GSM has RRLP, it is why= UMTS > has RRC, it is why LPP is being defined for LTE and it's why our own IP > location service protocols need the capabilities in the measurements draf= t. >=20 > By the same token, and tying the two points together, it's the public net= work > operator that offers the best assurance for the emergency network operato= r > that the information presented by the device really is valid, sane, and > representative of the real location from which the call is originating. I= 'd > challenge you to come up with a better or more recognisable third party t= o > provide that assurance to the recipient of location information. >=20 > Your, by now chronic, counsel that nothing can be perfect therefore nothi= ng > should be done makes no more sense now than it did four years ago. No, it > won't be perfect; there can't be guarantees - any more than you can guara= ntee > that somebody isn't monitoring your cell phone call despite it having sta= te of > the art encryption, or any more than you can guarantee that the bank acco= unt > site your logging onto isn't actually a spoofed site. However, I believe = we > can raise the level of assurance for location information to be as good a= s it > is for these services. And that's a significant level of assurance compar= ed to > your advice of "don't bother". >=20 > Regards, > Martin > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Marc > Linsner [mlinsner@cisco.com] > Sent: Thursday, 26 November 2009 12:52 AM > To: john.medland@bt.com; fmenard@xittelecom.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? >=20 > John, >=20 > This begs the question, "Is *trusted*, *reliable* location the right tool= to > thwart hoax emergency calls?" It seems that *trusted* location doesn't w= ork > in what is described below. >=20 > When emergency calling moves to the Internet, *trusted* location can/will= be > spoofed. >=20 > I'm trying to get everyone to understand that putting too much emphasis o= n > trusted location will get you in trouble. Sure, it's a tool, it has some > value, but it also opens up more attack vectors. >=20 > I also have a problem with the notion that network derived location is th= e > most accurate. This is not always the case. >=20 > Also, the point below is made that responders are dispatched to where the > caller states the emergency is located, not where the *trusted* location > dictates. So, the human already overrides the *trusted* location. >=20 > Is the value derived from *trusted* worth the cost? As Francios has > reported, the cost is exponentially more that the cost of the actual VoIP > service. Is this due to it's perceived (marketed) value? >=20 > -Marc- >=20 >=20 > On 11/24/09 2:53 PM, "john.medland@bt.com" wrote: >=20 >> Marc, Francois, >>=20 >> Without getting involved in the technical debate, I thought you may be >> interested to see some figures about what we in UK term hoax calls, ie p= eople >> who report a non-existent incident. The information in " " below is 3.5 >> years >> old but still illustrates the problem. >>=20 >> " Hoax calls are costing the UK Fire and Rescue Service a massive =A3230,0= 00 a >> day - =A384 million a year - and the problem is potentially putting lives = in >> danger. >>=20 >> Approximately 50,000 hoax fire calls are responded to every year, 135 p= er >> day, by the Fire and Rescue Service in England and Wales, whose role inc= ludes >> providing emergency response to fires, road traffic incidents and terror= ism. >> The Economic Cost of Fire report estimates that each hoax call costs =A31,= 700. >> This equates to a disturbing =A384 million per year. A significant cost fo= r the >> Fire and Rescue Service to absorb. >>=20 >> London Fire Brigade has the highest hoax call rate in the UK, attending >> nearly >> twice as many call outs (9,686) as the second worse affected brigade, Gr= eater >> Manchester (5,268) and the West Midlands (4,074). >>=20 >> Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, sai= d: >> "Young people in particular need to be aware what can happen if the fire >> brigade is called out under false pretences. The danger to others invol= ved >> in >> a real emergency and the financial drain that they impose on a service t= hat >> is >> there to save people's lives. " " >>=20 >>=20 >> UK emergency services use the location as one of the tests of how reliab= le is >> the report from a caller - if the "network provided" location (circuit >> switched wireline and GSM) differs appreciably from the incident locatio= n >> that >> a caller is reporting, then it influences the PSAP's response and >> questionning >> of the caller. >>=20 >> It is often children who make these hoax calls in the UK - it's difficul= t to >> understand why so I can't really answer Marc's question directly : we ne= ed a >> good psychiatrist/psychologist to answer that, but such calls are a very= real >> problem and having reliable location information is an important weapon = in >> tackling these as well as for speeding-up the handling of genuine calls. >>=20 >>=20 >> Regards >>=20 >> John >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >> Francois Menard >> Sent: 24 November 2009 19:25 >> To: Marc Linsner >> Cc: ecrit >> Subject: Re: [Ecrit] To trust or not to trust. Is that the question? >>=20 >> my point exactly! >>=20 >> f. >>=20 >> On 2009-11-24, at 14:19, Marc Linsner wrote: >>=20 >>> Why would a person requesting emergency assistance knowingly provide a >>> false location? >>>=20 >>> -Marc- >>>=20 >>> On 11/24/09 1:29 PM, "John Lange" wrote: >>>=20 >>>> Recently I've been following the debate on this list regarding >>>> veracity of location which loosely translates into a larger debate >>>> about security. >>>>=20 >>>> If I'm understanding all of this correctly, one position is that >>>> PSAPs will be resistant to solutions where the identity and location >>>> of the caller can't be assured and that this necessarily requires a >>>> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>>>=20 >>>> The other position is that the requirement for a trust relationship >>>> prevents nomadic VOIP users from accessing PSAPs when out of their >>>> home areas. Furthermore, these trusts can be circumvented so they >>>> provide only a false sense of security. >>>>=20 >>>> Is this a fair characterization of the two positions? >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Wed Nov 25 10:48:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7126B3A6AF2 for ; Wed, 25 Nov 2009 10:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRUs1x7YKu+Q for ; Wed, 25 Nov 2009 10:48:16 -0800 (PST) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by core3.amsl.com (Postfix) with ESMTP id 051E33A687D for ; Wed, 25 Nov 2009 10:48:15 -0800 (PST) Received: from BLU137-W36 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:48:11 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_61c54c50-6b72-49d5-b886-d3b15f26230d_" X-Originating-IP: [64.134.238.98] From: Bernard Aboba To: , , , Date: Wed, 25 Nov 2009 10:48:11 -0800 Importance: Normal In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F01D64767CF@SISPE7MB1.commscope.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 18:48:11.0435 (UTC) FILETIME=[D66287B0:01CA6DFF] Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:48:17 -0000 --_61c54c50-6b72-49d5-b886-d3b15f26230d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > - If trusted location is utopia=2C why are "Hoax calls are costing the UK= Fire > and Rescue Service a massive =A3230=2C000 a day - =A384 million a year" ?= ?? [BA] This demonstrates that "trusted location" by itself isn't enough. As = noted in the article=2C many false fire alarms are triggered by children who lack the sophisticatio= n to forge location. In those cases=2C the location and perhaps the identity= of the device are trustworthy -- but the assertion of a fire emergency in progress is fal= se.=20 The situation with "swatting" incidents appears to be somewhat different. = Here=2C the perpetrators are often technically sophisticated adults and the location=2C= the identity assertion and the emergency assertion all can be false.=20 > The IAP providing location is cost delta 2=2C > providing trusted location is 2 to the Nth power. If we accept the NENA i2.5 definition of "trusted location" I agree. NENA = i2.5 proposes a TLS-based certificate-based mutual authentication model for interfaces v2-v9=2C with the certificate hierarchy rooted in the VESA.=20 While securing elements internal to the emergency services network with a certificate hierarchy might be achievable=2C attempting to establish trust with every VSP and LIS on the planet through issuance of VESA-rooted certificates doesn't seem like a reasonable strategy to me. For one thing= =2C a VSP could conceivably need to communicate with emergency service=20 networks anywhere on the planet. Does this mean that they will need to acquire and manage certificates from all the potential emergency service networks they will need to deal with? > "Trusted" location vs location adds zero value to a normal/legitimate cal= ler > requesting emergency assistance. Hence trusted location is a tool to > mitigate attacks=2C but given the big picture cost delta between location= and > trusted location=2C is it worth the cost? It seems to me that the fundamental issue here is quite similar to the prob= lem we have had with SPAM. Today email is a commodity that is increasingly off= ered free or at very low prices. While the IETF has developed a certificate-bas= ed approach to the problem (e.g. DKIM)=2C so far I'm not aware that it has bee= n widely deployed. The bottom line is that most systems today are still usi= ng techniques based on various heuristics. As Mark Handley has noted=20 (see http://www.cs.ucl.ac.uk/staff/m.handley/papers/only-just-works.pdf)=2C= =20 these technologies "only just work"=2C but they remain very popular.=20 Given this experience=2C my question is what level of security will "only j= ust work" to address this problem. One approach would be to incorporate "911 fraud" = detection=20 capabilities into the SBCs deployed at the edges of the emergency services = network.=20 These SBCs could compare the location assertions in the PIDF-LO to the SIP = headers in an effort to ferret out fraudulent location assertions. =20 If that is the way things ultimately end up going=2C then the most importan= t question to ask is whether we're providing the fraud detection systems with enough i= nput data to do their job. =20 = --_61c54c50-6b72-49d5-b886-d3b15f26230d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B - If trusted location is utopia=2C why are "Hoax calls are costing t= he UK Fire
>=3B and Rescue Service a massive =A3230=2C000 a day - =A38= 4 million a year" ???

[BA] This demonstrates that "trusted location"= by itself isn't enough. =3B As noted in the article=2C
many false f= ire alarms are triggered by children who lack the sophistication
to forg= e location. =3B In those cases=2C the location and perhaps the identity= of the device
are trustworthy -- but the assertion of a fire emergency = in progress is false.

The situation with "swatting" incidents appea= rs to be somewhat different. =3B Here=2C the
perpetrators are often = technically sophisticated adults and the location=2C the identity
assert= ion and the emergency assertion all can be false.

>=3B The IAP pr= oviding location is cost delta 2=2C
>=3B providing trusted location is= 2 to the Nth power.

If we accept the NENA i2.5 definition of "trust= ed location" I agree. =3B NENA i2.5
proposes a TLS-based certificate= -based mutual authentication model for
interfaces v2-v9=2C with the cert= ificate hierarchy rooted in the VESA.

While securing elements inter= nal to the emergency services network with
a certificate hierarchy might= be achievable=2C attempting to establish
trust with every VSP and LIS o= n the planet through issuance of VESA-rooted
certificates doesn't seem l= ike a reasonable strategy to me. =3B =3B For one thing=2C
a VSP = could conceivably need to communicate with emergency service
networks a= nywhere on the planet. =3B Does this mean that they will need to
acq= uire and manage certificates from all the potential emergency service
ne= tworks they will need to deal with?

>=3B "Trusted" location vs loc= ation adds zero value to a normal/legitimate caller
>=3B requesting em= ergency assistance. Hence trusted location is a tool to
>=3B mitigate= attacks=2C but given the big picture cost delta between location and
&g= t=3B trusted location=2C is it worth the cost?

It seems to me that t= he fundamental issue here is quite similar to the problem
we have had wi= th SPAM. =3B Today email is a commodity that is increasingly offeredfree or at very low prices. =3B While the IETF has developed a certifi= cate-based
approach to the problem (e.g. DKIM)=2C so far I'm not aware t= hat it has been
widely deployed. =3B =3B The bottom line is that= most systems today are still using
techniques based on various heuristi= cs. =3B As Mark Handley has noted
(see http://www.cs.ucl.ac.uk/staf= f/m.handley/papers/only-just-works.pdf)=2C
these technologies "only jus= t work"=2C but they remain very popular.

Given this experience=2C m= y question is what level of security will "only just work"
to address th= is problem. =3B One approach would be to incorporate "911 fraud" detect= ion
capabilities into the SBCs deployed at the edges of the emergency s= ervices network.
These SBCs could compare the location assertions in th= e PIDF-LO to the SIP headers
in an effort to ferret out fraudulent locat= ion assertions. =3B

If that is the way things ultimately end up= going=2C then the most important question
to ask is whether we're provi= ding the fraud detection systems with enough input data
to do their job.=  =3B
= --_61c54c50-6b72-49d5-b886-d3b15f26230d_-- From mlinsner@cisco.com Wed Nov 25 11:45:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312E73A6B44 for ; Wed, 25 Nov 2009 11:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.034 X-Spam-Level: X-Spam-Status: No, score=-9.034 tagged_above=-999 required=5 tests=[AWL=1.565, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NznNQyjMzblD for ; Wed, 25 Nov 2009 11:45:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BF1463A6B43 for ; Wed, 25 Nov 2009 11:45:16 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAEYYDUuQ/uCWe2dsb2JhbACQIYt4AQELCyQGoVWXa4IuBoF+BI1J X-IronPort-AV: E=Sophos;i="4.47,288,1257120000"; d="scan'208";a="55214254" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2009 19:45:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAPJjAco016798; Wed, 25 Nov 2009 19:45:10 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 20:45:10 +0100 Received: from [10.116.195.114] ([10.116.195.114]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 20:45:09 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 25 Nov 2009 14:45:06 -0500 From: Marc Linsner To: Bernard Aboba Message-ID: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcpuB8mfhWx7ymmyuUqZ+POQOENsnQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Nov 2009 19:45:10.0251 (UTC) FILETIME=[CC2873B0:01CA6E07] Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:45:18 -0000 Bernard, I obviously agree, hence my assertion that 'trusted' location: 1) As proposed, is very expensive. 2) Gets trumped by the 'human' location, so the attack proceeds. 3) Since non-trusted location will still be accepted, too much emphasis on 'trusted' location could lead to a disastrous result in failing to respond to a legitimate emergency. 4) Exposes the attack vector to the community that builds attacks. As you state, the best place to defend against attacks is at the border of the ES network. As the cited experiences dictate, the best methodology is to control how you respond to packets received, not in trying to control th= e packets someone sends towards you, even a Government can't pull that one off. -Marc- On 11/25/09 1:48 PM, "Bernard Aboba" wrote: >> - If trusted location is utopia, why are "Hoax calls are costing the UK = Fire >> and Rescue Service a massive =A3230,000 a day - =A384 million a year" ??? >=20 > [BA] This demonstrates that "trusted location" by itself isn't enough. A= s > noted in the article, > many false fire alarms are triggered by children who lack the sophisticat= ion > to forge location. In those cases, the location and perhaps the identity= of > the device > are trustworthy -- but the assertion of a fire emergency in progress is f= alse. >=20 > The situation with "swatting" incidents appears to be somewhat different. > Here, the > perpetrators are often technically sophisticated adults and the location,= the > identity > assertion and the emergency assertion all can be false. >=20 >> The IAP providing location is cost delta 2, >> providing trusted location is 2 to the Nth power. >=20 > If we accept the NENA i2.5 definition of "trusted location" I agree. NEN= A > i2.5 > proposes a TLS-based certificate-based mutual authentication model for > interfaces v2-v9, with the certificate hierarchy rooted in the VESA. >=20 > While securing elements internal to the emergency services network with > a certificate hierarchy might be achievable, attempting to establish > trust with every VSP and LIS on the planet through issuance of VESA-roote= d > certificates doesn't seem like a reasonable strategy to me. For one thi= ng, > a VSP could conceivably need to communicate with emergency service > networks anywhere on the planet. Does this mean that they will need to > acquire and manage certificates from all the potential emergency service > networks they will need to deal with? >=20 >> "Trusted" location vs location adds zero value to a normal/legitimate ca= ller >> requesting emergency assistance. Hence trusted location is a tool to >> mitigate attacks, but given the big picture cost delta between location = and >> trusted location, is it worth the cost? >=20 > It seems to me that the fundamental issue here is quite similar to the pr= oblem > we have had with SPAM. Today email is a commodity that is increasingly > offered > free or at very low prices. While the IETF has developed a certificate-b= ased > approach to the problem (e.g. DKIM), so far I'm not aware that it has bee= n > widely deployed. The bottom line is that most systems today are still u= sing > techniques based on various heuristics. As Mark Handley has noted > (see http://www.cs.ucl.ac.uk/staff/m.handley/papers/only-just-works.pdf), > these technologies "only just work", but they remain very popular. >=20 > Given this experience, my question is what level of security will "only j= ust > work" > to address this problem. One approach would be to incorporate "911 fraud= " > detection=20 > capabilities into the SBCs deployed at the edges of the emergency service= s > network.=20 > These SBCs could compare the location assertions in the PIDF-LO to the SI= P > headers > in an effort to ferret out fraudulent location assertions. >=20 > If that is the way things ultimately end up going, then the most importan= t > question > to ask is whether we're providing the fraud detection systems with enough > input data > to do their job.=20 > =20 From Martin.Dawson@andrew.com Wed Nov 25 14:23:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927583A6852 for ; Wed, 25 Nov 2009 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHOS8nNJ+gzN for ; Wed, 25 Nov 2009 14:23:10 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E3A453A67E7 for ; Wed, 25 Nov 2009 14:23:09 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:8336 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S52579AbZKYWXA convert rfc822-to-8bit (ORCPT ); Wed, 25 Nov 2009 16:23:00 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 16:22:59 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 26 Nov 2009 06:22:57 +0800 From: "Dawson, Martin" To: Marc Linsner , "john.medland@bt.com" , "fmenard@xittelecom.com" Date: Thu, 26 Nov 2009 06:22:56 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16gACaI0qMAAcuIaQAEu8h9AAqxOuQ= Message-ID: <8B0A9FCBB9832F43971E38010638454F01D64767D3@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F01D64767CF@SISPE7MB1.commscope.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:23:11 -0000 > ________________________________________ > From: Marc Linsner [mlinsner@cisco.com] > Sent: Thursday, 26 November 2009 3:59 AM > To: Dawson, Martin; john.medland@bt.com; fmenard@xittelecom.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? > > Martin, > > You conveniently ignored a couple more points I made. > > - If trusted location is utopia, why are "Hoax calls are costing the UK Fire > and Rescue Service a massive £230,000 a day - £84 million a year" ??? That's a non-point. It's also somewhat perverse to take the evidence that this can be an issue and argue from that point that it's therefore worth doing even less. Where did anyone say utopia? This is more evidence that you aren't capable of seeing things as a matter of degree; you will forever make perfect the enemy of good. > > - The promotion of trusted location *could* include some marketing. Don't understand that. > > To answer your questions. > > Trusted Location attack vector. Even after excluding all the use cases, you > forgot the replay attack. How does the replay work given that a location URI is dynamically generated and transient? So you acknowledge the only actual use cases are ones that involve the attacker having some sort of real physical presence either directly or via remote controlled device in the network? > > Network determined location. Example: Would an emergency responder in > Chicago be able to provide a quicker response with location: > > 1) from the network - 41 52.735N, 87 38.168W > or > 2) from the caller - NW corner of the 105th floor of the Willis Tower That would be up to the call taker and PSAP policy to determine would it not? Not either of us. However, perhaps you've missed the point that this is about establishing policy on how calls are answered. Once the caller is actually talking to someone then the important PSAP resources are already being consumed. This is about establishing policy around how calls are managed on arrival to the emergency network - and particularly in congestion situations. > > Oh, another point you missed. I do/did admit that trusted location has > value, but it must be put into the context of *ALL* attacks on a PSAP and > it's value determined in accordance with it's cost. That cost includes the > business case of the Internet access provider (IAP). Forcing the IAP to > implement mechanisms/devices that don't add value to their business model > does not bode well for a future where accessing the Internet is suppose to > get easier, not harder. The IAP providing location is cost delta 2, > providing trusted location is 2 to the Nth power. Nice to see you can be concerned about the need for access providers to actually have a viable business; your point is somewhat counter to your position in the location hiding discussion and your recent ad hominem post. Where does this pseudo-math you cite above originate? Have you got a reference to this cost modelling? It looks wrong to me. > > "Trusted" location vs location adds zero value to a normal/legitimate caller > requesting emergency assistance. Hence trusted location is a tool to > mitigate attacks, but given the big picture cost delta between location and > trusted location, is it worth the cost? IMO - absolutely and we actually have a responsibility to ensure the mechanism is defined and available for those jurisdictions that want to take advantage of it. > > -Marc- On 11/25/09 10:08 AM, "Dawson, Martin" wrote: > Marc, > > You make two points: > > 1. There is the possibility of "spoofing" the mechanisms associated with > trusted location. > 2. "Network determined" location isn't necessarily the best. > > With respect to the first, I would genuinely appreciate your elaboration of > what this "attack vector" actually looks like. I'm not talking about the > alleged bot net out there generating emergency service calls. That's a horse > of a completely different color. Please don't invoke any scenarios that > involve a "remotely controlled" point of access within the PSAP jurisdiction. > That's possible today on the PSTN; it's not something a casual, foreign, > caller can do. I'm talking about a user connected to the Internet in a > completely different state/country/jurisdiction initiating an emergency call > that manages to be routed to the local PSAP with a location reported as being > local. If the mechanism used to validate location is dereference to a local > Internet provider LIS, how does the attacker actually achieve this? > > With respect to the claim that network determined location isn't necessarily > the best, I disagree. Location is determined by virtue of taking measurements. > Measurements can be made by the device and/or by the network. A purely > device-based approach to determining location is not able to take advantage of > whatever additional measurements the network takes (e.g. uplink timing). All > decent network based location service architectures include the ability for > measurements taken by the device to be provided to the server as well - > including any actual location determination that the device might make. That > is, the network can have access to everything the device has plus the > measurements only it can make. In principle, then, a network determined > location can always be at least as good as what the device can do on its own. > This is why SUPL has ULP pos protocols, it is why GSM has RRLP, it is why UMTS > has RRC, it is why LPP is being defined for LTE and it's why our own IP > location service protocols need the capabilities in the measurements draft. > > By the same token, and tying the two points together, it's the public network > operator that offers the best assurance for the emergency network operator > that the information presented by the device really is valid, sane, and > representative of the real location from which the call is originating. I'd > challenge you to come up with a better or more recognisable third party to > provide that assurance to the recipient of location information. > > Your, by now chronic, counsel that nothing can be perfect therefore nothing > should be done makes no more sense now than it did four years ago. No, it > won't be perfect; there can't be guarantees - any more than you can guarantee > that somebody isn't monitoring your cell phone call despite it having state of > the art encryption, or any more than you can guarantee that the bank account > site your logging onto isn't actually a spoofed site. However, I believe we > can raise the level of assurance for location information to be as good as it > is for these services. And that's a significant level of assurance compared to > your advice of "don't bother". > > Regards, > Martin > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Marc > Linsner [mlinsner@cisco.com] > Sent: Thursday, 26 November 2009 12:52 AM > To: john.medland@bt.com; fmenard@xittelecom.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? > > John, > > This begs the question, "Is *trusted*, *reliable* location the right tool to > thwart hoax emergency calls?" It seems that *trusted* location doesn't work > in what is described below. > > When emergency calling moves to the Internet, *trusted* location can/will be > spoofed. > > I'm trying to get everyone to understand that putting too much emphasis on > trusted location will get you in trouble. Sure, it's a tool, it has some > value, but it also opens up more attack vectors. > > I also have a problem with the notion that network derived location is the > most accurate. This is not always the case. > > Also, the point below is made that responders are dispatched to where the > caller states the emergency is located, not where the *trusted* location > dictates. So, the human already overrides the *trusted* location. > > Is the value derived from *trusted* worth the cost? As Francios has > reported, the cost is exponentially more that the cost of the actual VoIP > service. Is this due to it's perceived (marketed) value? > > -Marc- > > > On 11/24/09 2:53 PM, "john.medland@bt.com" wrote: > >> Marc, Francois, >> >> Without getting involved in the technical debate, I thought you may be >> interested to see some figures about what we in UK term hoax calls, ie people >> who report a non-existent incident. The information in " " below is 3.5 >> years >> old but still illustrates the problem. >> >> " Hoax calls are costing the UK Fire and Rescue Service a massive £230,000 a >> day - £84 million a year - and the problem is potentially putting lives in >> danger. >> >> Approximately 50,000 hoax fire calls are responded to every year, 135 per >> day, by the Fire and Rescue Service in England and Wales, whose role includes >> providing emergency response to fires, road traffic incidents and terrorism. >> The Economic Cost of Fire report estimates that each hoax call costs £1,700. >> This equates to a disturbing £84 million per year. A significant cost for the >> Fire and Rescue Service to absorb. >> >> London Fire Brigade has the highest hoax call rate in the UK, attending >> nearly >> twice as many call outs (9,686) as the second worse affected brigade, Greater >> Manchester (5,268) and the West Midlands (4,074). >> >> Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, said: >> "Young people in particular need to be aware what can happen if the fire >> brigade is called out under false pretences. The danger to others involved >> in >> a real emergency and the financial drain that they impose on a service that >> is >> there to save people's lives. " " >> >> >> UK emergency services use the location as one of the tests of how reliable is >> the report from a caller - if the "network provided" location (circuit >> switched wireline and GSM) differs appreciably from the incident location >> that >> a caller is reporting, then it influences the PSAP's response and >> questionning >> of the caller. >> >> It is often children who make these hoax calls in the UK - it's difficult to >> understand why so I can't really answer Marc's question directly : we need a >> good psychiatrist/psychologist to answer that, but such calls are a very real >> problem and having reliable location information is an important weapon in >> tackling these as well as for speeding-up the handling of genuine calls. >> >> >> Regards >> >> John >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Francois Menard >> Sent: 24 November 2009 19:25 >> To: Marc Linsner >> Cc: ecrit >> Subject: Re: [Ecrit] To trust or not to trust. Is that the question? >> >> my point exactly! >> >> f. >> >> On 2009-11-24, at 14:19, Marc Linsner wrote: >> >>> Why would a person requesting emergency assistance knowingly provide a >>> false location? >>> >>> -Marc- >>> >>> On 11/24/09 1:29 PM, "John Lange" wrote: >>> >>>> Recently I've been following the debate on this list regarding >>>> veracity of location which loosely translates into a larger debate >>>> about security. >>>> >>>> If I'm understanding all of this correctly, one position is that >>>> PSAPs will be resistant to solutions where the identity and location >>>> of the caller can't be assured and that this necessarily requires a >>>> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>>> >>>> The other position is that the requirement for a trust relationship >>>> prevents nomadic VOIP users from accessing PSAPs when out of their >>>> home areas. Furthermore, these trusts can be circumvented so they >>>> provide only a false sense of security. >>>> >>>> Is this a fair characterization of the two positions? >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From john.medland@bt.com Wed Nov 25 14:26:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD8C3A6950 for ; Wed, 25 Nov 2009 14:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIOBFt8Kgi7v for ; Wed, 25 Nov 2009 14:26:15 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C6A3B3A6852 for ; Wed, 25 Nov 2009 14:26:14 -0800 (PST) Received: from E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 22:26:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6E1E.406A9DBC" Date: Wed, 25 Nov 2009 22:25:35 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcptO9nkxN7Mwtm+QhGLT+WxPFIMbgAAI16gACaI0qMAB1QcIA== From: To: , X-OriginalArrivalTime: 25 Nov 2009 22:26:09.0142 (UTC) FILETIME=[494E4160:01CA6E1E] Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:26:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6E1E.406A9DBC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marc, I've inserted a few comments below that may help clarify the limits to = which we can use the figures I provided on hoax calls in the UK. =20 My main point was that hoax calls do occur (original question being why = would a person provide a false location) and cost a lot to manage, so = well worth considering all possible ways to minimise their impact. Regards John _____________________________________________=20 From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: 25 November 2009 13:53 To: Medland,JD,John,MLC12 R; fmenard@xittelecom.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? John, This begs the question, "Is *trusted*, *reliable* location the right = tool to thwart hoax emergency calls?" It seems that *trusted* location = doesn't work in what is described below. [John Medland] No, we can't draw that conclusion from what is said = below as we just don't have the information to judge and I should have = made that clear when I posted the comment on the list - my apologies. = For various reasons not all Fire Services in the UK yet use the = automatically provided location - even though the benefits are clear = from extensive use by Police, Ambulance, Coastguard and those Fire = Services that do use it.......... At the time these numbers were = gathered only a third of Fire Services were using the automated location = facility (more are now doing so, driven partly by the desire to tackle = hoax calls). The figures below simply show that there are many people (often children = in the UK) who do make hoax calls and that these are expensive to = manage, and therefore it is well worth considering all possible ways to = help minimise their impact.=20 Increasing use of automatically provided location is helping to drive = these figures down - it allows the PSAP call-takers to challenge = suspected hoax callers about location information they are providing = verbally, and change their questionning and response accordingly, for = example they may only send one vehicle or a different type of vehicle if = some doubt remains. =20 When emergency calling moves to the Internet, *trusted* location = can/will be spoofed. I'm trying to get everyone to understand that putting too much emphasis = on trusted location will get you in trouble. Sure, it's a tool, it has = some value, but it also opens up more attack vectors. [John Medland] I'd agree that automatically provided, trusted location = is only one of a set of tools needed to tackle hoax calls, but it is a = useful one, and if we can continue to try to find ways to provide it at = a reasonable cost that would be welcomed by PSAPs. =20 I also have a problem with the notion that network derived location is = the most accurate. This is not always the case. [John Medland] In the UK at present we only have automatically provided = locations from the networks - cell coverage for GSM and installation = address for fixed/wireline. Also, the point below is made that responders are dispatched to where = the caller states the emergency is located, not where the *trusted* = location dictates. So, the human already overrides the *trusted* = location. [John Medland] As mentioned above most Fire Services in the UK did not = have the automated location facility at the time these figures were = provided. So, in most of these cases all they would have would be a = verbally provided location. If a call-taker has both a verbal and an = automatically provided location and the two locations do not align, it = changes the questionning and nature of response. My understanding is = that if there was doubt, the PSAP may still send a response to the = verbally reported location but would degrade the response as mentioned = above. In some cases - verbal location remote from trusted automatic = location - they would not send a response at all. Although the thread is mainly about hoax calls, worth mentioning that = the Police send many responses to calls where caller has not been able = to provide a clear location entirely on the basis of a trusted, = automatically provided location.=20 =20 Is the value derived from *trusted* worth the cost? As Francios has = reported, the cost is exponentially more that the cost of the actual = VoIP service. Is this due to it's perceived (marketed) value? [John Medland] PSAPs do find it helpful to be able to trust location = for both genuine calls and the reduction of the impact of hoax calls - = cost has to be reasonable and proportionate though as it is at present. = I need to go and look at why the cost is so much in Canadian model. =20 -Marc- On 11/24/09 2:53 PM, "john.medland@bt.com" wrote: > Marc, Francois, >=20 > Without getting involved in the technical debate, I thought you may be = > interested to see some figures about what we in UK term hoax calls, ie = > people who report a non-existent incident. The information in " "=20 > below is 3.5 years old but still illustrates the problem. > =20 > " Hoax calls are costing the UK Fire and Rescue Service a massive=20 > =A3230,000 a day - =A384 million a year - and the problem is = potentially=20 > putting lives in danger. >=20 > Approximately 50,000 hoax fire calls are responded to every year, 135 = > per day, by the Fire and Rescue Service in England and Wales, whose=20 > role includes providing emergency response to fires, road traffic = incidents and terrorism. > The Economic Cost of Fire report estimates that each hoax call costs = =A31,700. > This equates to a disturbing =A384 million per year. A significant = cost=20 > for the Fire and Rescue Service to absorb. >=20 > London Fire Brigade has the highest hoax call rate in the UK,=20 > attending nearly twice as many call outs (9,686) as the second worse=20 > affected brigade, Greater Manchester (5,268) and the West Midlands = (4,074). >=20 > Sir Graham Meldrum, head of Her Majesty's Fire Service Inspectorate, = said: > "Young people in particular need to be aware what can happen if the=20 > fire brigade is called out under false pretences. The danger to=20 > others involved in a real emergency and the financial drain that they=20 > impose on a service that is there to save people's lives. " " >=20 >=20 > UK emergency services use the location as one of the tests of how=20 > reliable is the report from a caller - if the "network provided"=20 > location (circuit switched wireline and GSM) differs appreciably from=20 > the incident location that a caller is reporting, then it influences=20 > the PSAP's response and questionning of the caller. >=20 > It is often children who make these hoax calls in the UK - it's=20 > difficult to understand why so I can't really answer Marc's question=20 > directly : we need a good psychiatrist/psychologist to answer that,=20 > but such calls are a very real problem and having reliable location=20 > information is an important weapon in tackling these as well as for = speeding-up the handling of genuine calls. >=20 >=20 > Regards >=20 > John >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = > Of Francois Menard > Sent: 24 November 2009 19:25 > To: Marc Linsner > Cc: ecrit > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? >=20 > my point exactly! >=20 > f. >=20 > On 2009-11-24, at 14:19, Marc Linsner wrote: >=20 >> Why would a person requesting emergency assistance knowingly provide=20 >> a false location? >>=20 >> -Marc- >>=20 >> On 11/24/09 1:29 PM, "John Lange" wrote: >>=20 >>> Recently I've been following the debate on this list regarding=20 >>> veracity of location which loosely translates into a larger debate=20 >>> about security. >>>=20 >>> If I'm understanding all of this correctly, one position is that=20 >>> PSAPs will be resistant to solutions where the identity and location = >>> of the caller can't be assured and that this necessarily requires a=20 >>> trust relationship between VSPs and PSAPs and/or ISPs and PSAPs. >>>=20 >>> The other position is that the requirement for a trust relationship=20 >>> prevents nomadic VOIP users from accessing PSAPs when out of their=20 >>> home areas. Furthermore, these trusts can be circumvented so they=20 >>> provide only a false sense of security. >>>=20 >>> Is this a fair characterization of the two positions? >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01CA6E1E.406A9DBC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] To trust or not to trust. Is that the = question?

Marc,

I've inserted a = few comments below that may help clarify the limits to which we can use = the figures I provided on hoax calls in the UK. 

My main point was = that hoax calls do occur (original question being why would a person = provide a false location) and cost a lot to manage, so well worth = considering all possible ways to minimise their = impact.

Regards

John

_____________________________________________ =
From:   Marc = Linsner [mailto:mlinsner@cisco.com]
Sent:   = 25 November 2009 13:53
To:     Medland,JD,John,MLC12 R; = fmenard@xittelecom.com
Cc:     ecrit@ietf.org
Subject:        Re: = [Ecrit] To trust or not to trust. Is that the question?

John,

This begs the = question, "Is *trusted*, *reliable* location the right tool to = thwart hoax emergency calls?"  It seems that *trusted* = location doesn't work in what is described below.

[John Medland]  No, we can't draw that conclusion = from what is said below as we just don't have the information to judge = and I should have made that clear when I posted the comment on the list = - my apologies.   For various reasons not all Fire Services in = the UK yet use the automatically provided location - even though the = benefits are clear from extensive use by Police, Ambulance, Coastguard = and those Fire Services that do use it……….  At = the time these numbers were gathered only a third of Fire Services were = using the automated location facility (more are now doing so, driven = partly by the desire to tackle hoax calls).

The figures below simply show that there are many people = (often children in the UK)  who do make hoax calls and that these = are expensive to manage, and therefore it is well worth considering all = possible ways to help minimise their impact.

Increasing use of automatically provided location is = helping to drive these figures down - it allows the PSAP call-takers to = challenge suspected hoax callers about location information they are = providing verbally, and change their questionning and response = accordingly, for example they may only send one vehicle or a different = type of vehicle if some doubt remains. 

When emergency = calling moves to the Internet, *trusted* location can/will be = spoofed.

I'm trying to get = everyone to understand that putting too much emphasis on trusted = location will get you in trouble.  Sure, it's a tool, it has some = value, but it also opens up more attack vectors.

[John Medland]  I'd agree that automatically = provided, trusted location is only one of a set of tools needed to = tackle hoax calls, but it is a useful one, and if we can continue to try = to find ways to provide it at a reasonable cost that would be welcomed = by PSAPs.   

I also have a = problem with the notion that network derived location is the most = accurate.  This is not always the case.
[John Medland]  In the UK at present we only have = automatically provided locations from the networks - cell coverage for = GSM and installation address for fixed/wireline.

Also, the point = below is made that responders are dispatched to where the caller states = the emergency is located, not where the *trusted* location = dictates.  So, the human already overrides the *trusted* = location.

[John Medland]  As mentioned above most Fire = Services in the UK did not have the automated location facility at the = time these figures were provided. So, in most of these cases all they = would have would be a verbally provided location.  If a call-taker = has both a verbal and an automatically provided location and the two = locations do not align, it changes the questionning and nature of = response.   My understanding is that if there was doubt, the = PSAP may still send a response to the verbally reported location but = would degrade the response as mentioned above.  In some cases - = verbal location remote from trusted automatic location - they would not = send a response at all.

Although the = thread is mainly about hoax calls, worth mentioning that the Police send = many responses to calls where caller has not been able to provide a = clear location entirely on the basis of a trusted, automatically = provided location.

 
Is the value = derived from *trusted* worth the cost?  As Francios has reported, = the cost is exponentially more that the cost of the actual VoIP = service.  Is this due to it's perceived (marketed) = value?

[John Medland]  PSAPs do find it helpful to be able = to trust location for both genuine calls and the reduction of the impact = of hoax calls - cost has to be reasonable and proportionate though as it = is at present.  I need to go and look at why the cost is so much in = Canadian model. 

-Marc-


On 11/24/09 2:53 = PM, "john.medland@bt.com" <john.medland@bt.com> = wrote:

> Marc, = Francois,
> =
> Without = getting involved in the technical debate, I thought you may be =
> interested = to see some figures about what we in UK term hoax calls, ie =
> people who = report a non-existent incident.  The information in " " =
> below is 3.5 = years old but still illustrates the problem.
>  =
> " Hoax = calls are costing the UK Fire and Rescue Service a massive =
> =A3230,000 a = day - =A384 million a year - and the problem is potentially =
> putting = lives in danger.
> =
> = Approximately 50,000  hoax fire calls are responded to every year, = 135
> per day, by = the Fire and Rescue Service in England and Wales, whose
> role = includes providing emergency response to fires, road traffic incidents = and terrorism.
> The Economic = Cost of Fire report estimates that each hoax call costs = =A31,700.
> This equates = to a disturbing =A384 million per year. A significant cost =
> for the Fire = and Rescue Service to absorb.
> =
> London Fire = Brigade has the highest hoax call rate in the UK,
> attending = nearly twice as many call outs (9,686) as the second worse =
> affected = brigade, Greater Manchester (5,268) and the West Midlands = (4,074).
> =
> Sir Graham = Meldrum, head of Her Majesty's Fire Service Inspectorate, = said:
> "Young = people in particular need to be aware what can happen if the =
> fire brigade = is called out under false pretences.  The danger to
> others = involved in a real emergency and the financial drain that they =
> impose on a = service that is there to save people's lives. " = "
> =
> =
> UK emergency = services use the location as one of the tests of how
> reliable is = the report from a caller - if the "network provided" =
> location = (circuit switched wireline and GSM) differs appreciably from =
> the incident = location that a caller is reporting, then it influences
> the PSAP's = response and questionning of the caller.
> =
> It is often = children who make these hoax calls in the UK - it's
> difficult to = understand why so I can't really answer Marc's question
> directly : = we need a good psychiatrist/psychologist to answer that,
> but such = calls are a very real problem and having reliable location =
> information = is an important weapon in tackling these as well as for speeding-up the = handling of genuine calls.
> =
> =
> = Regards
> =
> = John
> =
> = -----Original Message-----
> From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
> Of Francois = Menard
> Sent: 24 = November 2009 19:25
> To: Marc = Linsner
> Cc: = ecrit
> Subject: Re: = [Ecrit] To trust or not to trust. Is that the question?
> =
> my point = exactly!
> =
> = f.
> =
> On = 2009-11-24, at 14:19, Marc Linsner wrote:
> =
>> Why = would a person requesting emergency assistance knowingly provide =
>> a false = location?
>> =
>> = -Marc-
>> =
>> On = 11/24/09 1:29 PM, "John Lange" <john@johnlange.ca> = wrote:
>> =
>>> = Recently I've been following the debate on this list regarding =
>>> = veracity of location which loosely translates into a larger debate =
>>> = about security.
>>> =
>>> If = I'm understanding all of this correctly, one position is that =
>>> = PSAPs will be resistant to solutions where the identity and location =
>>> of = the caller can't be assured and that this necessarily requires a =
>>> = trust relationship between VSPs and PSAPs and/or ISPs and = PSAPs.
>>> =
>>> The = other position is that the requirement for a trust relationship =
>>> = prevents nomadic VOIP users from accessing PSAPs when out of their =
>>> home = areas. Furthermore, these trusts can be circumvented so they =
>>> = provide only a false sense of security.
>>> =
>>> Is = this a fair characterization of the two positions?
>> =
>> =
>> = _______________________________________________
>> Ecrit = mailing list
>> = Ecrit@ietf.org
>> = https://www.ietf.org/mailman/listinfo/ecrit
> =
> = _______________________________________________
> Ecrit = mailing list
> = Ecrit@ietf.org
> = https://www.ietf.org/mailman/listinfo/ecrit


------_=_NextPart_001_01CA6E1E.406A9DBC-- From john@johnlange.ca Wed Nov 25 15:02:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED263A68F5 for ; Wed, 25 Nov 2009 15:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Pyvd2JQnOc for ; Wed, 25 Nov 2009 15:02:43 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 38BEC3A6813 for ; Wed, 25 Nov 2009 15:02:43 -0800 (PST) Received: by ywh15 with SMTP id 15so196594ywh.5 for ; Wed, 25 Nov 2009 15:02:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.174.40 with SMTP id w40mr14643031ybe.123.1259190155618; Wed, 25 Nov 2009 15:02:35 -0800 (PST) X-Originating-IP: [205.200.120.72] In-Reply-To: References: Date: Wed, 25 Nov 2009 17:02:35 -0600 Message-ID: From: John Lange To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:02:44 -0000 With regard to casual hoax calls or calls where the person can not speak (or doesn't know their location), it would seem unquestionable that device determined location is a valuable tool. The only question would be cost effectiveness, an issue that remains unresolved largely because at this time the number of users that would benefit is a small percentage. This may change in the future. That being said, I started this thread asking about a specific scenario which was a DDOS attach on PSAPs using remotely controlled devices. These calls will come from devices that are both location and user "trusted" (to the standard I've seen mentioned in this thread). Does anyone have any theories on how this scenario can be mitigated? Perhaps it would be important to mandate that user-agent information be passed from end-to-end? At least then you could filter a given type of attacker. -- John Lange www.johnlange.ca From James.Winterbottom@andrew.com Wed Nov 25 15:08:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED34A3A6B78 for ; Wed, 25 Nov 2009 15:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+h-GbzauUgi for ; Wed, 25 Nov 2009 15:08:37 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 03C343A68E3 for ; Wed, 25 Nov 2009 15:08:37 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:56416 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5418896AbZKYXIc convert rfc822-to-8bit (ORCPT ); Wed, 25 Nov 2009 17:08:32 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 17:08:31 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 26 Nov 2009 07:08:27 +0800 From: "Winterbottom, James" To: John Lange , "ecrit@ietf.org" Date: Thu, 26 Nov 2009 07:08:26 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcpuI2WbwIQCPojlR1aIs4/81jX9gwAAFXog Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EBB88B24C@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:08:38 -0000 Hi John, I hoped you meant "automatic location" and not specifically device determined location. In many cases a network provided or determined location is better than a device determined one. That aside, in the scenario you describe below the attacker must have some form of presence in the network, albeit via a zombie in the case you describe. At a minimum having trusted location information means that you can locate the zombie PC, this is something that you can't do today. Cheers James James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com Mobile: +61-448-266004 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > John Lange > Sent: Thursday, 26 November 2009 10:03 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] To trust or not to trust. Is that the question? > > With regard to casual hoax calls or calls where the person can not > speak (or doesn't know their location), it would seem unquestionable > that device determined location is a valuable tool. The only question > would be cost effectiveness, an issue that remains unresolved largely > because at this time the number of users that would benefit is a small > percentage. This may change in the future. > > That being said, I started this thread asking about a specific > scenario which was a DDOS attach on PSAPs using remotely controlled > devices. These calls will come from devices that are both location and > user "trusted" (to the standard I've seen mentioned in this thread). > > Does anyone have any theories on how this scenario can be mitigated? > > Perhaps it would be important to mandate that user-agent information > be passed from end-to-end? At least then you could filter a given type > of attacker. > > -- > John Lange > www.johnlange.ca > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Wed Nov 25 15:27:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935683A68FA for ; Wed, 25 Nov 2009 15:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koZXzpz83PCi for ; Wed, 25 Nov 2009 15:27:05 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 802873A68F4 for ; Wed, 25 Nov 2009 15:27:05 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:23440 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5419145AbZKYX1A convert rfc822-to-8bit (ORCPT ); Wed, 25 Nov 2009 17:27:00 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 17:27:00 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 26 Nov 2009 07:26:56 +0800 From: "Dawson, Martin" To: John Lange , "ecrit@ietf.org" Date: Thu, 26 Nov 2009 07:26:55 +0800 Thread-Topic: [Ecrit] To trust or not to trust. Is that the question? Thread-Index: AcpuI2WbwIQCPojlR1aIs4/81jX9gwAAODdl Message-ID: <8B0A9FCBB9832F43971E38010638454F01D64767D6@SISPE7MB1.commscope.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:27:06 -0000 More information is better. Location is one parameter that can be used to as part of a traffic signature. Information provided by the UA, however, needs to have some basis for trustability if it's to be used as part of a signature analysis. I think a large number of calls coming from remotely controlled devices needs to be addressed in the same way that a DDOS attack is normally mitigated. From what I see, the capacity of the service under attack is typically impacted during the interval of a DDOS attack and I'd expect that the same would occur to the emergency service. It would diminish the ability of the PSAP to handle real calls. Fewer real calls could be serviced - and the real extent of the impact would depend on exactly what this auto-bot did once the call was answered. It should certainly be considered a serious crime to mount a DDOS on the emergency services. The operators of botnets see their "asset" of a network of compromised hosts as a genuine business. They sell this capacity to spammers, scammers, and hoaxers... typically. They would not want their "asset" compromised. Consider the course of events should the botnet be used to mount a DDOS on PSAPs while using genuine trusted location to bypass the congestion control mechanism. The calls would have to arrive with a real carrier provided location URI for the location dereference. There's no point in the calls sharing one or a subset of URIs because that creates a traffic signature that can be used for automatic policy. So - we have a bunch of calls arriving at PSAPs with genuine location URIs that reveal genuine locations of the source of the calls. This fact alone runs strongly counter to the business interests of the botnet owners. Bring it on; it would provide a boon in forensic detail. Indeed an appealing grey hat operation when there are established carrier LIS capabilities in the Internet access networks would be for the authorities to solicit a package from the botnet operator and plant a binary whose sole purpose is to obtain location from the carrier LIS and send it to the authorities. How could they be confident their drone wasn't compromised by the botnet operator? By using trusted location mechanisms to validate the location information returned. Cheers, Martin ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of John Lange [john@johnlange.ca] Sent: Thursday, 26 November 2009 10:02 AM To: ecrit@ietf.org Subject: Re: [Ecrit] To trust or not to trust. Is that the question? With regard to casual hoax calls or calls where the person can not speak (or doesn't know their location), it would seem unquestionable that device determined location is a valuable tool. The only question would be cost effectiveness, an issue that remains unresolved largely because at this time the number of users that would benefit is a small percentage. This may change in the future. That being said, I started this thread asking about a specific scenario which was a DDOS attach on PSAPs using remotely controlled devices. These calls will come from devices that are both location and user "trusted" (to the standard I've seen mentioned in this thread). Does anyone have any theories on how this scenario can be mitigated? Perhaps it would be important to mandate that user-agent information be passed from end-to-end? At least then you could filter a given type of attacker. -- John Lange www.johnlange.ca _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Wed Nov 25 15:37:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821AE3A6878 for ; Wed, 25 Nov 2009 15:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQROJNgYRHOo for ; Wed, 25 Nov 2009 15:37:19 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by core3.amsl.com (Postfix) with ESMTP id 94EE73A6405 for ; Wed, 25 Nov 2009 15:37:19 -0800 (PST) Received: from BLU137-W31 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:35:48 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e218316e-370e-48f9-b49d-f25bda9a3741_" X-Originating-IP: [64.134.238.98] From: Bernard Aboba To: , Date: Wed, 25 Nov 2009 15:35:48 -0800 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 23:35:48.0873 (UTC) FILETIME=[049E9790:01CA6E28] Subject: Re: [Ecrit] To trust or not to trust. Is that the question? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:37:20 -0000 --_e218316e-370e-48f9-b49d-f25bda9a3741_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > That being said=2C I started this thread asking about a specific > scenario which was a DDOS attach on PSAPs using remotely controlled > devices. These calls will come from devices that are both location and > user "trusted" (to the standard I've seen mentioned in this thread). >=20 > Does anyone have any theories on how this scenario can be mitigated? Assuming that the calls otherwise appear to be perfectly legitimate (e.g. S= IP=20 headers match the enclosed PIDF-LO & RFC 4474 signatures if present=2C etc.= ) one might need to look at the media. It would take a pretty cleaver bot to= =20 be able to deliver credible media to a PSAP dispatcher=2C so that character= istics of the media might be useful in differentiating bot-originated emergency ca= lls=20 from authentic calls.=20 Unfortunately=2C that kind of heuristic isn't helpful until *after* the cal= l has been answered. What you really need in that kind of situation is to be able to= =20 prioritize incoming calls so that the SBCs protecting the emergency service= s network don't have to burn cycles on signaling with bot-controlled UAs.=20 = --_e218316e-370e-48f9-b49d-f25bda9a3741_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B That being said=2C I started this thread asking about a specific
= >=3B scenario which was a DDOS attach on PSAPs using remotely controlled<= br>>=3B devices. These calls will come from devices that are both locatio= n and
>=3B user "trusted" (to the standard I've seen mentioned in this= thread).
>=3B
>=3B Does anyone have any theories on how this sc= enario can be mitigated?

Assuming that the calls otherwise appear to= be perfectly legitimate (e.g. SIP
headers match the enclosed PIDF-LO &= amp=3B RFC 4474 signatures if present=2C etc.)
one might need to look at= the media. =3B It would take a pretty cleaver bot to
be able to de= liver credible media to a PSAP dispatcher=2C so that characteristics
of = the media might be useful in differentiating bot-originated emergency calls=
from authentic calls.

Unfortunately=2C that kind of heuristic = isn't helpful until *after* the call has been
answered. =3B What you= really need in that kind of situation is to be able to
prioritize inco= ming calls so that the SBCs protecting the emergency services
network do= n't have to burn cycles on signaling with bot-controlled UAs.
= = --_e218316e-370e-48f9-b49d-f25bda9a3741_--