Subject: [Insipid] Alexey Melnikov's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Mon, 10 Sep 2018 07:52:59 +0000

Hello Alexej,

Thanks a lot for reviewing the draft, please find responses and proposed resolutions inline below.

Best regards,

Peter and Arun

>From:      Alexey Melnikov <[email-masked]>

>Sent:      16 August 2018 14:34

>To:  The IESG

>Cc:  [email-masked]; [email-masked];

>[email-masked]; [email-masked]

>Subject:   Alexey Melnikov's No Objection on draft-ietf-insipid-logme-

>marking-12: (with COMMENT)

>Alexey Melnikov has entered the following ballot position for

>draft-ietf-insipid-logme-marking-12: No Objection

>When responding, please keep the subject line intact and reply to all email addresses included in the To

>and CC lines. (Feel free to cut this introductory paragraph, however.)

>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

>for more information about IESG DISCUSS and COMMENT positions.

>The document, along with other ballot positions, can be found here:

>https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/

>----------------------------------------------------------------------

>COMMENT:

>----------------------------------------------------------------------

>Similar to Benjamin, I am uneasy about this document and dual use of this mechanism. I think the advice

>it gives for an attacker is to inject the "log me" attribute at the beginning of a session that is of interest,

>closer to the originator ;-).

We have tried to prevent misuse for example by including the protocol safeguards described in 4.1 Scope of Marking, the need for authorization in 7.1, and the user control described in 8.6. If an attacker injects marking, this should be removed by the network, or ignored by non-supporting entities. Also the user will see that troubleshooting/testing is happening.

>Also one small nit:

>In Section 1:

>   This document defines a new header field parameter "logme" for the

>   "Session-ID" header field [RFC7989].  Implementations of this

>   document MUST implement session identity.

>Is "session identity" defined in RFC 7989? RFC 7989 doesn't use the term "session identity" anywhere. If

>you mean that in order to support this extension one needs to implement support for the Session-ID

>header field I suggest you rephrase the 2nd sentence to say something like this:

>   Implementations of this document MUST implement [RFC7989].

Revised the final paragraph Section 1 Introduction as follows as per the comment.

   This document defines a new header field parameter "logme" for the

   "Session-ID" header field [RFC7989].  Implementations of this

   document MUST implement [RFC7989].