Subject: [secdir] secdir review of draft-ietf-sipcore-199-02

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Feb 2010 09:56:50 -0500 (EST)

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  Document editors and WG chairs should treat these comments just 
like any other last call 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?).

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.)

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.")

-- Sam

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Feb 2010 08:11:37 +0100

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