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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hello Benjamin,

Below is the proposed resolution to your comment regarding error cases, which will be in version -13 of the draft.


Thanks!

Peter and Arun


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



We have revised the text in 5.3 to make it clear that the errors are “log me” errors and not errors with the session itself as follows.



5.3.  Error Handling



   The two error types that SIP entities must handle are defined in

   Section 5.1, a missing marker error and an error of "log me" marking

   that begins mid-dialog.  Section 5.2 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 UA, SIP intermediary, or

   B2BUA, it SHOULD consider this as an error condition in the "log me"

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

   UA, SIP intermediary, or B2BUA, it SHOULD consider this as an error

   condition in the "log me" functionality.  It MUST NOT forward the

   "log me" marker and MUST NOT log the message.  It MUST NOT mark

   subsequent requests and responses and MUST NOT log subsequent

   messages in the same dialog.



   "Log me" marking errors can be detected and handled only by

   supporting UAs or B2BUAs.  A SIP proxy as defined in [RFC3261] cannot

   detect or handle marking errors and will simply forward any "log me"

   marker it receives.



>

>-Benjamin



________________________________
From: Benjamin Kaduk <[e-mail]>
Sent: 16 August 2018 14:27
To: Dawes, Peter, Vodafone Group
Cc: Mirja Kuehlewind (IETF); Arun Arunachalam (carunach); Arun Arunachalam (carunach); [e-mail]; Gonzalo Salgueiro (gsalguei); [e-mail]; The IESG; [e-mail]
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

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) <[e-mail]>
> > Sent: 15 August 2018 08:32
> > To: Arun Arunachalam (carunach) <carunach=[e-mail]>
> > Cc: Arun Arunachalam (carunach) <[e-mail]>; insipid-
> > [e-mail]; Dawes, Peter, Vodafone Group
> > <[e-mail]>; Gonzalo Salgueiro (gsalguei)
> > <[e-mail]>; [e-mail]; The IESG <[e-mail]>; draft-
> > [e-mail]
> > 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=[e-mail]>:
> > >
> > >> On Aug 14, 2018, at 12:47 PM, Mirja Kühlewind <[e-mail]>
> > >>
> > >> On 14.08.2018 16:51, Arun Arunachalam (carunach) wrote:
> > >>>
> > >>>> On Aug 13, 2018, at 12:24 PM, Mirja Kühlewind <[e-mail]>
> > 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