Re: [Geopriv] Location Conveyance: Scenarios
Henning Schulzrinne <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Organization | Columbia University |
| Message-ID | <[email protected]> |
Thanks, Hannes; these are helpful to focus the discussion. I think, however, that the issue of security (encryption or integrity) and conveyance are essentially orthogonal. In other words, you can apply the same techniques, with similar problems, in all three conveyance mechanisms (by-value, by-attachment, by-reference). The procedural details differ (such as XML-DSIG and XML encryption vs. S/MIME vs. TLS), but the strength and the certificate problems are similar, albeit not identical. (For example, it is probably somewhat harder to deal with multi-recipient cases in S/MIME than in other mechanisms.) It might help streamline the discussion if we can agree on this general statement or show that it is mistaken. Henning Tschofenig, Hannes wrote: > Hi all, > > I have compiled a few message flows that would make it easier to discuss > the different scenarios. I have listed some challenges along with each > of the scenarios. > > > 1) Location by End Host / Per Value/ in Body > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (value/body) | | > | |----------------->| > | | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > * Likelyhood of the UA using S/MIME; nice on paper but does it reflect > reality? > * UA Alice needs to know that (a) intermediaries do not need to process > the PIDF-LO > (b) recipient has a certificate > * Unclear what happens if there are multiple recipients. > > > > 2) Location by End Host / Per Reference / in Body > > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (ref./body) | | > | |----------------->| > | | | > | Dereference | > |<==============================================>| > | | > | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > * Can be protected using S/MIME (see issue above) > * If not protected then the considerations of who is allowed to > dereference to a PIDF-LO are applicable. There is certainly a difference > between a reference pointing to a PIDF-LO at the UA itself and a > reference obtained using one of the discussed Geopriv L7 protocols. > It might be difficult for the end host to make the PIDF-LO available. It > might be difficult for him to have a server-side certificate but it > might be easier to control access to it. > > > 3) Location by SIP Proxy / Per Reference / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | | SIP Message | > | |----------------->| > | | Location | > | | (ref./header) | > | | | > | | | > | | Dereference | > | |<================>| > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * What should the SIP proxy but into the PIDF-LO when it is created > (policies, identifiers, etc.)? > * Authorization aspects: see above (Why cannot just everyone that sees > the reference in the header passing by dereference it?) > * Signing of the reference theoretically possible. SIP Proxy, however, > needs to know the intended recipient. > > > 4) Location by SIP Proxy / Per Value / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | | SIP Message | > | |----------------->| > | | Location | > | | (value/header) | > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * What should the SIP proxy but into the PIDF-LO when it is created > (policies, identifiers, etc.)? > * Data URI approach possible but with increased message size. > * Signing of the PIDF-LO possible but approach similar. SIP Proxy, > however, needs to know the intended recipient. > > > 5) Location by SBC / Per Value / in Body > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > (SBC) > | SIP Message | | | | > |---------------------------->| | | | > | Location (value/body) | SIP Message | > | |----------------->| > | | Location | > | | (value/body) | > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * If there is no solution for the cases available where the SIP proxy > can add a PIDF-LO and a reference is not acceptable (because of the > latency) it is likely that boxes will just do it. > * Does not play "nicely" with SIP. > * Problems with E2E security > > > 6) Location by End Host / Per Referene / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (ref./header) | | > | |----------------->| > | | | > | Dereference | > |<==============================================>| > | | > | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > > * Not sure about S/MIME usage > * Simlar considerations as in (2) > > Finally, I think it would be useful to differentiate between location > based services in general and emergency services since the requirements > are, in most cases, different. > > Ciao > Hannes > > _______________________________________________ > Geopriv mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip