Subject: Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

From: Jari Arkko <[email-masked]>
Date: Wed, 9 Apr 2014 14:41:04 +0200

Thanks for the review, Martin. Have there been any responses or changes based on your comments? I do not see the document version having changed...

Jari

On Feb 28, 2014, at 1:43 AM, Martin Thomson <[email-masked]> wrote:

> 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.
> 
> 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.
> 
> 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.)
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Nits/editorial comments:
> 
> S1 Having the disclaimer as the first section is a little strange.  I
> don't know what it is disclaiming yet.
> 
> S1, S3 It looks like a few characters are missing from these sections:
> "trust.These", "environment The", "[RFC3455]   This"
> 
> The change log contains a lot of normative language.  I expected to
> see pointers to changes, and maybe some justification, but items
> include normative-sounding text and no pointers(7), other contain
> pointers and duplicate text (3&4)
> 
> Change log #6 notes the removal of a field; given that this is
> extensible, why not just mark the CDMA 2000 item deprecated instead of
> removing it?
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 09:39:59 -0700

On 9 April 2014 05:41, Jari Arkko <[email-masked]> wrote:
> Have there been any responses or changes based on your comments? I do not see the document version having changed...

I have seen no response or revision.

---

From: <[email-masked]>
Date: Thu, 10 Apr 2014 10:07:13 +0200

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

Please resolve these comments along with any other Last Call comments you may receive.

Reviewer: Martin Thomson

Review Date: 2014-02-27

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.

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:

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?

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

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.

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

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:

   hop-by-hop.

[RJ] I have addedthe following:

And where a trustrelationship equivalent with that defined in RFC 3325 <xref target="RFC3325">between entities exist

   However, there

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?

Nits/editorial comments:

S1 Having the disclaimer as the first section is a little strange.  I don't know what it is disclaiming yet.

[RJ] That is a copy from RFC3455. RFC3455 fullfills the requirements documented in RFC4083. Would this be sufficient to write as a one sentence statement?

[RJ] Done

The change log contains a lot of normative language.  I expected to see pointers to changes, and maybe some justification, but items include normative-sounding text and no pointers(7), other contain pointers and duplicate text (3&4)

[RJ] tried to solve this. deleted normative text and made some corrections to your points.

Change log #6 notes the removal of a field; given that this is extensible, why not just mark the CDMA 2000 item deprecated instead of removing it?

[RJ] As far as I know is that 3GPP does not want to use it anymore. Is it not sufficent to not the deletion?

Best Regards

Roland

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Donnerstag, 10. April 2014 01:08
An: [email-masked]
Cc: Atle Monrad; Gonzalo Camarillo; Richard Barnes
Betreff: Fwd: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

Can you guys please respond to Martin's review?  This document is on the IESG telechat agenda for tomorrow.  Honestly, you guys cannot complain that IETF is not doing work in a timely manner if authors cannot respond to reviews like this, especially at this stage of the game.

I will note that I haven't seen all the messages around these reviews because people don't usually add the shepherd and I don't seem to be being picked up by any aliases.

Regards,
Mary.

---

From: Atle Monrad <[email-masked]>
Date: Thu, 10 Apr 2014 09:43:54 +0000

Thanks Roland

Mary, is the draft back on track ??

:)

/atle

________________________________

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation
Ericsson

From: [email-masked] [mailto:[email-masked]]
Sent: 10. april 2014 10:07
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Atle Monrad; Gonzalo Camarillo; [email-masked]
Subject: AW: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

Hi Marry,

Reviewer: Martin Thomson

Review Date: 2014-02-27

Major issues:

Do we need more?

Minor issues:

mechanism.)

[RJ] Replaced

[RJ] sorry cannot do

   hop-by-hop.

   However, there

[RJ] Is this sufficient?

Nits/editorial comments:

[RJ] Done

Best Regards

Roland

An: [email-masked]<mailto:[email-masked]>

Regards,
Mary.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 10 Apr 2014 13:56:31 +0300

Hi Roland,

do not update the draft until the AD tells you so.

Cheers,

Gonzalo

On 10/04/2014 11:07 AM, [email-masked] 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 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?
> 
>  
> 
> 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.
> 
>  
> 
> Major issues:
> 
>  
> 
> headers.  For example, there isn't enough information in the document to
> allow me to interpret the contents of cgi-3gpp:
> 
> 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.
> 
>  
> 
> 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?
> 
>  
> 
> Minor issues:
> 
>  
> 
>          target="RFC3455"></xref>to remove the P-Called-Party-ID header
> field
> 
>        header field defined in RFC 7044
> <xreftarget="RFC7044"></xref>rather than the P-Called-Party-ID header field
> 
>  
> 
>  
> 
> access network types), but the draft does nothing about it.  It seems to
> be propagating the mistake it notes.
> 
>  
> 
> 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
> And where a trustrelationship equivalent with that defined in RFC 3325
> <xreftarget="RFC3325">between entities exist
> 
>  
> 
>  
> 
> 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?
> 
>  
> 
>  
> 
> Nits/editorial comments:
> 
>  
> 
> [RJ] That is a copy from RFC3455. RFC3455 fullfills the requirements
> documented in RFC4083. Would this be sufficient to write as a one
> sentence statement?
> 
>  
> 
>  
> 
> The change log contains a lot of normative language.  I expected to see
> pointers to changes, and maybe some justification, but items include
> normative-sounding text and no pointers(7), other contain pointers and
> duplicate text (3&4)
> 
>  
> 
> *Von:*Mary Barnes [mailto:[email-masked]]
> *Gesendet:* Donnerstag, 10. April 2014 01:08
> *An:* [email-masked]
> *Cc:* Atle Monrad; Gonzalo Camarillo; Richard Barnes
> *Betreff:* Fwd: [Gen-art] Gen-ART review of
> draft-drage-sipping-rfc3455bis-13
> 
>  
> 
> Can you guys please respond to Martin's review?  This document is on the
> IESG telechat agenda for tomorrow.  Honestly, you guys cannot complain
> that IETF is not doing work in a timely manner if authors cannot respond
> to reviews like this, especially at this stage of the game. 
> 
>  
> 
> I will note that I haven't seen all the messages around these reviews
> because people don't usually add the shepherd and I don't seem to be
> being picked up by any aliases. 
> 
>  
> 
> Regards,
> 
> Mary. 
> 
> From: *Martin Thomson* <[email-masked]
> <mailto:[email-masked]>>
> To: Jari Arkko <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]> Review Team"
> <[email-masked] <mailto:[email-masked]>>, IESG IESG <[email-masked]
> <mailto:[email-masked]>>,
> [email-masked]
> <mailto:[email-masked]>
> 
>> Have there been any responses or changes based on your comments? I do
> not see the document version having changed...
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Apr 2014 17:15:15 +0300

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-masked] 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 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.

>       "i-wlan-node-id", "dsl-location" and "ci-3gpp2", "ci-3gpp2-femto" and  "gstn-location" are defined in 3GPP TS 24.229

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.

>       header field defined in RFC 7044 <xref target="RFC7044"></xref>rather than the P-Called-Party-ID header field

OK for me.

> [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 knowled…

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.

> 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.

> [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 Appl…

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Apr 2014 15:23:07 -0700

> 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.

Yes, a description of the issues would be appropriate.  I don't expect
to change anything here, but this is a very poorly understood
architecture with privacy properties that are challenging.  Making
those properties clearer is - I believe - entirely appropriate.
Geopriv [RFC6280] has tools that you can use - a framework of terms
and concepts - that should make this relatively easy to achieve.  It
shouldn't require more than a couple of paragraphs.

---

From: <[email-masked]>
Date: Fri, 25 Apr 2014 09:44:16 +0200

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-masked]] 
Gesendet: Donnerstag, 10. April 2014 16:15
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

Roland,

I think this is fine.

OK for me.

Yes.

Jari