That is enough for me. Thanks. Jari
On Apr 25, 2014, at 9:44 AM, [email protected] wrote: > Hi Jari, > > 1. I have put the document status to informal > 2. I have shifted TS 24.229 to normative and updated the references to the > latest 3GPP Release > 3. Added Text to 6.1: That is, the privacy of the user relies on the other > entities in the session not disclosing information that they have learned > about the user. > 4. For the P-Access-Network Info header I was looking to our use cases. The > main use case is the emergency call where a possibility is: the UE includes a > P-Access-Network-Info header field, which contains a cell identifier or > location identifier, which is subsequently mapped, potentially by the > recipient, into a real location. > > So we have the statement in 4.4.2: > Additionally, the first outbound proxy, if in possession of > appropriate information, can also add a P-Access-Network-Info header > field with its own information. > > So I have added a sentence in Section 4.4 saying: > > A proxy providing services based on the P-Access-Network header field must > consider the trust relationship to the UA or outbound proxy including the > P-Access-Network header field. > > I hope that solves the issues. A version -14 will coming soon. > > Best Regards > > Roland > > > > -----Ursprüngliche Nachricht----- > Von: Jari Arkko [mailto:[email protected]] > Gesendet: Donnerstag, 10. April 2014 16:15 > An: Jesske, Roland > Cc: [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected] > Betreff: Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13 > > Roland, > > Thanks for your responses. I think these are generally to the right > direction, I have commented below where I think some further discussion is > needed. > > On Apr 10, 2014, at 11:07 AM, [email protected] wrote: > >> Hi Marry, >> I'm really sorry, this mail slipped through my hands. And I didn't see >> anything in the data tracker history. Since I'm the main Editor, it is my >> fault that this was not answered. >> It is true we cannot claim any speed if we do nothing. Again I'm Sorry. >> >> So here are my answers. For the Gen-review. >> So I have created a Version -14 which I can upload now. Please indicate if I >> should do this or if I should wait for further comments? >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-drage-sipping-rfc3455bis-13 >> Reviewer: Martin Thomson >> Review Date: 2014-02-27 >> IETF LC End Date: 2014-03-14 >> IESG Telechat date: (if known) >> >> Summary: I find it strange that this 3GPP document is being published on the >> standards track. But since it's a -bis there is clearly precedent, and it >> is otherwise sound. >> >> [RJ] Yes it is informal as RFC3455 is I'll change that. > > It is published for informational according to the last call announcement, > and I can't find any statement from the draft that this would be on the > standards track. > >> Major issues: >> >> This document doesn't include enough information for me to some of the >> headers. For example, there isn't enough information in the document to >> allow me to interpret the contents of cgi-3gpp: >> cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) >> (I pick on P-Access-Network-Info, because I'm somewhat familiar with it.) >> >> This can probably be addressed by the inclusion of appropriate normative >> references. I seem to recall there being a 3GPP TS that covered at least >> some of these. >> >> [RJ] Below that section we have the text: >> The access-info MAY contain additional information relating to the access >> network. The values for "cgi-3gpp", "utran-cell-id-3gpp", >> "i-wlan-node-id", "dsl-location" and "ci-3gpp2", "ci-3gpp2-femto" and >> "gstn-location" are defined in 3GPP TS 24.229 >> >> Do we need more? > > I think this is fine. > > But would anyone mind if 24.229 was a normative reference? In my mind I need > to read it to understand what to put into these attributes. > >> Minor issues: >> >> RFC 4244 is now obsolete, see 7044. (related nit: Change log entry #2 seems >> quite defensive, unnecessarily so. This document only needs to define >> P-Called-Party-ID, and reference History-Info as an alternative >> mechanism.) >> >> [RJ] Replaced >> [RJ] Due to your comment I have removed the whole text as follows: >> Additionally the P-Called-Party-ID >> header field has been defined within 3GPP systems since release >> 5, and therefore it is realistic to expect implementations to be >> already released to the field. It is therefore considered that >> replacement of the P-Called-Party-ID header field within 3GPP >> systems causes more issues that it solves, and therefore the >> update of RFC3455 <xref >> target="RFC3455"></xref> to remove the P-Called-Party-ID header field >> will not be addressed. However it is recommended that any new >> usage of this type of functionality should use the History-Info >> header field defined in RFC 7044 <xref target="RFC7044"></xref>rather >> than the P-Called-Party-ID header field > > OK for me. > >> Change log entry #5, mentions a shortcoming of 3455 (no registry for access >> network types), but the draft does nothing about it. It seems to be >> propagating the mistake it notes. >> >> [RJ] Yes I can agree this. so this seems a action for future. > > Yes. > >> >> A lot has happened since RFC 3455 was published. The privacy considerations >> around the use of P-Access-Network-Info are unchanged from their pre-Geopriv >> form. In particular, I find the UA knowledge part to be problematic; >> Geopriv definitions can probably help here. >> >> [RJ] sorry cannot do > > I think a better approach would be to describe the issues, rather than try to > change what the implementations do, if that is what you meant by using > Geopriv definitions. > >> S6.1 P-Associated-URI is a powerful linkability vector, which could be a far >> more serious privacy leak than the text implies. The following seems like >> good advice, but is not sufficient: >> >> An eavesdropper could possibly collect the list of identities a user >> is registered. This can have privacy implications. To mitigate this >> problem, this extension SHOULD only be used in a secured environment, >> where encryption of SIP messages is provided either end-to-end or >> hop-by-hop. >> >> You also have to trust the other end of the hop with the information. >> I think that's implicit, but probably needs to be stated. >> >> [RJ] I have addedthe following: >> And where a trustrelationship equivalent with that defined in RFC 3325 <xref >> target="RFC3325">between entities exist > > This is good, but I'd be even more explicit. Maybe add "That is, the privacy > of the user relies on the other entities in the session not disclosing > information that they have learned about the user. > >> >> S6.4 This claim sounds false to me: >> >> However, there >> are no security problems resulting from a UA inserting incorrect >> information. Networks providing services based on the information >> carried in the P-Access-Network-Info header field will therefore need >> to trust the UA sending the information. A rogue UA sending false >> access network information will do no more harm than to restrict the >> user from using certain services. >> >> Any parameter whereby changing it can cause loss of service is likely to be >> true in the inverse. The draft makes no claims that would make me believe >> otherwise. >> >> [RJ] Since we have the P-Access-Network-Info as header that is also set up >> by the IMS entity P-CSCF with adding the network provided element there is a >> difference in interpreting the header by Applications. Of course the network >> provided information is trustful and can be used for sensitive services >> since the user provided information should only be used by services which >> are not sensitive. >> >> [RJ] Is this sufficient? > > I feel that this may need more explanation. If you point was that the P-CSCF > adds information that is trustworthy and leads to discovery of false > information planted by the rogue UA, then maybe we should be explicit about > this. > > Jari > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
