Subject: [sipcore] AD review draft-ietf-sipcore-199-00

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2009 09:24:41 -0500

In preparing this document for IETF last call, I found a few points we  
should
discuss before moving forward.

Major Comments

I don't understand the sentence in section 4.1 that talks about
RFC5009.  There is not enough here to inform an implementor and don't
think 5009 is required reading to understand or implement this
document (hence, I don't agree that 5009 should be a normative
reference). The sentence has been there for a long time, but
I think other things have pulled reviewer's eyes away from it.

In Sections 5 and 9, the document says to include SDP in a 199 if
RFC3263 requires it. I would like to see some additional discussion
around whether this is the right way to deal with this edge case. If
it is, then this document needs to explain how a UA should handle
receiving an offer in a 199.  A different path out is to say that
such a 199 MUST NOT be sent reliably. (More explanation of why we
allow 199 to be sent reliably at all (why this is SHOULD not MUST)
would also help).

Last sentence on page 8: This paragraph is talking about the proxy
generating a 199 itself. It would be terribly misleading from a
diagnostics point of view for the proxy to put the Record-Route and
contact from some UA (it would then look like the 199 came from the
remote endpoint - is that what you are trying to accomplish?). Why is
having these bits in the message useful at all?

I don't think the document currently provides a solid answer to this
question (maybe I'm missing it): If a proxy has multiple branches
outstanding and receives a 200 OK on one of them, it forwards it
immediately. As the other branches complete, should the proxy send
199s for them (assuming they didn't complete with additional 200s)?

The security consideration section is not yet sufficient. If there is
an The sentence in section 4.1 talks effective attack here, we need
text that explores it. If there isn't, we need text that argues it
isn't.

Minor Comments

Bottom of page 3, next to last paragraph, last sentence: This assumes
the response can't be recovered from, precluding responding to
authentication challenges, extension negotiation, etc.

Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP?

Section 8 is completely redundant. It adds no value to the draft. I
suggest deleting it.

Nits

The 2119 language (two instances of MAY unless I missed more)
appearing in the introduction are inappropriate in an introduction.

Page 5, second paragraph : is "shall not" meant to be normative?

Page 8 Section 6 first paragraph: Suggest dropping "on an early
dialog" from the first sentence. Does it add anything? This would
help avoid the problem the current text has about assuming proxies
know about dialogs.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Oct 2009 20:20:52 +0200

Hi Robert,

Comments inline. 

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

>In preparing this document for IETF last call, I found a few points we
should discuss before moving forward.
>I don't understand the sentence in section 4.1 that talks about
RFC5009.  There is not enough here to inform an 
>implementor and don't think 5009 is required reading to understand or
implement this document (hence, I don't agree that 
>5009 should be a normative reference). The sentence has been there for
a long time, but I think other things have pulled 
>reviewer's eyes away from it.

I can change 5009 into an informative reference.

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

>RFC3263 requires it. I would like to see some additional discussion
around whether this is the right way to deal with 
>this edge case. If it is, then this document needs to explain how a UA
should handle receiving an offer in a 199.  A 
>different path out is to say that such a 199 MUST NOT be sent reliably.
(More explanation of why we allow 199 to be sent 
>reliably at all (why this is SHOULD not MUST) would also help).

I wouldn't like to generally disallow to send 199 reliably, in case
there is some future use-case which would need it. That's the reason for
the SHOULD: don't send it reliably unless you have a good reason to do
so.

Regarding the specific must-include-SDP-offer case (which will be very
rare, in my opinion) I see two alternatives:

1.  We disallow reliable 199 in such cases
2.  We say that the UAS must include e.g. an SDP offer without any m-
lines.

My proposal is to describe both alternatives, and say that the UAS MUST
use of them.

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

>Last sentence on page 8: This paragraph is talking about the proxy
generating a 199 itself. It would be terribly 
>misleading from a diagnostics point of view for the proxy to put the
Record-Route and contact from some UA (it would then 
>look like the 199 came from the remote endpoint - is that what you are
trying to accomplish?). Why is having these bits 
>in the message useful at all?

The intention is NOT to make the 199 look like it came from the
endpoint, but someone commented that the UA could be confused if the
bits aren't included.

Personally I would bo ok to remove the text, since the proxy is not
allowed to send a 199 reliably (there will be no PRACK etc, for which
the bits would b needed)

>I don't think the document currently provides a solid answer to this
question (maybe I'm missing it): If a proxy has 
>multiple branches outstanding and receives a 200 OK on one of them, it
forwards it immediately. As the other branches 
>complete, should the proxy send 199s for them (assuming they didn't
complete with additional 200s)?

The intention is that NO 199s are sent after 200 OK has been forwarded
on a branch, and the proxy sends CANCEL on the other branches. 

I DO agree that it is not clear in the spec, and that we can add some
text about that.

Now, IF we would want the proxy to send 199 for the other branches the
proxy would have to wait for the final INVIE responses on the cancelled
branches, because even if the proxy sends CANCEL the terminating UE may
already have sent a 200 OK.

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

>The security consideration section is not yet sufficient. If there is
an The sentence in section 4.1 talks effective 
>attack here, we need text that explores it. If there isn't, we need
text that argues it isn't.

I am not sure I understand the comment. Could you please clarify?

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

>Bottom of page 3, next to last paragraph, last sentence: This assumes
the response can't be recovered from, precluding 
>responding to authentication challenges, extension negotiation, etc.

Again, I am not sure I understand the comment.

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

>Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP?

I can add it. How would you like to change to look like?

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

suggest deleting it.

I based this on other drafts, but I can remove it.

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

>Nits
>
>The 2119 language (two instances of MAY unless I missed more) appearing
in the introduction are inappropriate in an 
>introduction.

I propose to change "MAY" to "can" (in the introduction).

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

>Page 5, second paragraph : is "shall not" meant to be normative?

Yes. I'll change it to uppercase.

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

>Page 8 Section 6 first paragraph: Suggest dropping "on an early dialog"
from the first sentence. Does it add anything? 
>This would help avoid the problem the current text has about assuming
proxies know about dialogs.

I can drop it from the first sentence.

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

Thanks for your comments!

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2009 13:29:35 -0500

Quick response to the clarifying questions:

<large chunk snipped>

> I am not sure I understand the comment. Could you please clarify?

Wow - that got paste clobbered somewhere along the way.
It should have said:

The security consideration section is not yet sufficient. If there is
an  effective attack here, we need text that explores it. If there  
isn't,
we need text that argues it isn't.

This sentence:
    When SIP entities upstream receive the non-2xx
    final response they will release resources associated with the
    session, and the UAC will terminate the session setup.
is assuming the final response wasn't something the UAC could react to
by trying again with some related changes (like responding to a  
401/407).

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 Oct 2009 17:53:19 +0200

Hi,
 
>The security consideration section is not yet sufficient.
>
>It should have said:
>
isn't, 
>we need text that argues it isn't. 

Ok, I'll look into that. 
	
-------------------

>Bottom of page 3, next to last paragraph,
>
>
>This sentence:
401/407).

Ok, now I got it.

So, I guess the text should say something like:

"When SIP entities upstream receive the non-2xx final response they will
normally release resources associated with the
session, and the UAC will terminate the session setup, unless the final
response (e.g. a 401/407 final response) triggers a new session setup
request to be sent."

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 16 Oct 2009 20:29:16 +0200

Hi, 

text about that.

Actually, when taking a closer look at the text, I think this is already
covered. The text says that when the proxy receives a non-2xx final
response, it sends 199 if the forking proxy has not already sent a final
resposne for any of the early dialogs. So, if a final response (2xx or
non-2xx) response has been sent, additional non-2xx responses will not
trigger 199.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 16 Oct 2009 20:40:58 +0200

Hi,

>I can add it. How would you like to change to look like?

I would need some clarification on why DTLS would have to be added here.
The issue is not related to a specific key management mechanism used,
but with the fact that the media is encrypted in general.

Of course different key management mechanisms may have different impacts
on the needed resources etc, but I still don't see why this would be an
issue specific to DTLS. 

Regards,

Christer