Genart LC review: draft-ietf-insipid-logme-reqs-11

Stewart Bryant <stewart.bryant@gmail.com> Tue, 03 January 2017 15:03 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092A41295F3; Tue, 3 Jan 2017 07:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nHQLW-hHRX6P; Tue, 3 Jan 2017 07:03:17 -0800 (PST)
Received: from mail-wj0-x22d.google.com (mail-wj0-x22d.google.com [IPv6:2a00:1450:400c:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE099129496; Tue, 3 Jan 2017 07:03:13 -0800 (PST)
Received: by mail-wj0-x22d.google.com with SMTP id sd9so262102300wjb.1; Tue, 03 Jan 2017 07:03:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=H8bntGtI/3J7B6qQpjdyg/g3wkal5Ukk1smKYXqvhSo=; b=Muj2VgXwO6SyiCXHZ2f0yDd/dU7sNe8xspeJQchCa1H4IO51Ca0FNQRJBLNY538Soo ShKVJs6GLa25JcIIl8k6BztrfNNJ85xnFlUTT8RPXoPPGZTqiaSxmiwT91Brl2b1vffj YhFdDVXapEo7z2G88qGB3+LC9Z39O3Uvx/QDBxyxZ38lrRtSwSbniHqjCrev+jbAe8Oj 8wq+S0mCcvvft4ijLnnb7PPBZRAkiLy5NAgdUSBD/2dttZn4nyC8qT+sF3jcDZgZEPSP TkGhQmhh8MAzmBiQKjx9MJFMst+15X6zxX/srgMqCeybbpb6ch8HcKEMRdFHJwAPXMkW Rtog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=H8bntGtI/3J7B6qQpjdyg/g3wkal5Ukk1smKYXqvhSo=; b=RjGSiQs3e3Std4GHuX2JkbXNA1ivy4RHHXbBAJrbuDaxPwHn40J+IbSYEOfFLz7xEw PVFE9PIAe34Xwc5Msbnw2xiNAcI2Tf5rCHSIo8FRx2f80opOiPm357EM0sue8GUf6Kr/ dwUOxDoqkTq7kkZQkMVtgYJkYSMnybwRJDSeS1quSoAIV/MmgP4C5mxUxaAthHTC96kf 96lIlKIwc0p9iPZ0VoCEdwgz7oBzIMSu2EhjJPJuh7klCo5z1bEeLoMyV86YnkvuV6PC docWh5DUC6RPafUdlhxzXwWSJcijghHTt6O1z90KaveEcYPtzLkmFiS7OfefWsJq3kBf IpOQ==
X-Gm-Message-State: AIkVDXIsqE1TenPMs+gnLSdc3JXol/61+0P/nm1Uq1s3XE7XNSflto3LVNocvmixEQtdmw==
X-Received: by 10.194.105.228 with SMTP id gp4mr52148258wjb.208.1483455791876; Tue, 03 Jan 2017 07:03:11 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ba10sm93368816wjb.32.2017.01.03.07.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 07:03:11 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
To: draft-ietf-insipid-logme-reqs@ietf.org, General Area Review Team <gen-art@ietf.org>, IETF Discussion <ietf@ietf.org>, insipid@ietf.org
Subject: Genart LC review: draft-ietf-insipid-logme-reqs-11
Message-ID: <fe8b1273-8f3e-8590-4823-9c56cf62f4ad@gmail.com>
Date: Tue, 3 Jan 2017 15:03:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/iir3IuVFSzeROkHuEzKIKdXkuEA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 15:03:19 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.

Document: draft-ietf-insipid-logme-reqs-11
Reviewer: Stewart Bryant
Review Date: 2017-01-03
IETF LC End Date: 2017-01-13
IESG Telechat date: unknown

Summary: Ready with minor issue

This is a well written document that describes a useful feature in
its intended purpose. However I could not help but think that it has
an inevitable alternate use in the observation of users. There is
guidance on how to prevent this, but that seems easily ignored. Thus
the guidance from Security Area review will be of particular importance.

Major issues:

None.

Minor issues:

6.1.  Trust Domain

    Since a "log me" marker may cause a SIP entity to log the SIP header
    and body of a request or response, the "log me" marker SHOULD be
    removed at a trust domain boundary.


SB> I am not convinced that SHOULD is strong enough given that the traffic
SB> is leaving the trust domain.

Nits/editorial comments:


3.1.  Network Boundary

    Figure 2 shows a network boundary between GW-A1
    in operator A's network and the SBC in operator B's network.  A

SB> SBC needs expanding on first use.

===================

    [RFC5853] gives examples of manipulating signaling to prevent the
    sending network passing on sensitive information, for example
    topology hiding, or the receiving network protecting itself from
    signaling that is not under its control, for example protocol repair.

SB> The last sentence does not scan well.

===================

    o  REQ9: The "log me" marker mechanism SHOULD allow a SIP
       intermediary to request logging SIP requests and responses on
       behalf of the originating endpoint.  The typical use case for this
       requirement is for compatibility with UAs that have not

SB> UA needs expanding on first use.