Subject: [Ecrit] Deployment models

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 May 2005 23:06:05 -0400

We had discussed several deployment models (network architectures), 
including, roughly in order of challenge:

(Vertical integration) Network access and call signaling (SIP) operated 
by the same entity or at least two entities with a close relationship; 
for example, the IAP operates an outbound proxy in each subnet that can 
insert or provide location information;

(User cert) The IAP and VSP are separate entities that don't cooperate, 
but the IAP might operate an outbound proxy that provides identity 
assertion based on access identity.

(Certified customer, no relationship) The IAP hands out customer 
certificates that allow a user to certify that they are known to a 
larger entity. Customers can give their private keys to their evil twins 
and shady friends, but they would presumably face some liability for 
this. The VSP is a separate entity in this case.

(No relationship) The IAP and VSP have no relationship; one certifies 
location and maybe a customer name, the other an identity only. There is 
no long-term stable relationship between the access identifier and the 
voice identifier. (Indeed, there may not be any voice identifier as 
such, as the caller may just run its own SIP client, without the benefit 
of a Vonage-like entity.)

The basic assumption is that the IAP provides location (and maybe 
identity), the VSP identity, but no location. Obviously, in the first 
case, they are the same, so the distinction is moot.

This only matters if the receiver can discriminate under overload. If 
the receiving call center is somehow obligated to take all calls with 
equal probability, signing does not matter, except to prevent a bad 
actor from modifying in-transit signaling requests (for which channel 
security is probably a better approach).

In all cases, it doesn't matter for this discussion whether the location 
is identified by a location object or some pointer to a location object.

Henning

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 May 2005 07:47:52 -0400

I agree with these model descriptions.  I have problems with terminology.

I think we all know and agree with the term "Internet Service Provider".  A
customer has a direct relationship with his ISP.

I have been using the term "Access Infrastructure Provider" for the entity
that actually owns the infrastructure.  This may or may not be the ISP.
However, when the AIP and the ISP are not the same entity, the ISP
borrows/rents/leases facilities from the AIP.  Location is always reported
to the subscriber by the ISP.  The AIP is the entity that actually knows
where the subscriber is.  Location is always originated by (and possibly
signed by) the AIP.  There are cases where the infrastructure is split
between two entities.  For example, one entity may actually own the wires,
and another the layer 2 infrastructure.  Again, there are contractual
relationships between these parties.  I'm calling the AIP the Layer 2
entity.  The ISP provides IP packet forwarding.  

I'm not sure what entity an IAP is.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Schulzrinne
> Sent: Monday, May 16, 2005 11:06 PM
> To: [email-masked]; [email-masked]'
> Subject: [Geopriv] Deployment models
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 May 2005 09:08:42 -0400

Some people prefer IAP (Internet Access Provider), but it's the same  
thing as your AIP. (I find IAP somewhat more parallel to ISP.)

The VPN comment has nothing to do with location, but rather with the  
IP prefix. This was for the case that LO signatures turn out to be  
useless.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 May 2005 21:09:25 -0400

> including, roughly in order of challenge:

This thread is started in the context of discussing signing of LCI?

> (Vertical integration) Network access and call signaling (SIP) 
> operated by the same entity or at least two entities with a close 
> relationship; for example, the IAP operates an outbound proxy in each 
> subnet that can insert or provide location information;
>
> (User cert) The IAP and VSP are separate entities that don't 
> cooperate, but the IAP might operate an outbound proxy that provides 
> identity assertion based on access identity.

Perhaps I'm misreading this, but is there a real-life example of this 
deployment scenario?

> larger entity. Customers can give their private keys to their evil 
> twins and shady friends, but they would presumably face some liability 
> for this. The VSP is a separate entity in this case.
>
> location and maybe a customer name, the other an identity only. There 
> is no long-term stable relationship between the access identifier and 
> the voice identifier. (Indeed, there may not be any voice identifier 
> as such, as the caller may just run its own SIP client, without the 
> benefit of a Vonage-like entity.)

You seem to have assumed public key crypto.  Is there a reason why 
shared key could not be used?

> In all cases, it doesn't matter for this discussion whether the 
> location is identified by a location object or some pointer to a 
> location object.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 May 2005 21:37:04 -0400

> This thread is started in the context of discussing signing of LCI?

Motivated by, but I don't want this to be seen as discussing that issue. 
  I don't think much of this discussion depends on signing of a 
particular data object. I'm just trying to ascertain models that have 
security impact if an entity wants to ascertain who is calling and/or 
from where.

> Perhaps I'm misreading this, but is there a real-life example of this 

Kind of. Many corporate firewalls essentially operate that way, i.e., 
they'll terminate application sessions and act as an outbound proxy.

This model in particular is rather hypothetical. It might avoid some of 
the tieing-ourselves-in-knots that the separation of known signaling 
identity and known location incurs. Operating an outbound proxy just for 
emergency calls is a minor burden for an IAP, and doesn't seem to 
substantially interfere with the ability to choose any VSP for other 
voice services.

> shared key could not be used?

In some cases, the scenario is that a third party verifies the 
assertion, e.g., that a call was generated by 
[email-masked]. As far as I know, this is most readily 
accomplished by using PK.

In the case of the outbound proxy you asked about, standard 
authentication, such as SIP Digest auth, would work (based on shared keys).

Henning

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 May 2005 10:28:42 -0400

I don't think the detailed access model matters to our work.  IAP is an 
enetity that provides location information based on L1 and/or L2 
knowledge.  I don't think we in the IETF need to know the detailed 
structure of this entity, even though that structure can be of great 
practical importance.