Re: [sipcore] draft-ietf-sipcore-keep - New draft version

[Paul Kyzivat <[e-mail]>]

Christer,

[speaking as individual]

I have reviewed the new version. The change in use of upstream and 
downstream has worked out well - it now seems understandable and not 
upside down. *Except* I think you missed changing one place - in 1.1:

    In some cases a User Agent Client (UAC) does not register itself
    before it establishes a session, but in order to maintain NAT
    bindings open during the session it still needs to be able to
    negotiate sending of keep-alives towards its adjacent upstream SIP
    entity.  A typical example is an emergency call, where a registration
    is not always required in order to make the call.

In that "upstream" should be "donwstream".

But I still think there are problems with the rules for routing messages 
so as to take advantage of the keep-alives while avoiding doing anything 
improper.

The intro lists three cases, but I think two of them (1.1 and 1.3) are 
describing the same situation. So we get two cases from there:

WITH-OUTBOUND:
   no register, dialog establishing request, outbound *is* in use.
   There is need of negotiating keep-alive use that isn't negotiated
   as part of outbound

WITHOUT-OUTBOUND:
   outbound is not supported and so not used, but keep-alives still
   desired. Includes both REGISTER and Dialog-establishing sub-cases.

In the WITH-OUTBOUND case:

outbound results in the negotiation of keep-alives on the last hop to 
the UA. So IIUC, the use of keep is to negotiate keep-alives on other 
hops along the path. 5626 specifies the procedures for selecting/reusing 
the flow for subsequent requests in dialog for the hop it is concerned 
with. It does not do so for any other hop. keep-05 has text added to 4.4 
for this case, but I don't think it is right.

This is a case that could be covered, in part, by 5923 (connect-reuse). 
In the TLS case where 5923 allows bidirectional use of a connection, the 
keep-alive mechanism is complementary. But that is no good for TCP or 
UDP. The security concerns that prevented 5923 from permitting 
bidirectional use of TCP are also reasons it can't in general be used here.

It should arguably be ok to use TCP and UDP bidirectionally here as long 
as the usage is restricted to in-dialog requests. But its going to take 
some additional text to limit it this way and explain the reason that 
security is not compromised.

In the WITHOUT-OUTBOUND case:

You can't fall back on outbound to give any guidance on when to use a 
flow and when not.

In the dialog-establishing case, the rules that apply to the non-last 
hops in the WITH-OUTBOUND case should also apply here, even to the last hop.

In the REGISTER case it gets harder. The problem is that you want to 
support new outbound out-of-dialog requests. If you have a TLS 
connection, then 5923 tells you when you can do it. Without that, the 
reuse of the flow must be tied to the registration in some way. I know 
you want this for IMS which has its own form of secure connection. But 
you are going to have to find some way to specify it here that will 
survive security considerations scrutiny. I don't know what that might be.

In any case, I suspect you need to reinstate the references to 5923 to 
make this all work.

I'm still hoping to get comments from an outbound expert here. They 
might be able to put all this stuff in context better than I can.

	Thanks,
	Paul

Christer Holmberg wrote:
> (Private)
> 
> Hi,
> 
> Based on your WGLC comments/discussions, I have put together a new version draft.
> 
> It can be found at:
> 
> http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-05pre.txt
> 
> Please check whether your issues have been addressed.
> 
> Please note that I have now "switched" downstream and upstream, and suggested definition text for those.
> 
> Please also note that I for now have removed section 6, regarding overlapping with the connect-reuse spec.
> 
> Regards,
> 
> Christer