Subject: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Sep 2013 10:54:18 -0500

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-insipid-session-id-reqts-08
Title: Diameter Overload Control Requirements
Reviewer: Vijay K. Gurbani
Review Date: Sep-17-2013
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as an Informational
RFC; two minor issues follow.

Major: 0
Minor: 2
Nits:  2

Minor:

- S3.2, the list of what are not considered communication sessions
  appears rather arbitrary.  What criteria makes you consider these
  are not communication sessions?  Is it the fact that some sort of
  conferencing (ad-hoc or organized) is being used?  If so, best to
  state this up front.  Otherwise I am left wondering why these cases
  are not considered to be a communication session.  I can certainly
  see the benefit of knowing which endpoints participated in a
  conference call that is indexed by a unique Session-ID.  So, why
  preclude this?  Any reason for doing so will help understand the
  decision for considering conferencing out of scope.

- S7, third paragraph: In cleartext traffic that is not subject to an
  rfc4474-type mechanism, I am not sure how you can prevent an attacker
  from spoofing (i.e., changing) the identifier to render is useless?

  Likewise, under similar conditions I am not sure how an application
  can verify that the session identifier was not changed.

  Unless, of course, you are stating that the identifier must be
  transmitted over a confidential and privacy preserving channel (which
  seems to be the gist of the last sentence of the section).  If that
  is the case, then you may want to highlight in a more prominent form
  than currently stated.

Nits:

- S3.1, first paragraph: s/that,/which,/

- S3.1, seventh paragraph: s/speaks of/considers/
   (less colloquial that way).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Sep 2013 16:04:22 -0500

On 09/17/2013 03:04 PM, James Polk wrote:
> Vijay
> comments below

James: Thanks for your time.  More inline.

> I guess I don't know what you are asking for clarity on. The INSIPID
> solutions draft (mostly done, if we can get around a backwards
> compatibility inconsistency within the WG) certainly has conferencing as
> one of the main use-cases of that draft. However, these two drafts we
> written at about the same time (with the reqs ID reaching WG consensus
> first), and by pretty much the same author set (at least the same two
> editors) and some wording might have been overlooked in one draft where
> it is in the other draft.

In that case, I would strongly suggest to harmonize the text between
the mechanism draft and the requirement draft.  You can see the problem
if the former considers conferencing in scope and the latter does not.

> That's a roundabout way of saying that if you or anyone has suggested
> text or a list of bullets/summary of what should be here in the reqs
> draft, we'll certainly give strong consideration to putting that text
> in. Paul and I did struggle with this section of what is and what is not
> a communication session, and felt a short list would be better than a
> longer, more exhaustive list. It's picking how many examples - but not
> too many - are included. Any help here would be appreciated.

But it seems to me that the short list in the draft right now precludes
the use cases that the mechanism draft supports.  So, at the very
least, the current short list should be expunged.

As to what exactly is a communication session?  Hmmm ... initially I was
going to suggest that the Replaces header creates a new communication
session, disjoint from its parent; but it seems that the mechanism
draft considers the Replaces to have the same session identification
(Section 6 of draft-ietf-insipid-session-id-02).  So, in the end I am
not sure what to suggest here.  Alternatively, why bother providing a
list of what does NOT constitute a communication session?  Unless
hampered by interoperation between protocols (i.e., H.323 to SIP, Q.931
to SIP and vice-versa), it seems to me that the notion of a
communication session is already defined in your draft.  Just leave it
at that.  No?

> we'll attempt to make this more clear - that "...the identifier must be
> transmitted over a confidential and privacy preserving channel..."  as
> you say.

Or more appropriately, the SIP message containing the identifier must be
transmitted over a confidential and privacy preserving channel.

> Thanks for the review

Thank you for taking my feedback into consideration.

Cheers,

- vijay

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Sep 2013 17:14:26 -0400

Guys,

> we'll attempt to make this more clear - that
> "...the identifier must be transmitted over a
> confidential and privacy preserving channel..."  as you say.

It's not critical that this value be hidden, necessarily.  Ideally, all SIP
signaling would be secured against snooping, but that does not directly
affect the Session-ID header value itself.

The main point of that paragraph is that we adhere to REQ6 to ensure that
values are unique in time and space.  They need to be random such that
somebody who wants to be a troublemaker cannot easily guess what Session-ID
values might be in use and re-use them for a different call in the same time
and place.

Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Sep 2013 16:36:33 -0500

> values might be in use and re-use them for a different call in the same time

But that is not what the text in question says (c.f., third paragraph of
Section 7).

The text talks about "surreptitiously spoof[ing] the identifier".  To me
this means changing the identifier such that the origin does not know
that the change occurred.

If what you are worried about is using the same Session-ID to replay a
message in the same time quantum and space, then saying what you write
above is sufficient.  That is, "[The identifier needs] to be random such
that it is impervious to guess and reuse for a different session in the
same time and space."

Thanks,

- vijay

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Sep 2013 19:32:11 -0400

Vijay,

I believe that those things are covered.  In that paragraph, it talks about
the fact that one should an attacker who might use the same value.  It then
talks about the fact the value should be random (or otherwise really hard to
just guess).  It also talks about the secure transport of the session-ID.
Aside from REQ6, none of the language in that paragraph is normative.

I'm not sure exactly what you think we need to further clarify in that
paragraph (the last one in Section 7), but I'm happy to make changes as you
suggest.

Paul

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2013 5:37 PM
> To: Paul E. Jones
> Cc: 'James Polk'; [email-masked];
> 'IESG IESG'; [email-masked]
> Subject: Re: APPSDIR review of draft-ietf-insipid-session-id-reqts-08
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 18 Sep 2013 10:55:18 -0500

> paragraph (the last one in Section 7), but I'm happy to make changes as you

Paul: I did not do the review to tick a process box somewhere.  I did
it for the normal reasons related to any peer review including rendering
the resulting draft less ambiguous and more useful to people tasked with
actually implementing this piece of work.

> Aside from REQ6, none of the language in that paragraph is normative.

Regarding your assertion that "those things are covered", let me
simply say that they are not covered in sufficient detail to allow a
random implementer to pick this draft and implement the work.

The phrase "surreptitiously spoof[ing]" implies (to me) changing the
identifier such that the origin does not know that the change occurred.
If what you mean is that the identifier should not be copied and
replayed, just say so.  Drop the spoofing bit.

But really, the problem is broader than that.  Underlying REQ5 is the
unstated assumption that the SIP traffic is protected through normal
hop-by-hop TLS.  If this was not the case, then how do you know that the
intermediary that injected the identifier is malicious or benign?
Furthermore, the paragraph in question also asks for "sufficient
verification ... to ensure integrity" of the identifier.  Note that
no means is given as to how the verification is to be performed.
Clearly, what you have in mind is hop-by-hop TLS, but you have not
stated this explicitly.  In fact, this all encompassing hop-by-hop TLS
is not present as a requirement, and is only mentioned as the last
sentence in Section 7.  Simply saying that RFC3261 threat model applies
is not sufficient.  RFC3261 allows you to send SIP messages in
cleartext.

You really need to make a case in Section 7 that

  (a) identifiers must not reveal privacy (REQ4),
  (b) identifiers must not be amenable to insertion by untrusted
      intermediaries (REQ5),
  (c) identifiers must be globally unique in time and space (REQ6),
  (d) must not be amenable to copy-and-replay attacks (no requirement in
      S5 for this); otherwise, diagnostic equipment will not know what
      to do with duplicate identifiers,
  (e) identifiers must not be amenable to guessing, i.e., if an adversary
      possesses the current identifier, this knowledge must not allow it
      to guess the next identifier (no requirement in S5 for this),
  (f) identifiers must be verfiable at the receiving endpoint (no
      requirement in S5 for this).

TLS takes care of (b), (d), (f), and to a certain extent (e).  If an
adversary cannot observe the current identifier, it cannot use it to
guess the next one.

Unfortunately, I don't see such a logical progression in the last
paragraph of Section 7.  The second paragraph makes a good job of
ensuring REQ4 is met, but the third paragraph appears to be more a
stream of consciousness.

I believe that we write these drafts so that others, probably not well
versed with the assumptions as we are, can read the drafts and
implement the work with minimum ambiguity.  I don't think the draft
passes that test.

In the end, I have indicated my disposition with "Minor comments",
not "Major comments".  So if I have not convinced you that parts of
the draft should be looked at again, you are of course, free to
disregard the advice and move ahead.  From my part, the review is
certainly not binding.  However, if you buy my arguments, I'd be more
than happy to work with you to suggest text to make the draft better.

Thanks,

- vijay

---

From: James Polk <[email-masked]>
Date: Tue, 17 Sep 2013 15:04:42 -0500

Vijay

comments below

At 10:54 AM 9/17/2013, Vijay K. Gurbani wrote:
>this draft (for background on appsdir, please see â€‹

I guess I don't know what you are asking for 
clarity on. The INSIPID solutions draft (mostly 
done, if we can get around a backwards 
compatibility inconsistency within the WG) 
certainly has conferencing as one of the main 
use-cases of that draft. However, these two 
drafts we written at about the same time (with 
the reqs ID reaching WG consensus first), and by 
pretty much the same author set (at least the 
same two editors) and some wording might have 
been overlooked in one draft where it is in the other draft.

That's a roundabout way of saying that if you or 
anyone has suggested text or a list of 
bullets/summary of what should be here in the 
reqs draft, we'll certainly give strong 
consideration to putting that text in. Paul and I 
did struggle with this section of what is and 
what is not a communication session, and felt a 
short list would be better than a longer, more 
exhaustive list. It's picking how many examples - 
but not too many - are included. Any help here would be appreciated.

>  from spoofing (i.e., changing) the identifier to render is useless?

I agree with this, but SIP entities need to be 
prepared to receive Session-ID header-values that 
are different. The draft says this.

>  can verify that the session identifier was not changed.

see about

Thanks for the review

James

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Sep 2013 21:03:47 +0000

Vijay,

I apologize for taking so long to get back to you.  This has been an 
extremely busy week for me.

Please see comments below.

------ Original Message ------
From: "Vijay K. Gurbani" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]; "'James 
Polk'" <[email-masked]>; "'IESG IESG'" <[email-masked]>; 
[email-masked]
Sent: 9/18/2013 11:55:18 AM
Subject: Re: [apps-discuss] APPSDIR review of 
draft-ietf-insipid-session-id-reqts-08
>actually implementing this piece of work.
  I understand.  I wasn't trying to be combative.  Rather, I'm just 
stating that I'm not sure what more is needed.  Please don't assume I 
was being argumentative, as that certainly was not the intent.
>replayed, just say so. Drop the spoofing bit.
I cannot recall who introduced that language into that text, but the 
desire would be prevent two things:
1) We would not want an attacker changing the values in an existing SIP 
session, as this makes it more challenging for logging systems, for 
example
2) We would not want an attacker to send SIP messages through the 
network presenting a given Session Identifier that is used by another 
session.

The reason is that such abuse interferes with any use network elements 
might have for the Session Identifier, effectively rendering it useless.

The proposed remedies in that paragraph are to mandate REQ6 and 
encourage encryption.
>intermediary that injected the identifier is malicious or benign?
REQ5 does not, in itself, assume or require some kind of security.  In a 
trusted service provider network, for example, the value might be 
inserted at the edge by an SBC and no encryption used through the 
service provider domain.
>is not sufficient. RFC3261 allows you to send SIP messages in
The required security differs based on the environment.  As I mentioned 
above, a service provider domain may have minimal internal security 
requirements, placing all security at the edge.  Likewise, the issues 
related to the Session-ID are not unlike those of the Call-ID.  In fact, 
an attack on the Call-ID or "To" header in SIP is far more problematic 
than an attack on the Session-ID.   So, while I think most real-world 
implementations of SIP (ignoring Session-ID) should use TLS, at the very 
least, we cannot insert a requirement for use of any particular security 
mechanism.
>adversary cannot observe the current identifier, it cannot use it to
I do not disagree, but I cannot insert a requirement into this text that 
says TLS must be used.  There may be folks who would oppose that.  I 
think the particular means through which the requirements are met should 
be spelled out only in the solution text.  If you really disagree, we 
can go back to the WG and raise the point.  I certainly have no 
objection to that.
>than happy to work with you to suggest text to make the draft better.
I would wholeheartedly welcome concrete suggestions.  I know from 
experience that being too close to a piece of work can blind a person 
from seeing the problems.  A fresh pair of eyes and one who understands 
the issues is always helpful.

Paul

>
>Thanks,
>
>- vijay
>-- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Sep 2013 17:07:54 -0400

Vijay,

(My email client did not format that well. Let me try to correct that...)

------ Original Message ------
From: "Vijay K. Gurbani" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]; "'James 

Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Sep 2013 10:29:31 -0500

> extremely busy week for me.

Paul: No problem.  Please see inline.

> was being argumentative, as that certainly was not the intent.

No worries; I just wanted to make sure that if you made any changes,
they would be driven by what you would also consider actual problems,
and not driven by just trying to placate me :-)

> desire would be prevent two things: [...]

Right, it is the "encourage encryption" part that I think should garner
some attention.  One way to do so is suggested below.

> inserted at the edge by an SBC and no encryption used through the

SIP has developed this notion of a trust domain as a set of SIP nodes,
including B2BUAs, that are trusted to exchange some private information
among (and between) themselves.  This function goes by the wonderful
name of Spec(T) and is fully defined in rfc3324.  Other pieces of work
[1,2] that forsee a need to define a trust domain simply use the
Spec(T) function to do so.

> least, we cannot insert a requirement for use of any particular security

The Spec(T) mechanism at least allows you to state that you have
thought of the security ramifications of the header being sent out in
cleartext, and therefore, domains that wish to exchange the header in
non cleartext format should comply to Spec(T).  You can define Spec(T)
as is done in [1], without having to delve into the mandating TLS or
choosing cipher specs for TLS.

It seems appropriate that if we know that usurping the session
identifier will lead to problems then we at least try to provide a way
to mitigate these problems without mandating specific security policies.
I think Spec(T) allows you to do so.

Regarding the statement that an attack on the Call-ID or "To" header
being more disruptive than an attack on Session-ID, sure I agree.  But
at least we have rfc4474 to mitigate that (I understand it is not used
widely, but it *is* there).

> can go back to the WG and raise the point.  I certainly have no

I am not privy to the discussions that happened in the working group
along making TLS mandatory.  But from your description it seems that
the working group does not want to mandate it.  Maybe couching the
security aspects in terms of Spec(T) will suffice?

[1] See Section 5.4 of 
http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-09
[2] 
http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-02

Thanks,

- vijay

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Sep 2013 00:47:12 +0000

Vijay,

Thanks for the additional feedback.  I will consult with a few of the 
folks in the WG to see how we can best address your points.

Paul

------ Original Message ------
From: "Vijay K. Gurbani" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]; "'James 
Polk'" <[email-masked]>; "'IESG IESG'" <[email-masked]>; 
[email-masked]
Sent: 9/23/2013 11:29:31 AM
Subject: Re: [apps-discuss] APPSDIR review of 
draft-ietf-insipid-session-id-reqts-08

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 25 Sep 2013 12:40:34 -0500

> folks in the WG to see how we can best address your points.

Paul: Sure, no worries.  Thanks for your time.

- vijay