Re: [secdir] secdir review of draft-ietf-sipcore-info-events

Christer Holmberg <> Mon, 26 April 2010 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90D393A6993 for <>; Mon, 26 Apr 2010 05:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.941
X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3zMG5FpReiVN for <>; Mon, 26 Apr 2010 05:43:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D94E43A6B9B for <>; Mon, 26 Apr 2010 05:43:46 -0700 (PDT)
X-AuditID: c1b4fb3d-b7bf6ae000005bec-33-4bd58a7531da
Received: from (Unknown_Domain []) by (Symantec Brightmail Gateway) with SMTP id 35.10.23532.57A85DB4; Mon, 26 Apr 2010 14:43:33 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 26 Apr 2010 14:43:33 +0200
From: Christer Holmberg <>
To: Sandra Murphy <>, Adam Roach <>
Date: Mon, 26 Apr 2010 14:43:31 +0200
Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-info-events
Thread-Index: AcrkS8PJRsNZFtp4S8KgbBF/Bk6uDQA8adKA
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Apr 2010 12:43:52 -0000

Hi Sandy, 

>>>This specification sort-of provides a SIP-based tunnel for 
>>>application protocols.
>>>1: What prevents (or allows detection of) insertion of bogus Info 
>>>Package specifications? (e.g. by a proxy). If nothing, then why is 
>>>this ok?
>>This is the general way that SIP works, and it applies to all the SIP 
>>header fields. It's not great, but proxies are implicitly 
>>trusted to do the right thing. If it's a problem for INFO, then it's a problem 
>>for everything that has ever used or will ever use SIP.
>Aye, and therein lies the rub.  ;-}
>In my usual broken-record nagging, insider failures are hard 
>to protect against, sometimes impossible.  But knowing just 
>how bad things might get (how much damage an insider failure 
>could potentially cause) might be a good idea. It might 
>inspire people to put strong operational controls in place.  
>Buy a bigger liability policy. Abandon all hope ye who enter 
>here. etc.
>When I made some similar comments on a different SIP draft a 
>while back, there was a discussion on the sip wg list of 
>writing down somewhere what the wg chair called the "please 
>molest me" security model. I didn't follow the discussion to 
>the end, so I don't know if that ever got past the good 
>intention stage and if so where the written down text ended up.

I guess Adam can comment on the status about that.

However, I see that as a generic work, and not something that should be done in the Info-Events draft.

Section 10.10 talks about the usage of some security mechanism in order to protect the data, and I am not sure what more we could say in this draft.