Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-keep

From: Christer Holmberg <[email-masked]>
Date: Sun, 1 Aug 2010 21:48:07 +0200

Hi John,

First, please also look at the reply I intend to send to Paul's comments. He has some issues with the upstream and downstream wording, and I know you have provided input on that. So, the outcome of that may of course also have impact on new text etc that I suggest for some of your comments.

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

>This has some minor issues that need fixing before it is ready to go.
>
>1. In 4.2.2: ".  Once negotiated, keep-
>   alives are sent until the registration is terminated, or until a
>   subsequent registration refresh request is sent or forwarded.  When a
>   subsequent registration refresh request is sent or forwarded, if a
>   SIP entity is willing to continue sending keep-alives associated with
>   the registration, usage of keep-alives MUST be re-negotiated.  If
>   usage is not successfully re-negotiated, the SIP entity MUST cease
>   sending of keep-alives associated with the registration."
>Yet in 4.2.3:
> "Once negotiated, keep-alives MUST
>  be sent for the lifetime of the dialog, until the dialog is
>   terminated.  Once usage of keep-alives associated with a dialog has
>   been negotiated, it is not possible to re-negotiate the usage
>   associated with the dialog."
>
>There seems to be inconsistency between registrations and dialogs. For a registration, keep-alive can be terminated 
>when the registration is refreshed, whereas for a dialog there is no way to terminate keep-alives (without terminating the dialog). 
>Would it not be better to align the two? The use case for being able to negotiate no keep-alives during a registration that is already using 
>keep-alives is not clear. It might be simpler to say that, once keep-alive has been negotiated, it remains in place for the duration of the registration or dialog.

The issue is not related to a need to be able to negotiate no keep-alives duinrg a registration that is already using keep-alives. But, as Hadriel pointed out at one point, a proxy that is 
willing to receive keep-alives might not be able to distinguish between an initial registration and a registration re-fresh. It would need be registration aware. Hadriel did not want to enforce such requirement.

Personally I don't see that as a big problem, as registrations aren't refreshed that often in the first place. But, I would not like to "allign" by mandating renegotiation of keep-alives associated with dialogs with every re-INVITE/UPDATE, because I'm afraid it would make the mechanism too "heavy".

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

>2. "When the SIP entity receives the associated response, if the "keep"
>   parameter in its Via header field of the response contains a
>   parameter value, it MUST start to send keep-alives towards the same
>   destination where it would send a subsequent request (e.g.  REGISTER
>   requests and initial requests for dialog) associated with the
>   registration (if the keep-alive negotiation is for a registration),
>   or where it would send subsequent mid-dialog requests (if the keep-
>   alive negotiation is for a dialog)."
>
>This sentence is rather long. But my main concern is with the dialog-initiating case. Whilst "where it would send subsequent mid-dialog requests" is correct, that is not necessarily where the Via header field entry with 'keep' has come from. Or putting it another way, if a non-
>record-routing proxy were to include 'keep', sending keep-alives towards that proxy would be pointless. Of course, a non-record-routing proxy should not include 'keep'. In this case the first mid-dialog request should contain 'keep' again, and if the response to that also 
>contains 'keep' (with a value) then keep-alives can start.
>So although the 'keep' in Via in principle works for both registrations and dialogues, there are subtle differences. The present wording doesn't seem to be wrong, but it certainly doesn't convey the real situation very satisfactorily, IMO. It might be useful to have separate 
>statements for registrations and dialogs. It might also be useful to state that a non-record-routing proxy MUST NOT insert 'keep' (probably more appropriate in 4.4).

I guess that proxies that want to SEND keep-alives associated with a dialog shall also insert themselves in the dialog route set.

So, I could add the following text to section 4.3:

"A SIP entity MUST NOT indicates willingness to send keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [3261]."

...and the following text to section 4.4:

"A SIP entity MUST NOT indicates willingness to receive keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [3261]." 

(That is more general, and will also cover endpoints, SBCs and B2BUAs that use Contact instead of Record-Route.)

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

>3. "Once a SIP entity has negotiated sending of keep-alives associated
>   with a dialog towards its adjacent upstream SIP entity, it MUST NOT
>   insert a "keep" parameter in any subsequent SIP requests associated
>   with the dialog."
>
>This doesn't seem to be quite correct. A sends 'keep' to B on a dialog-forming request. B does not record route. A sends mid-dialog request to C. Surely in this case, A needs to be able to include 'keep'? But this text seems to forbid it.

Correct. I guess the text should say that once the sending of keep-alives associated with a dialog has been *negotiated*, the SIP entity must not inset a "keep" parameter in subsequent requests.

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

>A note further down seems to cover the points I made in 2 and 3 above, but I don't think that is satisfactory. In particular, using a note to contradict a MUST NOT is incorrect.
>
>4. "NOTE: If a SIP entity inserts a "keep" parameter in its Via header
>   field of an INVITE request, and it receives multiple responses
>   (provisional or final) associated with the request, as long as at
>   least one of the responses, per dialog, contains a "keep" parameter
>   with a parameter value it is seen as an indication that the adjacent
>   upstream SIP entity is willing to receive keep-alives associated with
>   the dialog."
>
>This isn't incorrect, but it is hard to work out what it means. If there is a dialog-forming response, and then further responses on that
>same dialog, then 'keep' in any one of these should be sufficient. But if there are multiple dialog-forming responses, then 'keep' on any 
>one of these will (I assume) apply only to that dialog, and not other dialogs formed by other responses. I think there is room for stating 
>this more clearly.

I am not sure how I can make it more clear, but what about the following:

"NOTE: As long as at least one response, associated with a dialog, contains 
a "keep" parameter with a parameter value it is seen as an indication that the adjacent
upstream SIP entity is willing to receive keep-alives associated with
the dialog on which the response is received."

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

>5. In 4.3: "The SIP entity must support the amount of STUN
>   which is required to apply the STUN keep-alive mechanism defined in
>   [RFC5626], and it must support the CRLF keep-alive mechanism defined
>   in [RFC5626]."
>
>I assume the use of lower case "must" (two instances) is motivated by the belief that we are repeating what is in RFC 5626. However, I don't think that is correct - we are stating new normative requirements (i.e., to apply the mechanisms in RFC 5626 to the cases covered 
>by this I-D). Therefore I think we should use "MUST" in each case. Similarly in 4.4.

I guess people like Adam could give guidance on whether to use lower or upper case here.

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

>6. The Security Considerations section merely states: "This specification does not introduce security considerations in
>   addition to those specified in [RFC5626]."
>
>Considering the I-D addresses dialogs, not just registrations, it sounds like this statement might not be sufficient. For example, if a dialog hop crosses 
>a firewall, use of keep-alive is likely to keep the firewall pin-hole open for an extended period. I leave it to the security experts to determine 
>whether this is an issue.

A registration will also keep the pin-hole open, and frequent sending of SIP requests will keep the pin-hole open. 

But, let's see what the security people say.

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

>7. In section 3: ""keep" parameter: A SIP Via header field parameter that a SIP entity
>   can insert in its Via header field of a request to explicitly
>   indicate willingness to send keep-alives towards it adjacent upstream
>   SIP entity.  If a SIP entity is willing to receive keep-alives from
>   its adjacent downstream SIP entity, and the Via header field
>   associated with the adjacent downstream SIP entity contains a "keep"
>   parameter, the SIP entity willing to receive keep-alives can add an
>   integer parameter value to that "keep" parameter.  The integer
>   parameter value can be used to indicate a recommended keep-alive
>   frequency.  A zero value indicates that the SIP entity is willing to
>   receive keep-alives, but that a recommended keep-alive frequency is
>   not provided."
>
>This seems top be far too much for a definition. Some of the material should instead be covered later in the document (and I suspect it already is).

Would the following be sufficient:

""keep" parameter: A SIP Via header field parameter that a SIP entity
can insert in its Via header field of a request to explicitly
indicate willingness to send keep-alives towards its adjacent upstream
SIP entity. A SIP entity can also insert the header field in a response to
explicitly indicate willingness to receive keep-alives from its adjacent downstream
SIP entity."

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

>Nits:
>N1. Change "Eventhough" to "Even though".
>
>N2. "since usage of keep-alives in most cases are implicitly negotiated"
>Change "are" to "is".
>
>N3. "usage of keep-alives are not implicitly negotiated"
>Change "are" to "is".
>
>N4. "usage keep-alives". Change to "usage of keep-alives".
>
>N5: "why usage needs to be explicitly negotiated."
>The word "why" seems to be wrong. Should it be "where"?

I would use "where", but I guess your english is better than mine, so... :)

>N6: "towards it adjacent upstream SIP entity"
>Change "it" to "its".
>
>N7: "the amount of STUN which is required" (two instances)
>In each case, change to "those aspects of STUN that are required".

I'll fix these.

Thanks for your comments!

Regards.

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 12:32:33 +0200

Hi John, 

Some more on one of your comments.

>>>3. "Once a SIP entity has negotiated sending of keep-alives 
>>>    associated with a dialog towards its adjacent upstream SIP entity, 
>>>    it MUST NOT insert a "keep" parameter in any subsequent SIP requests 
>>This doesn't seem to be quite correct. A sends 'keep' to B 
>>on a dialog-forming request. B does not record route. A sends 
>>mid-dialog request to C. Surely in this case, A needs to be 
>>able to include 'keep'? But this text seems to forbid it.
> 
>Correct. I guess the text should say that once the sending of 
>keep-alives associated with a dialog has been *negotiated*, 
>the SIP entity must not inset a "keep" parameter in 
>subsequent requests.

When taking a second look at the text, I actually think it is correct.

It already says that when the sending of keep-alive has been negotiated. It does not say once the "keep" parameter has been included.

Regards,

Christer