Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-reason-q850-loc-04

From: Ben Campbell <[email-masked]>
Date: Thu, 29 Nov 2018 22:57:09 -0600

Hi,

This is my AD evaluation of draft-ietf-sipcore-reason-q850-loc-04. I have some substantive and editorial comments that I would like to resolve prior to IETF last call.

Thanks!

Ben.
--------------------------

*** Substantive Comments ***

§3: “open to be used by any other network”
That would really mean “any other network that includes ISUP interworking gateways and uses Q.850 reason codes”, right?

§4:
- Figure 1: Is it possible the Q.850 location code list will ever change? if so, how will this list stay in sync? 3326 just referenced Q.850 for the reason codes; can this do the same?

- “Thus other values are not within the scope of this document.”
I’m not sure what that means. Are non-listed values forbidden? Undefined? Are they defined in _other_ documents?

- "Depending on the direction the UAC or UAS shall include the location...”
I’m not sure what that means. Does it mean “Depending on whether the message is a request or a response”?

Also, is that “shall” intended as normative?  (I suggest it not, since I assume inserting the location is optional.) Would it make sense to just say “... the UAC or UAS includes the location...”?

§6 and §7:

Unfortunately, RFC 3326 contains no privacy considerations at all, so we really can’t say that this doesn’t change them. The expectation for privacy considerations has changed since that RFC was published. I think this document does need to describe any privacy considerations that  the combination of a Q.850 reason code and location might have.

For example, can an intermediary learn anything about the end user behavior by examining them that it couldn’t learn otherwise? The answer might well be “no”, but the draft should explain the reasoning behind that.

Similarly unfortunately, the security considerations in RFC 3326 did not address ISUP interworking. Could an attacker do anything destructive or useful to the attacker by monitoring or tampering with Q.850 location information in a SIP message?

§9.1: The Header Fields Parameter sub registry also needs the “Predetermined Values” and “Reference” column filled in . I assume those values are “Yes”, and “RFCXXXX” (with XXXX replaced with the assigned RFC number), respectively.

*** Editorial Comments ***

- Header: The Updates field should just say “Updates: 3326”.

- Abstract: Please mention the update in the abstract.

§1:
- Please add a sentence of two to explain what “reason of release” means. (Should that be “reason for release”?) I know that’s in 3326--it doesn’t need detail here, but it needs enough for people to realize what you are talking about.

- 2nd sentence: The antecedent of “It” is ambiguous.

- “does specify” -> “specifies”

- The last sentence seems like a non sequitur, since this is the first mention of location. Perhaps the previous sentence could say''..., but not the Q.850 location information.

- The draft needs to elaborate on the what Q.850 represents. Otherwise, reviewers are going to assume location in the geolocation sense, and get really worried about privacy issues.

§2: Please use the new boilerplate from RFC8174, unless there is a specific reason not to.

§4:
- 2nd paragraph: s/“The mechanism employed”/“This specification “

- The second sentence has redundant Q.850 citations.

-2nd to last paragraph, "This approach is only valid in cases when the ISUP [Q.850] ocation is available.” I suspect “invalid” should be “possible” or something to that effect.

- last paragraph, “in other cases the location, if present, MUST be ignored”: I suggest “Other values MUST be ignored if present."

§5:
- First paragraph:
s/“... set up... ”/ “...sent...”
s/“... set to 1 meaning ...”/“... set to 1, meaning ..."

---

From: <[email-masked]>
Date: Fri, 30 Nov 2018 10:38:26 +0000

Hi Ben,
thank you for your extensive review.
Please find the answers below.

When should I deliver a new draft then? 
ASAP?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Ben Campbell <[email-masked]>
> Gesendet: Freitag, 30. November 2018 05:57
> An: [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: AD Evaluation of draft-ietf-sipcore-reason-q850-loc-04
> 
> Hi,
> 
> This is my AD evaluation of draft-ietf-sipcore-reason-q850-loc-04. I have some
> substantive and editorial comments that I would like to resolve prior to IETF
> last call.
> 
> Thanks!
> 
> Ben.
> That would really mean “any other network that includes ISUP interworking
> gateways and uses Q.850 reason codes”, right?
> 
[RJ] Yes
> §4:
> - Figure 1: Is it possible the Q.850 location code list will ever change? if so,
> how will this list stay in sync? 3326 just referenced Q.850 for the reason
> codes; can this do the same?
> 
[RJ] PSTN is sooner or later going in retirement.
The bit values (0000-1111) will not be extended. The naming of  locations defined within Q.850 will from my point of view not change. Nevertheless all values which could change have an generic naming within the draft. Since we have discussed the same possibility earlier, thus we have added all values from 0000 to 1111.

So an interworking can be guaranteed in any case, even the naming of the location in PSTN may change. 

The last try to  change any location was around 2002 in ITU-T and that was not successful. 
The only changes appearing is adding a cause value. The latest 3 cause values were added in 2001, 2002 and 2018.
But changing location names would result in PSTN with big incompatibilities where everybody. Thus touching locations in ISUP would harm.

> - “Thus other values are not within the scope of this document.”
[RJ] Yes 16 Values is the maximum number.
> Are they defined in _other_ documents?
[RJ] We have interworked every possible bit value out of Q.850 for location, there are no more left over.
> message is a request or a response”?
[RJ] Yes this can be a request or an response. Do you expect some more worde then?
> 
> Also, is that “shall” intended as normative?  (I suggest it not, since I assume
> inserting the location is optional.) Would it make sense to just say “... the UAC
> or UAS includes the location...”?

[RJ] Yes SHALL=MUST. Within Q.850 the location is mandatory to be set when sending a cause Value.
That is why we put in shall. But I could life also with your proposal.
> 
> §6 and §7:
> 
> Unfortunately, RFC 3326 contains no privacy considerations at all, so we really
> can’t say that this doesn’t change them. The expectation for privacy
> considerations has changed since that RFC was published. I think this
> document does need to describe any privacy considerations that  the
> combination of a Q.850 reason code and location might have.

[RJ] I would propose to delete then the first sentence.
Thus the considerations would state:
While the addition of the location parameter
   does provide an indicator of the entity that added the location in
   the signaling path this provides little more exposure than the
   [Q.850] cause itself.

I could add:
When applying privacy according to RFC 3323 the location value will not give any hint to the identity originating or terminating party of the call. It shows only the location of the release of the call which maybe the end device itself (location user) or any other network part. 
The location is even not showing from which city or town the call is coming from. 

Would this be enough?
> 
> For example, can an intermediary learn anything about the end user behavior
> by examining them that it couldn’t learn otherwise? The answer might well be
> “no”, but the draft should explain the reasoning behind that.
>
[RJ] see above

> Similarly unfortunately, the security considerations in RFC 3326 did not
> address ISUP interworking. Could an attacker do anything destructive or
> useful to the attacker by monitoring or tampering with Q.850 location
> information in a SIP message?
> 
[RJ] I could add:
RFC3398 does an extensive security consideration due to interworking between ISUP and SIP. Beyond this considerations the addition of the location does not add more security concerns.
The location shows the network part where the call is released. Knowing this does not increase the possibilities of extended fraud scenarios. 

> §9.1: The Header Fields Parameter sub registry also needs the
> “Predetermined Values” and “Reference” column filled in . I assume those
> values are “Yes”, and “RFCXXXX” (with XXXX replaced with the assigned RFC
> number), respectively.
> 
[RJ] YES, OK will do that.
> - Header: The Updates field should just say “Updates: 3326”

[RJ] YES, OK will do that.