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
I have no problem with indications that advise the PSAP call-taker:
- “This caller is using a SP we don’=
t know, please query the caller as to their identity and location.”
- “There is no validation that the IP address of thi=
s caller exists at the reported location, please query further about locatio=
n.”
I have a problem with:
- 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.
I have no problem with:
- Requiring that calls to the ESInet meet a set of ope=
n 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 cann=
ot happen based on the SP utilized, the failure scenario of the algorithm is=
disastrous.
-Marc-
On 10/31/09 8:43 AM, "Brian Rosen" <br@brianrosen.net> wrote:
<=
SPAN STYLE=3D'font-size:11pt'>You are looking for trouble when there isn't any=
.
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.
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
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.
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 the<=
BR>
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.
Brian
On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>
>
>
> 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 =
thousands of
>> such successful service providers. It usually quickly settle=
s Darwinian
>> style to one or two. When the PSAPs see a bunch of calls fro=
m some new
>> source, they will call them up, and get them on the "we know =
you" list. No
>> big deal.
>>
>> You are still speculating about something that hasn't happened, an=
d 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 m=
atter.
>
> Exactly my point. In the scenario you've painted, the PSAP is go=
ing to
> evaluate the validity/urgency of the request for emergency assistance<=
BR>
> 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 emerge=
ncy is
> 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 pur=
pose.
> Simply stating these are the only tools available is not good enough.<=
BR>
>
> -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 SP=
s. I believe
>>> the mix of SPs and the products they offer will change dramati=
cally at a
>>> pace that PSAPs won't be able to keep up. This week Goog=
le, next week
>>> Noggle, the next week Boogle, etc. If in fact the PSAP r=
equires
>>> relationships with every SP that may send an emergency call th=
eir 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 service=
s without service
>>>> providers that have two way interactive media, where the i=
dentity of the
>>>> callers is a simple domain name, emergency calls from thos=
e devices is
>>>> interesting, they can't provide a suitable callback withou=
t 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, w=
e'll solve it.
>>>>
>>>> Right now, the simpler case of a direct call from an unkno=
wn source 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 p=
ath is being used 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 do=
n't have to drop calls
>>>> when we're attacked. OTOH, I don't want to promote t=
he proxy server 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 ar=
en'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&q=
uot; means SP path in 99.999% of cases
>>>>>> gets the PSAPs what they want. They don't ca=
re 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 calls, and
>>>>>> even
>>>>>> if they were in "From", they won't be th=
e domain in P-Asserted-Identity,
>>>>>> or
>>>>>> the SubjectAltName of the Identity signature. &nbs=
p;If some service that used
>>>>>> email addresses as identities sent us calls, the e=
mail address (with its
>>>>>> domain) is the "userpart" of the identit=
y, not the whole thing. There
>>>>>> are
>>>>>> some interesting problems when you have URI to som=
ething like 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. Certific=
ates for vanity domains
>>>>> are
>>>>> certainly doable. Besides P-Asserted-Identity is=
not a MUST in phonebcp.
>>>>> :^)
>>>>>
>>>>>>
>>>>>> The Firewall/Session Border controls will have sev=
eral criteria when
>>>>>> PSAPs
>>>>>> are overloaded, but AFAIK, no existing firewalls o=
r 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 w=
orks for the other users of
>>>>>> these systems, we're unlikely to be able to have e=
mergency services
>>>>>> special
>>>>>> firewalls or SBCs.
>>>>>
>>>>> We're not talking about existing firewalls and SBCs. &=
nbsp;We're talking about
>>>>> ESInet Border Control Function. If you don't def=
ine what you want there,
>>>>> you'll live with what you get. My suggestions ar=
e not beyond what's
>>>>> possible, it's all software.
>>>>>
>>>>> -Marc-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--B_3339998035_321754--
From br@brianrosen.net Mon Nov 2 06:53: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 E746228C15B for ; 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 ; 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 ; 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
) 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
To: Marc Linsner ,
Message-ID:
Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWC
In-Reply-To:
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:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-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" 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"
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" 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 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" 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"
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" wrote:
>>>>>> >>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> On 10/30/09 2:29 PM, "Brian Rosen"
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
Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
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.
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.
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.
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.
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.
Brian
On 11/2/09 10:13 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
<=
SPAN STYLE=3D'font-size:11pt'>I have no problem with indications that advise t=
he PSAP call-taker:
- “This caller is using a SP we don’=
t know, please query the caller as to their identity and location.”=20
- “There is no validation that the IP address of thi=
s caller exists at the reported location, please query further about locatio=
n.”
I have a problem with:
- 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.
I have no problem with:
- Requiring that calls to the ESInet meet a set of ope=
n 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 cann=
ot happen based on the SP utilized, the failure scenario of the algorithm is=
disastrous.
-Marc-
On 10/31/09 8:43 AM, "Brian Rosen" <br@brianrosen.net> wrote:
<=
SPAN STYLE=3D'font-size:11pt'>You are looking for trouble when there isn't any=
.
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.
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
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.
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 the<=
BR>
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.
Brian
On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>
>
>
> 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 =
thousands of
>> such successful service providers. It usually quickly settle=
s Darwinian
>> style to one or two. When the PSAPs see a bunch of calls fro=
m some new
>> source, they will call them up, and get them on the "we know =
you" list. No
>> big deal.
>>
>> You are still speculating about something that hasn't happened, an=
d 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 m=
atter.
>
> Exactly my point. In the scenario you've painted, the PSAP is go=
ing to
> evaluate the validity/urgency of the request for emergency assistance<=
BR>
> 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 emerge=
ncy is
> 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 pur=
pose.
> Simply stating these are the only tools available is not good enough.<=
BR>
>
> -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 SP=
s. I believe
>>> the mix of SPs and the products they offer will change dramati=
cally at a
>>> pace that PSAPs won't be able to keep up. This week Goog=
le, next week
>>> Noggle, the next week Boogle, etc. If in fact the PSAP r=
equires
>>> relationships with every SP that may send an emergency call th=
eir 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 service=
s without service
>>>> providers that have two way interactive media, where the i=
dentity of the
>>>> callers is a simple domain name, emergency calls from thos=
e devices is
>>>> interesting, they can't provide a suitable callback withou=
t 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, w=
e'll solve it.
>>>>
>>>> Right now, the simpler case of a direct call from an unkno=
wn source 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 p=
ath is being used 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 do=
n't have to drop calls
>>>> when we're attacked. OTOH, I don't want to promote t=
he proxy server 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 ar=
en'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&q=
uot; means SP path in 99.999% of cases
>>>>>> gets the PSAPs what they want. They don't ca=
re 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 calls, and
>>>>>> even
>>>>>> if they were in "From", they won't be th=
e domain in P-Asserted-Identity,
>>>>>> or
>>>>>> the SubjectAltName of the Identity signature. &nbs=
p;If some service that used
>>>>>> email addresses as identities sent us calls, the e=
mail address (with its
>>>>>> domain) is the "userpart" of the identit=
y, not the whole thing. There
>>>>>> are
>>>>>> some interesting problems when you have URI to som=
ething like 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. Certific=
ates for vanity domains
>>>>> are
>>>>> certainly doable. Besides P-Asserted-Identity is=
not a MUST in phonebcp.
>>>>> :^)
>>>>>
>>>>>>
>>>>>> The Firewall/Session Border controls will have sev=
eral criteria when
>>>>>> PSAPs
>>>>>> are overloaded, but AFAIK, no existing firewalls o=
r 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 w=
orks for the other users of
>>>>>> these systems, we're unlikely to be able to have e=
mergency services
>>>>>> special
>>>>>> firewalls or SBCs.
>>>>>
>>>>> We're not talking about existing firewalls and SBCs. &=
nbsp;We're talking about
>>>>> ESInet Border Control Function. If you don't def=
ine what you want there,
>>>>> you'll live with what you get. My suggestions ar=
e not beyond what's
>>>>> possible, it's all software.
>>>>>
>>>>> -Marc-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
=
--B_3340000415_20739401--
From mlinsner@cisco.com Mon Nov 2 09:33: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 C46333A6859 for ; 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 ; 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 ; 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
To: Brian Rosen
,
Message-ID:
Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMew=
In-Reply-To:
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:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 02 Nov 2009 17:33:29 -0000
On 11/2/09 8:53 AM, "Brian Rosen"
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" 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"
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" wrote:
>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 10/30/09 6:41 PM, "Brian Rosen"
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" 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"
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" wrote:
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 10/30/09 2:29 PM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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
) 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
To: Marc Linsner ,
Message-ID:
Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJg==
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:
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 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" wrote:
>=20
> On 11/2/09 8:53 AM, "Brian Rosen"
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" 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"
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" wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 10/30/09 6:41 PM, "Brian Rosen"
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" 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"
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" wrote:
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 10/30/09 2:29 PM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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
To: Brian Rosen
,
Message-ID:
Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXT
In-Reply-To:
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:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Nov 2009 14:18:29 -0000
On 11/2/09 11:56 AM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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
) 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
To: Marc Linsner ,
Message-ID:
Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcYAZalT2QABYXWCAAWZMewAAM2jJgAqrdXTAACkgmg=
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] 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: Tue, 03 Nov 2009 14:36:55 -0000
inline
On 11/3/09 10:18 AM, "Marc Linsner" wrote:
>
>
> On 11/2/09 11:56 AM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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 ); 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"
To: Brian Rosen
, Marc Linsner , "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:
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] 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: 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" wrote:
>
>
> On 11/2/09 11:56 AM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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
) 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
To: "Dawson, Martin" , Marc Linsner , "ecrit@ietf.org"
Message-ID:
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:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-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" 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" wrote:
>
>>
>>
>> On 11/2/09 11:56 AM, "Brian Rosen"
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:
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 ; 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 ; 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 ; 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
In-Reply-To: <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com>
Date: Tue, 3 Nov 2009 22:45:39 -0500
Content-Transfer-Encoding: 7bit
Message-Id:
References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com>
To: Ted Hardie
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\)" , 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:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-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:
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 ; 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 ; 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 ; 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 ; 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 ; 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"
To: "ecrit"
Subject: [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: 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