Subject: [Insipid] draft-ietf-insipid-session-id versus RFC 3323

From: Brett Tate <[email-masked]>
Date: Tue, 28 Jun 2016 14:33:32 -0400

Hi,

Since the topic of privacy was raised... should the following snippet from
RFC 3323 cause the Session-ID to be removed by the privacy service?  If
not, why?  I thought I'd ask since Session-ID appears to be a
non-essential informational header.

RFC 3323 section 5.3:

"Note that the privacy service MUST remove any non-essential
informational headers that have been added by the user agent,
including the Subject, Call-Info, Organization, User-Agent, Reply-To
and In-Reply-To."

Thanks,
Brett

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 29 Jun 2016 01:59:18 +0000

Brett,

Looking through RFC 3323, the one section you called out was the one I also noticed could potentially apply. The question then becomes whether or not the Session-ID header is both “non-essential” and “informational”. I would say it is largely informational, however whether it is essential or not depends on your definition of essential. Could it be considered “essential” for troubleshooting? Maybe not because you could troubleshoot without it - it would just be more difficult - but it is not absolutely necessary (essential). However, a customer may have some diagnostic infrastructure in place that relies on the presence of the Session-ID header in which case then it is essential for their tools to work.

Also, the Session-ID behaves similar to a Call-ID header and 3323 does not mandate that the privacy service modify the Call-ID header (it MAY) and even then, the reason it gives for modifying Call-ID is "since the Call-ID commonly contains a hostname or IP address corresponding to the originating client” which the Session-ID header does not provide as the Session Identifier itself does not reveal any information about the user or device. It can only potentially reveal a relationship between two parts of a session.

Are there any examples of other headers that implementers of 3323 have not removed based on the clause in section 5.3? Do you have a strong opinion either way? I can see arguments for and against removing it, so I don’t have a strong opinion. Either way, does it bear mentioning in the Session-ID specification?

-Paul

> On Jun 28, 2016, at 2:33 PM, Brett Tate <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Wed, 29 Jun 2016 15:47:18 -0400

Hi,

Thanks for the response; reply is inline.

> Could it be considered “essential” for troubleshooting?
> Maybe not because you could troubleshoot without it - it
> would just be more difficult - but it is not absolutely
> necessary (essential). However, a customer may have some
> diagnostic infrastructure in place that relies on the
> presence of the Session-ID header in which case then
> it is essential for their tools to work.

I agree that some administrators might not want Session-ID to be removed.

> Are there any examples of other headers that
> implementers of 3323 have not removed based on the
> clause in section 5.3?

I assume that vendors have applied the concept in a variety of ways with
various degrees of configurability.

> Do you have a strong opinion either way?  I can see
> arguments for and against removing it, so I don’t have
> a strong opinion.

I also do not have a strong opinion.

> Either way, does it bear mentioning in the Session-ID
> specification?

Depending upon interpretation, draft-ietf-insipid-session-id and RFC 3323
have conflicting mandates.

If the working group desires a specific behavior, it should likely be
discussed within the draft if RFC 3323 causes an ambiguity or conflict with
the desired behavior.

If the intermediary removes the Session-ID, I assume that a different (or
maybe the same) intermediary might add a different Session-ID.

As usual, the topic of privacy related to lawful intercept doesn't need to
be discussed.  I assume that some vendors will implement conferenced lawful
intercept as not being a conference.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 29 Jun 2016 20:10:56 +0000

Thanks Brett. Let me see if perhaps I can add a mention in the Security and Privacy considerations section. As usual thanks for your insight and feedback.

-Paul

> On Jun 29, 2016, at 3:47 PM, Brett Tate <[email-masked]> wrote:
> 
> Hi,
>