[sipcore] Comments on draft-ietf-sipcore-keep-05

[Hadriel Kaplan <[e-mail]>]

Howdy,
I think it's getting close to final.  Below are my comments...

Technical:
1) What happens if the two nodes indicate keepalives, but the downstream doesn't receive them?  In Outbound, it would cause a flow failure for the registration.  My guess is vendors will do the same for draft-keep. (probably even for dialog-based keepalives)  So to me that means (a) the indicated timer value is a maximum time which the sender must send them in, not just a "recommendation", and (b) failure to receive a response to the keepalive should trigger a re-Register, which needs to be indicated in text in the draft.


2) Just to be clear, even if there are multiple Registrations or dialogs on a given connection, only one keepalive "instance" would be active on that connection, right?  I.e., we're not talking about sending multiple keepalives, one per dialog/registration, on the same connection.  So something like this should be added to section 4.1:
"Even though the keepalive negotiation is performed on a registration or dialog basis, the keepalive mechanism is per transport connection, meaning only one keepalive is sent from the upstream to the downstream entity per TCP connection or UDP port pairs, even if there are multiple dialogs and registrations across them.  Since keepalive is negotiated in each REGISTER or dialog transaction, the most recently negotiated settings MUST be used for the whole connection."

There is, unfortunately, a complication around this stuff: a proxy can be stateful for some calls and stateless for others.  This means you can send a INVITE request downstream and be told to do keepalives, while your next INVITE to it does not, but you still need to do keepalives.  I'm not sure how to handle this in text.


3) Section 4.2.2 says:
   Usage of keep-alives
   can be negotiated when the registration is established, or later
   during the lifetime of the registration.

I don't believe it's technically possible to re-negotiate it during the lifetime, because the "lifetime" is the expiry value of the Registration.  Once you send another REGISTER to renegotiate it, it's a new "lifetime".  No?  


4) Section 4.3 has:
   A SIP entity that has negotiated sending of keep-alives associated
   with a registration MUST be prepared to receive, from the receiver of
   the keep-alives, SIP messages (requests and responses) associated
   with the registration on the same IP port:address from where the
   keep-alives are sent.  If the SIP entity sends the keep-alives over a
   connection-oriented transport protocol, it MUST be prepared to
   receive SIP messages associated with the registration over the same
   connection.  The same rules apply for SIP messages associated with a
   dialog, if the SIP entity has negotiated sending of keep-alives
   associated with a dialog.

Why is that in this draft?? (I don't understand how it relates)


5) Security considerations.  There are some security considerations which are not in 5626.  Just off the top of my head they are:

a) Any downstream SIP entity, beyond the adjacent downstream peer node, can modify the Via header identifying the local node and thus cause the local node to send keepalives to its adjacent peer (at high rates) if the peer does not support this keepalive mechanism.

b) A man-in-the-middle between two SIP nodes can modify the Via header at will, and thus can prevent keepalive from being used, or can decrease the timer value to a very low value to consume resources, or can cause the downstream to expect keepalives while the upstream does not know to send them and thus cause a failure.



Editorial:
- s/CRLF/double-CRLF/g

- Section 4.4 first para, change:
   The SIP entity must
   support those aspects of STUN that are required in order to apply the
   STUN keep-alive mechanism defined in [RFC5626], and it must support
   the CRLF keep-alive mechanism defined in [RFC5626].
To:
   The SIP entity must
   support those aspects of STUN that are required in order to apply the
   STUN keep-alive mechanism defined in [RFC5626] for connection-less
   transports such as UDP, and it must support the CRLF keep-alive 
   mechanism defined in [RFC5626] for connection-oriented transports 
   such as TCP and TLS over TCP.


-hadriel