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

[Ben Campbell <[e-mail]>]

Apologies for the late response. I somehow missed seeing your response until now. Comments inline. I removed sections that seem resolved.

Please submit a new revision as soon as you are ready.

Thanks!

Ben.

> On Nov 30, 2018, at 4:38 AM, [e-mail] wrote:
> 
>> 

[...]

>> *** 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?
>> 
> [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.

Okay.


> 
>> - “Thus other values are not within the scope of this document.”
> [RJ] Yes 16 Values is the maximum number.
>> I’m not sure what that means. Are non-listed values forbidden? Undefined?
>> 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.

IIUC, you are saying there are no possible other values. If so, perhaps “Thus other values are out of scope...” would make more sense as “Thus other values are not possible”?

>> 
>> - "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”?
> [RJ] Yes this can be a request or an response. Do you expect some more worde then?

I think “Depending on whether the message is a request or a response...” would be more clear than “Depending on the direction..."

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

I’m okay with making it normative. My concern was that it was not capitalized.

>> 
>> §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?

If the call was released by the end device, does that not let people infer information about the original callee, if that device can be associated with the callee?

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

Okay. If I might suggest a bit of wordsmithing:
- s/ "Beyond this considerations” / "Beyond these considerations”
- s/ “more security concerns” / “additional security concerns"

[...]