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

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 17:29:48 -0600

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, [email-masked] 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"

[...]

---

From: <[email-masked]>
Date: Wed, 16 Jan 2019 14:26:52 +0000

Hi Ben,
thank you for the review of my comments.
I did change the draft due to your comments.

With regard to your question:

“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?”

So if you apply privacy regarding RFC3326 i.e. on all levels with privacy user, header, history & session there will be no information within the SIP message left which has an information about the user sending the message.

Target headers    where   user     header    session   id   history

   --------------------------------------------------------------------

   Call-ID (Note)      R   anonymize    -         -       -      -

   Call-Info           Rr   delete    not add     -       -      -

   Contact             R      -      anonymize    -       -      -

   From                R   anonymize    -         -       -      -

   History-Info        Rr     -       delete    delete    -    delete

   In-Reply-To         R    delete      -         -       -      -

   Organization        Rr   delete    not add     -       -      -

   P-Asserted-Identity Rr     -       delete      -     delete   -

   Record-Route        Rr     -      anonymize    -       -      -

   Referred-By         R   anonymize*   -         -       -      -

   Reply-To            Rr   delete      -         -       -      -

   Server              r    delete    not add     -       -      -

   Subject             R    delete      -         -       -      -

   User-Agent          R    delete      -         -       -      -

   Via                 R      -      anonymize    -       -      -

   Warning             r   anonymize    -         -       -      -

Thus I think that the user indication will not help anybody in identifying the user of the device sending the message.

I hope you can agree on that.

So I will upload an updated draft as soon as possible.

Best Regards

Roland

Von: sipcore <[email-masked]> Im Auftrag von Ben Campbell
Gesendet: Dienstag, 15. Januar 2019 00:30
An: Jesske, Roland <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: ***CAUTION_Invalid_Signature*** Re: [sipcore] AD Evaluation of draft-ietf-sipcore-reason-q850-loc-04

Thanks!

Ben.

On Nov 30, 2018, at 4:38 AM, [email-masked]<mailto:[email-masked]> wrote:

[...]

§4:

Okay.

§6 and §7:

I could add:

Would this be enough?

[...]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jan 2019 17:02:31 -0600

Hi Roland,

I think this version is ready for IETF Last Call. I will request that shortly.

I still have some minor editorial comments below. These can be addressed along with any IETF LC feedback.

Thanks!

Ben.

> On Jan 14, 2019, at 5:29 PM, Ben Campbell <[email-masked]> wrote:
> 
> Signed PGP part

I think it would be worth mentioning that in the draft.

[…]

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

I think we’ve resolved that part, but looking at the new language:

"When applying privacy according to [RFC3323] 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."

I think readers will still get confused by the use of “location” to describe something that’s not a “physical” location. I think it would help in this sentence to clarify that we are talking about “ISUP location”. Also, the is the use of RFC 3323 really relevant? That is, I don’t think the ISUP location reveals the identity one way or another, right? It’s not up to this draft to worry about whether some other part of the SIP message does.

Finally, there are some minor grammar issues. I propose the following simplification:

“The ISUP location value itself will not reveal the identity of the originating or terminating party of the call.  It shows only the ISUP network location of the device that released the call. The ISUP location does not show show the physical location of the caller or callee.”

(Nit) §7, new text: I propose the following edit:

OLD:
"[RFC3398] does an extensive security consideration due to
   interworking between ISUP and SIP.”
NEW:
"[RFC3398] describes detailed security consideration due to
   interworking between ISUP and SIP."

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jan 2019 17:07:43 -0600

Oops, I forgot two more minor editorial comments. This does not change the last call status.

- Abstract: The abstract should not contain citations. It’s okay to mention an RFC number, but don’t put it in brackets like a citation would be in the body.

- It needs a normative reverence to RFC 8174.

Thanks!

Ben.

> On Jan 30, 2019, at 5:02 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi Roland,
> 
>> On Jan 14, 2019, at 5:29 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Signed PGP part