Re: [secdir] secdir review of draft-ietf-sipcore-199-02 - Samuel's comments

[Christer Holmberg <[e-mail]>]

 
Hi,

Below are my replies to Samuel's comments.

>This defines an intermediate "we're done" response, allowing 
>parties to tear down some state, while still requiring a 
>final response.
> 
>The obvious risk (forging these, just like forging a TCP 
>reset) is documented.
> 
>Even though the point of the 199 response is to allow early 
>resource release, I notice that some state is still being 
>maintained for these sessions.  It might be worth explicitly 
>reminding readers of when they can timeout (is there a 
>timeout specified somewhere?).

The 199 response only tears down a specific early dialog within a session (during the setup phase of a session there may be multiple early dialogs), but the session itself, and all other early dialog within it, are unaffected. For those normal RFC 3261 procedures apply.

--------------
 
>I'm also a little worried about the implications of one party 
>or another trying to continue the dialog, perhaps 
>maliciously, after sending or receiving one of these.  What 
>if one of these were used to disable a monitoring or billing 
>system, but the parties continued to use the open session?  
>(Compare to sending a weak C-tone on a wiretapped PSTN line.)

That is of course possible, but in my opinion it is possible in SIP already without this, using other responses and requests which tears down a dialog or session. The protocol itself does not prevent users from continue to send media using the parameters (IP address/port, codecs etc) that thay have negotiated for the session.

So, if one wants to prevent this from happening, some policy procedures need to be applied in the network.

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

>Editorial:
> 
>Please expand the acronyms in the abstract.  (The id-nits 
>checklist says the abstract "Should be meaningful to someone 
>not versed in the technology; most abbreviations must be 
>expanded on first use.")

Sure, I'll fix that.

Regards,

Christer