Re: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 16 August 2018 13:32 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F3E130F17; Thu, 16 Aug 2018 06:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDNbM-6oXIyG; Thu, 16 Aug 2018 06:32:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFFE130E0D; Thu, 16 Aug 2018 06:32:32 -0700 (PDT)
X-AuditID: 12074422-f4bff70000004c70-ee-5b757bc0f4ff
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.95.19568.1CB757B5; Thu, 16 Aug 2018 09:27:30 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w7GDRMBV015124; Thu, 16 Aug 2018 09:27:23 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7GDRGIp003786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Aug 2018 09:27:19 -0400
Date: Thu, 16 Aug 2018 08:27:16 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, "Arun Arunachalam (carunach)" <carunach=40cisco.com@dmarc.ietf.org>, "Arun Arunachalam (carunach)" <carunach@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>
Message-ID: <20180816132715.GD40887@kduck.kaduk.org>
References: <153417744610.24989.8583018232862453031.idtracker@ietfa.amsl.com> <47069B3D-25CE-409F-9099-E235D656C498@cisco.com> <a7811c35-2843-1b8b-1862-4fe7e0abe69a@kuehlewind.net> <CBE69AF1-8AFC-4FC2-898A-0D70B96BE009@cisco.com> <4EA01E28-6DEB-4B6F-861F-E2C753E37541@kuehlewind.net> <AM5PR0501MB24654C915AD02EC5CDE97233973F0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM5PR0501MB24654C915AD02EC5CDE97233973F0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsUixG6nonuoujTa4MFvdovtx1cxWTQ+mMZu sf/SHEaLuVP8LGb8mchs8eL6R2aLR49+MFnMv/+MyaLv5RcmB06PKb83snqcWHaF1WPJkp9M Hi0fF7J69M1YzxjAGsVlk5Kak1mWWqRvl8CVce/qLtaCfdoV9z/vYGlgnK/UxcjJISFgIrF7 /3G2LkYuDiGBxUwSzT+fsYMkhAQ2Mkq0/kyGSFxlkti0/wkLSIJFQFXi9tqDrCA2m4CKREP3 ZeYuRg4OEQFbid1ngkDqmQWeMUvsvN/IDuIIC8xllNixr5cZpIEXaN2+R7uh1v1iktj7eior REJQ4uRMiA3MAuoSf+ZdApvKLCAtsfwfB0RYXqJ562ywOZwCiRJ7Z0PMFBVQltjbd4h9AqPg LCSTZiGZNAth0iwkkxYwsqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIjh0X pR2ME/95HWIU4GBU4uF9YFgSLcSaWFZcmXuIUZKDSUmUV7+6OFqILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCK97SWm0EG9KYmVValE+TEqag0VJnPd+TXi0kEB6YklqdmpqQWoRTFaGg0NJgte2 CqhRsCg1PbUiLTOnBCHNxMEJMpwHaPijSpDhxQWJucWZ6RD5U4y6HH/eT53ELMSSl5+XKiXO exOkSACkKKM0D24OKOVJZO+vecUoDvSWMO98kHU8wHQJN+kV0BImoCXTBMCWlCQipKQaGIWY dVTbTW66r+DgmWFv5n7n4tGMFSHHq5dWHrM6eOYNa8jEf8tD79+zr+6S81B6sOVrLvOcI9t7 llbP3Z288s7n1Q0/nkcsNGb7wunud6Tmkpmz03KPms+1cmumqFk+3ca1WeGbyeUnpUsPLVf8 xa54UK9d8r/PCrEShYn8nEmrGF07z99fe0mJpTgj0VCLuag4EQCiHDFUVAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/BtDnrZPBdz4yZbarumuNoAVFjVE>
Subject: Re: [Insipid] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_d?= =?iso-8859-1?q?raft-ietf-insipid-logme-marking-12=3A_=28with_COMMENT=29?=
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 13:32:35 -0000

Sorry to jump in with something only semi-related...

On Wed, Aug 15, 2018 at 02:57:44PM +0000, Dawes, Peter, Vodafone Group wrote:
> Hi Mirja,
> Please find some further proposals trying to resolve your comments in-line below. Thanks again for your review.
> 
> Regards,
> Peter
> 
> > -----Original Message-----
> > From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
> > Sent: 15 August 2018 08:32
> > To: Arun Arunachalam (carunach) <carunach=40cisco.com@dmarc.ietf.org>;
> > Cc: Arun Arunachalam (carunach) <carunach@cisco.com>;; insipid-
> > chairs@ietf.org; Dawes, Peter, Vodafone Group
> > <Peter.Dawes@vodafone.com>;; Gonzalo Salgueiro (gsalguei)
> > <gsalguei@cisco.com>;; insipid@ietf.org; The IESG <iesg@ietf.org>;; draft-
> > ietf-insipid-logme-marking@ietf.org
> > Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-
> > marking-12: (with COMMENT)
> >
> >
> > > Am 15.08.2018 um 00:13 schrieb Arun Arunachalam (carunach)
> > <carunach=40cisco.com@dmarc.ietf.org>;:
> > >
> > >> On Aug 14, 2018, at 12:47 PM, Mirja Kühlewind <ietf@kuehlewind.net>;
> > >>
> > >> On 14.08.2018 16:51, Arun Arunachalam (carunach) wrote:
> > >>>
> > >>>> On Aug 13, 2018, at 12:24 PM, Mirja Kühlewind <ietf@kuehlewind.net>;
> > wrote:
> > >>>>
> > >>>>
> > >>>> 3) Section 4.6 feels a little misplace but I not sure where it
> > >>>> belong otherwise (maybe section 3 or 5?). Or maybe move section 4.5
> > >>>> in an own section later in the doc…?
> > >>>
> > >>>
> > >>> We added "4.6 Error Handling” under Section 4 since this section talks
> > about endpoint and intermediary behavior. Error handling needs to be
> > implemented in SIP entities, and we could reword the beginning of 4.6. to:
> > "The two error types that SIP entities must handle are defined in Section 5, a
> > missing marker error and an error of "log me" marking that begins mid-
> > dialog."
> > >>>
> > >>> Or if needed, we could move it as first part of Section 5 and rename this
> > section as "5. Error Handling” and make “5.1 Error cases” as a sub-section.
> > >> I'd prefer this solution. But it's just an editorial comment, so I leave it to
> > you.
> > >
> > >
> > > We plan to move it to Section 5.
> > >
> > >
> > >>
> > >>>
> > >>> Please let us know your preference.
> > >>>
> > >>>>
> > >>>> 4) Also Section 4.6: "It MUST NOT forward the "log me" marker"
> > >>>> Does it mean an intermediate MUST remove the marker if an error is
> > >>>> detected? Is that safe given the proxy scenarios? If at all I would
> > >>>> recommend to use MAY here, I guess…
> > >>>
> > >>> If the proxy is logme aware then it is expected to remove logme marker
> > in error scenarios. It is safe to remove. The objective is to stop the
> > propagation of incorrect marking as soon as possible.
> > >>
> > >> I have the feeling that this could be more explicitly spelled out in the doc
> > and maybe also providing further guidance when it is actually safe to remove
> > a marking would be really good.
> > >
> > >
> > > The situations when “log me” marking can be safely removed is discussed
> > in Section 8.2 "Log Me" Marker Removal” and in Section 8.3 “Denial of Service
> > Attacks". Please let us know whether these sections address your comment
> > (or) whether we are missing something specific.
> > >
> > These sections only discuss the case of inter-domain traffic. My question was
> > should an intermediate that understands logme also remove markings in
> > error cases (markings show up mitdterm or something)? Maybe you can say
> > something more in section 5 or 4.6.
> >
> 
> We can further clarify Section 4.6 (which will be moved to within Section 5) as below. This section specifies error handling by both UAs and intermediaries.
> 
> 4.6.  Error Handling
> 
>    Two error types are defined in Section 5, a missing marker error and
>    an error of "log me" marking that begins mid-dialog.  Section 6 gives
>    exceptions which have a missing marker or marking that begins mid-
>    dialog but are not errors.
> 
>    If a missing marker error is detected by a “log me” aware UA, SIP intermediary,
>    it SHOULD consider this as an error condition.  It MUST NOT
>    mark subsequent requests and responses and MUST stop logging messages
>    in the same dialog.  Any previously logged messages SHOULD be
>    retained and not deleted.
> 
>    If a "log me" marking that begins mid-dialog error is detected by a
>     “log me” aware UA, SIP intermediary, it SHOULD consider this as an error
>    condition.  A UA MUST ignore the “log me” marker, SIP intermediaries MUST
>    remove the "log me" marker from the Session-ID
>    header prior to forwarding the message to the next hop and the received message
>    MUST NOT be logged.  It MUST NOT mark subsequent requests and responses and
>    MUST NOT log subsequent messages in the same dialog.

I expect this is just my communications security background speaking, but
I'm used to seeing "this is an error condition" get a response of "tear
down the entire connection/dialog/whatever".  That doesn't seem to be the
case, here, though -- is the appropriate response to the error condition
just the behavior described in the document of ceasing to use "log me"
markers and stopping logging?  It may be more clear to explicitly say
"error condition in the "log me" functionality" to avoid the misreading
that it is a broader error condition of the entire dialog.

-Benjamin