From nobody Tue Jan 3 07:03:21 2017 Return-Path: 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 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 To: draft-ietf-insipid-logme-reqs@ietf.org, General Area Review Team , IETF Discussion , insipid@ietf.org Message-ID: 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: Subject: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . 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. From nobody Tue Jan 3 07:11:45 2017 Return-Path: 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 CC61412960D; Tue, 3 Jan 2017 07:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 3GIlm7H5Bepd; Tue, 3 Jan 2017 07:11:37 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 6B614129617; Tue, 3 Jan 2017 07:11:37 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id c85so201572985wmi.1; Tue, 03 Jan 2017 07:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=H8bntGtI/3J7B6qQpjdyg/g3wkal5Ukk1smKYXqvhSo=; b=MbBN9nQFRBxhXVAxSKfb7wCjdf+oaYm2WbmTvWWSbEASCkKbTnl4/VxJIDmGjYtis7 dHOK4FEkiL8LMsJ7q4mdYJmy2hmtagVw8BpOu7swlJIvDa4k5HlxgbScttnqOjTWnM+t RS4wVX3kNibJscm1c3R5Zds50cUM4xWd69ldiMqbFUdrJkBRKccF1zniamzkh3vEv+Hv tXA2I2xBNoliLqizJxOl6sf6RaMQ5L893Y1mzroLXvWNHbmxvXFiNHTJgYTiKnb8e/a0 vlH9DOFl8zgMKLC56hQLNeNNfKiFuJckTOEq8NRYBYwDZY12+BcGKx4rDldx+d8QQdaU 565Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=H8bntGtI/3J7B6qQpjdyg/g3wkal5Ukk1smKYXqvhSo=; b=Rtq7gfgekxV7b1PH4PWGDS7UE6+C5YpLaO39IbZxbWCudX1Za4JkYLvRMylG06aMsf /aTRs2JsKSc5Izn/CE9BTzS+jqiXBwXQsLoHX4lvIos+tQyvJpmacrUvJWyiES+m5a3B hNTvGvlpf4kQY7VpZhMGFDGx5xK5XDTG6dPKpBliku3hj7gLPZ/l4Xxqgv+Xj0n0sfA2 5KsPI/J828OS0SsFv90U3TCNlNw1SZ4aoHShAFhCuVO8QYf/6tpT5hUmw++v7lyB0Y2k Ml4yt/MBFQ9yurPabIUhA8HrBS9YsXStf9TD9+BKT/Vt6cMNuTn3RBuF++omB2oDw/2k EoOQ== X-Gm-Message-State: AIkVDXLYrN2XTUIstwKGg+kYLCL+HI1MHQj6lbTGXMjOWw0/LmCMm0meCKaZtrb9quMKcg== X-Received: by 10.28.69.17 with SMTP id s17mr55637008wma.141.1483456295646; Tue, 03 Jan 2017 07:11:35 -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 o3sm93552074wjx.39.2017.01.03.07.11.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 07:11:35 -0800 (PST) From: Stewart Bryant To: draft-ietf-insipid-logme-reqs@ietf.org, General Area Review Team , IETF Discussion , insipid@ietf.org Message-ID: <4d11bb6c-c286-0e56-282a-4003fc518eab@gmail.com> Date: Tue, 3 Jan 2017 15:11:32 +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: Subject: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 15:11:40 -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 . 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. From nobody Wed Jan 4 09:53:21 2017 Return-Path: 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 EEDCF1296A2; Wed, 4 Jan 2017 09:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 l3A6CAwhAtIx; Wed, 4 Jan 2017 09:53:11 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2581012969F; Wed, 4 Jan 2017 09:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4360; q=dns/txt; s=iport; t=1483552391; x=1484761991; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dNG+LhD5OiOIo8EsJezX/YOt8LM7hj+ZR5Di2Za0u2c=; b=RV7AOgH/HNNypuAaRPz1xRMMJhJBWDFBiGkz2+9ZeOUKf5zvRGusiuOX RwJ9HCULtzNsy60WHZnf6M4DDKbh5NFhN1ph70XOp2uzUwrx7FDBz77OK bR5/gRMlZaE3iQ+wnFvC8z+ikm0N1IGMvIMCjwQDRW6XuLGKmdVcqkJqL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBTNm1Y/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAR9fgQwHjVCUR4d+jSSCCB8LhS5KAhqBPD8UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaAEBAQMBAQEhEToLBQsCAQYCFAQCAiYCAgIfBgsVEAIEDgWIVQMQC?= =?us-ascii?q?A6ReJ1NgiWHPw2CXQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHPIJfgk6EfS2?= =?us-ascii?q?CMQWaUTgBhlWGcYN6gXaFCIlbiXWISgEfOIErLg4BhVRyhyWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,459,1477958400"; d="scan'208";a="188400189" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 17:53:03 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v04Hr3ul003527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jan 2017 17:53:03 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 4 Jan 2017 11:53:02 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 4 Jan 2017 11:53:02 -0600 From: "Arun Arunachalam (carunach)" To: Stewart Bryant Thread-Topic: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSZdOzWxg3IqmLzEyw43rvylRZSaEo/7YA Date: Wed, 4 Jan 2017 17:53:02 +0000 Message-ID: <16B3F47D-2E14-4F2A-B99B-CF309474DB20@cisco.com> References: <4d11bb6c-c286-0e56-282a-4003fc518eab@gmail.com> In-Reply-To: <4d11bb6c-c286-0e56-282a-4003fc518eab@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.0] Content-Type: text/plain; charset="utf-8" Content-ID: <2750847D1597944992A6F480452EE92C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: General Area Review Team , "Arun Arunachalam \(carunach\)" , "insipid@ietf.org" , IETF Discussion , "draft-ietf-insipid-logme-reqs@ietf.org" Subject: Re: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:53:13 -0000 SGkgU3Rld2FydCwNCg0KVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3ICENCg0K UGxlYXNlIHNlZSBpbmxpbmUgYW5kIGxldCB1cyBrbm93IHlvdXIgaW5wdXQuDQoNCg0KPiBPbiBK YW4gMywgMjAxNywgYXQgMTA6MTEgQU0sIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBn bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdl ciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYQ0KPiBSZXZpZXcgVGVhbSAoR2VuLUFS VCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQo+IGJ5IHRoZSBJ RVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IEZvciBtb3JlIGlu Zm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gDQo+IDxodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lg0KPiANCj4gRG9jdW1lbnQ6IGRyYWZ0LWll dGYtaW5zaXBpZC1sb2dtZS1yZXFzLTExDQo+IFJldmlld2VyOiBTdGV3YXJ0IEJyeWFudA0KPiBS ZXZpZXcgRGF0ZTogMjAxNy0wMS0wMw0KPiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTAxLTEzDQo+ IElFU0cgVGVsZWNoYXQgZGF0ZTogdW5rbm93bg0KPiANCj4gU3VtbWFyeTogUmVhZHkgd2l0aCBt aW5vciBpc3N1ZQ0KPiANCj4gVGhpcyBpcyBhIHdlbGwgd3JpdHRlbiBkb2N1bWVudCB0aGF0IGRl c2NyaWJlcyBhIHVzZWZ1bCBmZWF0dXJlIGluDQo+IGl0cyBpbnRlbmRlZCBwdXJwb3NlLiBIb3dl dmVyIEkgY291bGQgbm90IGhlbHAgYnV0IHRoaW5rIHRoYXQgaXQgaGFzDQo+IGFuIGluZXZpdGFi bGUgYWx0ZXJuYXRlIHVzZSBpbiB0aGUgb2JzZXJ2YXRpb24gb2YgdXNlcnMuIFRoZXJlIGlzDQo+ IGd1aWRhbmNlIG9uIGhvdyB0byBwcmV2ZW50IHRoaXMsIGJ1dCB0aGF0IHNlZW1zIGVhc2lseSBp Z25vcmVkLiBUaHVzDQo+IHRoZSBndWlkYW5jZSBmcm9tIFNlY3VyaXR5IEFyZWEgcmV2aWV3IHdp bGwgYmUgb2YgcGFydGljdWxhciBpbXBvcnRhbmNlLg0KPiANCj4gTWFqb3IgaXNzdWVzOg0KPiAN Cj4gTm9uZS4NCj4gDQo+IE1pbm9yIGlzc3VlczoNCj4gDQo+IDYuMS4gIFRydXN0IERvbWFpbg0K PiANCj4gICBTaW5jZSBhICJsb2cgbWUiIG1hcmtlciBtYXkgY2F1c2UgYSBTSVAgZW50aXR5IHRv IGxvZyB0aGUgU0lQIGhlYWRlcg0KPiAgIGFuZCBib2R5IG9mIGEgcmVxdWVzdCBvciByZXNwb25z ZSwgdGhlICJsb2cgbWUiIG1hcmtlciBTSE9VTEQgYmUNCj4gICByZW1vdmVkIGF0IGEgdHJ1c3Qg ZG9tYWluIGJvdW5kYXJ5Lg0KPiANCj4gDQo+IFNCPiBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCBT SE9VTEQgaXMgc3Ryb25nIGVub3VnaCBnaXZlbiB0aGF0IHRoZSB0cmFmZmljDQo+IFNCPiBpcyBs ZWF2aW5nIHRoZSB0cnVzdCBkb21haW4uDQoNCldlIGNhbiBjaGFuZ2UgZnJvbSBTSE9VTEQgdG8g TVVTVC4NCg0KDQoNCj4gDQo+IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0KPiANCj4gDQo+IDMu MS4gIE5ldHdvcmsgQm91bmRhcnkNCj4gDQo+ICAgRmlndXJlIDIgc2hvd3MgYSBuZXR3b3JrIGJv dW5kYXJ5IGJldHdlZW4gR1ctQTENCj4gICBpbiBvcGVyYXRvciBBJ3MgbmV0d29yayBhbmQgdGhl IFNCQyBpbiBvcGVyYXRvciBCJ3MgbmV0d29yay4gIEENCj4gDQo+IFNCPiBTQkMgbmVlZHMgZXhw YW5kaW5nIG9uIGZpcnN0IHVzZS4NCg0KDQpXZSB3aWxsIGNoYW5nZSBpdCB0byDigJzigKZhbmQg dGhlIFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIgKFNCQynigKbigJ0uDQoNCj4gDQo+ID09PT09 PT09PT09PT09PT09PT0NCj4gDQo+ICAgW1JGQzU4NTNdIGdpdmVzIGV4YW1wbGVzIG9mIG1hbmlw dWxhdGluZyBzaWduYWxpbmcgdG8gcHJldmVudCB0aGUNCj4gICBzZW5kaW5nIG5ldHdvcmsgcGFz c2luZyBvbiBzZW5zaXRpdmUgaW5mb3JtYXRpb24sIGZvciBleGFtcGxlDQo+ICAgdG9wb2xvZ3kg aGlkaW5nLCBvciB0aGUgcmVjZWl2aW5nIG5ldHdvcmsgcHJvdGVjdGluZyBpdHNlbGYgZnJvbQ0K PiAgIHNpZ25hbGluZyB0aGF0IGlzIG5vdCB1bmRlciBpdHMgY29udHJvbCwgZm9yIGV4YW1wbGUg cHJvdG9jb2wgcmVwYWlyLg0KPiANCj4gU0I+IFRoZSBsYXN0IHNlbnRlbmNlIGRvZXMgbm90IHNj YW4gd2VsbC4NCg0KDQpXZSBjYW4gcmV3cml0ZSB0aGlzIHBhcmFncmFwaCBhcyBmb2xsb3dzOg0K ICAgDQogICBUb3BvbG9neSBoaWRpbmcgYW5kIHByb3RvY29sIHJlcGFpciAoc2VlIFtSRkM1ODUz XSkgYXJlIHR3byBjb21tb24gDQogICBmdW5jdGlvbnMgdGhhdCBtYW5pcHVsYXRlIHNpZ25hbGlu ZyBhdCB0aGUgbmV0d29yayBib3VuZGFyeS4gVGhlc2UgDQogICBmdW5jdGlvbnMgYXJlIHBlcmZv cm1lZCBieSBTSVAgZGV2aWNlIHR5cGVzICAoc2VlIFtSRkM3MDkyXSkgc3VjaCBhcw0KICAgU2Vz c2lvbiBCb3JkZXIgQ29udHJvbGxlciBhbmQgSW50ZXJjb25uZWN0aW9uIEJvcmRlciBDb250cm9s IEZ1bmN0aW9uIChJQkNGKS4NCiAgDQoNCj4gDQo+ID09PT09PT09PT09PT09PT09PT0NCj4gDQo+ ICAgbyAgUkVROTogVGhlICJsb2cgbWUiIG1hcmtlciBtZWNoYW5pc20gU0hPVUxEIGFsbG93IGEg U0lQDQo+ICAgICAgaW50ZXJtZWRpYXJ5IHRvIHJlcXVlc3QgbG9nZ2luZyBTSVAgcmVxdWVzdHMg YW5kIHJlc3BvbnNlcyBvbg0KPiAgICAgIGJlaGFsZiBvZiB0aGUgb3JpZ2luYXRpbmcgZW5kcG9p bnQuICBUaGUgdHlwaWNhbCB1c2UgY2FzZSBmb3IgdGhpcw0KPiAgICAgIHJlcXVpcmVtZW50IGlz IGZvciBjb21wYXRpYmlsaXR5IHdpdGggVUFzIHRoYXQgaGF2ZSBub3QNCj4gDQo+IFNCPiBVQSBu ZWVkcyBleHBhbmRpbmcgb24gZmlyc3QgdXNlLg0KDQpXZSB3aWxsIGNoYW5nZSBpdCB0byDigJzi gKYud2l0aCBVc2VyIEFnZW50cyAoVUEpIHRoYXQgaGF2ZSBub3Qg4oCmIg0KDQpUaGFua3MhDQpB cnVuDQoNCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gaW5zaXBpZEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQNCg0K From nobody Wed Jan 4 11:29:54 2017 Return-Path: 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 AFEDF129441; Wed, 4 Jan 2017 11:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 LEK1P19ZEz3c; Wed, 4 Jan 2017 11:29:47 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 2BB731200A0; Wed, 4 Jan 2017 11:29:47 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id k184so269721572wme.1; Wed, 04 Jan 2017 11:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2ETFgXZxUWYzKyrRZnGlf2MiW+5c8SWi2zzH2ZkeRb0=; b=PStF29rxng/iUrYPRW8oB/gZ5EpHfyO3FDVV2CMwH/mjXWx0wf7+ZHf+rXyKLW5qF8 qbdhok/ucFUPS9Rx9nn4mewfcK4eqXfwZZrihHOMEhx3KwfH+c7z8OdNBcnsQk6ogns4 pEywfCoaQlXQDSCr/kUYt9Vx6xjPXBtGnHH3chZC+34j5adOVLmaHZg+ZhaQf8e1Hoeh bHYsMB9iWrSn3WntjDEaydsQ0arJ3zg6AWBTyXL75tMKDUU1/P6o323bVD13P73hxY18 NrHNAGZndN6Quz3aM7bpR/gn6XyMkyrJxGUomK247ZOCmm8k41tLQCqWISNjtn1TUuNv KlbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2ETFgXZxUWYzKyrRZnGlf2MiW+5c8SWi2zzH2ZkeRb0=; b=obJjxbjQYFerlDqw08vAe93fvOewPLggoXDCTNQRUCVglCG0Q/lucDswFPeVhIlz8Z wWARvc3UX57Ujak/jvsrjad+v2Iw9xiy4IuIOgIZAxbWYnsMSabGBOTV25GkrOg5uX/x HjV95hSqiCu/ALGAEaaq3raNHRZUckk6pJra4iO8qqPGWwH6lfSv5SLb3rjcYJ+u/K4g jqj6mVl/IU5oS/5UDP9OG3//QHB2QeCZ6ac4ITim2lfNrHH+2/Bx3OsB301NumKiuLVE eChZJ2DvRqmiE5J39vPbICv51zJs9LQ+NvXSR3wleFQ7Q4MEYiaQr2B5i5+WnlT81prK AQHg== X-Gm-Message-State: AIkVDXJ1id1QLXyvzNt979F+QltZVcLnkNnt/zSxHNaEFESrmzfIs6MjfLh5wfaq8ePk8w== X-Received: by 10.28.135.5 with SMTP id j5mr63666339wmd.3.1483558185426; Wed, 04 Jan 2017 11:29:45 -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 uz7sm5312201wjc.11.2017.01.04.11.29.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 11:29:44 -0800 (PST) To: "Arun Arunachalam (carunach)" References: <4d11bb6c-c286-0e56-282a-4003fc518eab@gmail.com> <16B3F47D-2E14-4F2A-B99B-CF309474DB20@cisco.com> From: Stewart Bryant Message-ID: <949f78f9-f08e-62c2-5be0-e1fe6e981656@gmail.com> Date: Wed, 4 Jan 2017 19:29:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <16B3F47D-2E14-4F2A-B99B-CF309474DB20@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: General Area Review Team , "insipid@ietf.org" , IETF Discussion , "draft-ietf-insipid-logme-reqs@ietf.org" Subject: Re: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:29:51 -0000 Hi Arun Those changes look good to me. Thanks Stewart On 04/01/2017 17:53, Arun Arunachalam (carunach) wrote: > Hi Stewart, > > Thanks for taking the time to review ! > > Please see inline and let us know your input. > > >> On Jan 3, 2017, at 10:11 AM, Stewart Bryant wrote: >> >> 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 >> >> . >> >> 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. > We can change from SHOULD to MUST. > > > >> 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. > > We will change it to “…and the Session Border Controller (SBC)…”. > >> =================== >> >> [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. > > We can rewrite this paragraph as follows: > > Topology hiding and protocol repair (see [RFC5853]) are two common > functions that manipulate signaling at the network boundary. These > functions are performed by SIP device types (see [RFC7092]) such as > Session Border Controller and Interconnection Border Control Function (IBCF). > > >> =================== >> >> 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. > We will change it to “….with User Agents (UA) that have not …" > > Thanks! > Arun > >> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid From nobody Fri Jan 6 18:56:43 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2B1270B4; Fri, 6 Jan 2017 18:56:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 18:56:33 -0800 Archived-At: Cc: insipid@ietf.org, ietf@ietf.org, draft-ietf-insipid-logme-reqs.all@ietf.org Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 02:56:34 -0000 Reviewer: Sean Turner Review result: Has Nits After getting over my initial reaction that was something like "srsly!? we're going to standardize the exact opposite of 'do not track'", I realized that this is a requirements draft for an IETF approved WG and a chartered work item of that WG :) 0) s3.2: Is the intent to define a protocol mechanism to determine if the two or domains are part of the same trust domain? This requirement could be achieved by saying out-of-band bilateral agreements are the mechanism to establish the domain. 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"? Is there another logging format other than SIP CLF? 2) s5.1: Should the must be MUST in the following: All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator. 3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing? I mean if SIP doesn't allow adding new headers then didn't somebody sink your battleship? But SIP does allow you to add arbitrary headers so I think I'm missing something as to why this is needed? 4) s5.2: REQ3 - Reads a bit awkward to me how about: It MUST be possible to mark a SIP request or response for logging by inserting a "log me" marker. i.e., remove "of interest" 5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there fields that SIP requires be stripped? 6) Is there a missing requirement based on the security considerations that requires the this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted? From nobody Tue Jan 10 06:51:37 2017 Return-Path: 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 E39DE1294EE; Tue, 10 Jan 2017 06:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham 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 xApgLQtx8Hxf; Tue, 10 Jan 2017 06:51:25 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) (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 22425129422; Tue, 10 Jan 2017 06:51:21 -0800 (PST) Received: from [195.245.230.51] by server-8.bemta-3.messagelabs.com id 76/E9-31649-8E4F4785; Tue, 10 Jan 2017 14:51:20 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRWlGSWpSXmKPExsWi75nTqfv8S0m Ewb8VOhYLb0VYPNs4n8Vi/v1nTBZXVjUyW3xY+JDFgdVjyZKfTB4HDzIGMEWxZuYl5VcksGZs n3+VtWCxZsWGJzOZGxgfKHYxcnEICWxnlJi1ZTEThHOYUWLa+8NQziZGie2rr7N1MXJwsAnYS 8zYE9PFyMkhIuAqcWDvEWaQGmaB5YwSfxoa2EASwgKOEruPHGaBKHKSWHRkGzuEbSTRtWE1K4 jNIqAq8fHjTEYQm1cgVOLU1Q1gcSEBX4nLlxaA1XMK+EnserYSzGYUkJX40riaGcRmFhCXuPV kPhOILSEgILFkz3lmCFtU4uXjf6wQNToSC3Z/YoOwtSWWLXzNDLFLUOLkzCcsELtUJf6tXMQ0 gVF0FpKxs5C0z0LSPgtJ+wJGllWM6sWpRWWpRbqmeklFmekZJbmJmTm6hgbGermpxcWJ6ak5i UnFesn5uZsYgfFVz8DAuIPx8lenQ4ySHExKorzLPpdECPEl5adUZiQWZ8QXleakFh9ilOHgUJ LgZQXGq5BgUWp6akVaZg4w0mHSEhw8SiK8HCBp3uKCxNzizHSI1ClGRSlx3m8gMwVAEhmleXB tsORyiVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5IwLx/IeJ7MvBK46a+AFjMBLY60KwZZXJKI kJJqYOxa5JBu9LBhaazoPbN7L1du7RMWzu66Waz5gE3tpdOc8x6znfknf5bhfvvO/cYa3UVsL QvvB2x16uw8viVc4Kfc1089jtkSpYZ8h7Y78vyJ8Lya2me0RkBycWjAv5tO6hHNN7Z/eJ9ZXR C+2SYm1zj4f6v/Za3JglnLjdTvpTlmmGiHeOlKK7EUZyQaajEXFScCAFpVWsQpAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-11.tower-33.messagelabs.com!1484059879!83783586!1 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20516 invoked from network); 10 Jan 2017 14:51:19 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-11.tower-33.messagelabs.com with AES256-SHA encrypted SMTP; 10 Jan 2017 14:51:19 -0000 Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 10 Jan 2017 15:51:11 +0100 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH11W.internal.vodafone.com (47.73.211.215) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 10 Jan 2017 15:51:10 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0294.000; Tue, 10 Jan 2017 15:51:09 +0100 From: "Dawes, Peter, Vodafone Group" To: Sean Turner , "secdir@ietf.org" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0A Date: Tue, 10 Jan 2017 14:51:09 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> In-Reply-To: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" , "ietf@ietf.org" , "draft-ietf-insipid-logme-reqs.all@ietf.org" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:51:28 -0000 Hello Sean, Thanks very much for your review, some proposals and answers from the co-au= thors inline below to cover the points raised. Best regards, Peter > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 07 January 2017 02:57 > To: secdir@ietf.org > Cc: insipid@ietf.org; ietf@ietf.org; draft-ietf-insipid-logme-reqs.all@ie= tf.org > Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >=20 > Reviewer: Sean Turner > Review result: Has Nits >=20 > After getting over my initial reaction that was something like "srsly!? w= e're > going to standardize the exact opposite of 'do not track'", I realized th= at this > is a requirements draft for an IETF approved WG and a chartered work item > of that WG :) >=20 > 0) s3.2: Is the intent to define a protocol mechanism to determine if the= two > or domains are part of the same trust domain? This requirement could be > achieved by saying out-of-band bilateral agreements are the mechanism to > establish the domain. There is no intent to define a protocol mechanism to determine if two or more domains are part of the same trust domain. s3.2 explains the meaning of the term "trust domain" as it is used in this draft because the term "tr= ust domain" does not have a fixed meaning throughout its use in RFCs. RFC 3324 section 2.3 defines "trust domain" for network asserted identity and this definition is re-used by RFC 7316 for a private network indicator. "Trust domain" is used without definition in RFC6404. So we define the term " trus= t domain" as it applies to log-me marking. >=20 > 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"? = Is > there another logging format other than SIP CLF? We am not aware of any other SIP logging formats and SIP CLF is expected to= be used, but the logging format will be defined in the solutions draft. =20 >=20 > 2) s5.1: Should the must be MUST in the following: >=20 > All log retrieval mechanisms must adhere to > authorization and privacy protection policies > set forth by the network administrator. >=20 This "must" was left lower case as retrieval itself is out of scope, but we= think capitalizing MUST would be consistent with the rest of the draft so we can do that. Although this MUST does not impact interoperability, we extended the use of MUST beyond interoperability required to satisfy RFC 2119 as a result of a comment from area director Ben Campbell. > 3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing? > I mean if SIP doesn't allow adding new headers then didn't somebody sink > your battleship? But SIP does allow you to add arbitrary headers so I th= ink > I'm missing something as to why this is needed? The purpose of REQ3 is to make it clear that the solution needs a new protocol element, i.e. "log me" marking cannot be done using existing SIP. The text says: "REQ3: It MUST be possible to mark a SIP request or response as of interest for logging by inserting a "log me" marker. This is known a= s "log me" marking. " >=20 > 4) s5.2: REQ3 - Reads a bit awkward to me how about: >=20 > It MUST be possible to mark a SIP request or response for > logging by inserting a "log me" marker. >=20 > i.e., remove "of interest" We can see your point. The purpose of the words "of interest" is to avoid suggesting that marking requests and responses forces them to be logged. The decision of whether to honour the log-me marking is largely left to the admin policy (e.g. s6.2.1 says " The presence of a "log me" marker might cause some SIP entities to log signaling.") but "log me" marking is n= ot expected to force logging in all cases. =20 The following revision of REQ3 would clarify: REQ3: It MUST be possible to mark a SIP request or response to be considere= d for logging by inserting a "log me" marker. >=20 > 5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are ther= e fields > that SIP requires be stripped? The purpose of REQ4 (It MUST be possible for a "log me" marker to cross network boundaries.) is to ensure that the log me marker is not defined in = a way that will very probably cause it to be removed by real-world networks such as described earlier in the draft in s3.1 ("A network boundary is significant in this document because manipulation of signaling at the boundary could prevent end-to-end testing or troubleshooting. "). Also, some protocol elements might change at a network boundary, for example an outgoing network boundary may obfuscate some fields, or an incoming network boundary might translate the request URI from a public identity to one that is private to that network. >=20 > 6) Is there a missing requirement based on the security considerations th= at > requires the this marker MUST be removed at the earliest opportunity if i= t > has been incorrectly inserted? We can move the text "The presence of a "log me" marker might cause some SI= P entities to log signaling. Therefore, this marker MUST be removed at the= earliest opportunity if it has been incorrectly inserted." from s6.2.1 and add a REQ12 in s5.3. >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Tue Jan 10 09:33:24 2017 Return-Path: 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 D1A4D1296EF for ; Tue, 10 Jan 2017 09:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 jhia_sT26qel for ; Tue, 10 Jan 2017 09:33:21 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 A2A5F129541 for ; Tue, 10 Jan 2017 09:33:21 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-03v.sys.comcast.net with SMTP id R0HoczZ9HcKypR0IScYISG; Tue, 10 Jan 2017 17:33:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484069600; bh=4AukQsG5rSLQEWb2OcYQ2AzoC75dFYzsR1PyZIz0TWI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CtaVdKY7mVEDQXarKi/LKzu7E9KABiDkoHlXm/IfGrzohZruFk3G1x932kKH5AUg+ cvu6fQkjPW3libHl7E6iuJE28lkuWwpJWejAH70lPAHnNbtKYvOKWyQiD3rPjraA7P aps2ajaHYNJwu1V0jwv65O9l+EwESzgqX/HH71eCeowJJrMjVA4o/svdrZLmyTP9bg wM1l3UmIw6xXrVkcm7zq07/XOx130Tqm6nan7xI1KhAx8soNw9zPL6WDJsPGHO2yoP 4dp6/iKJP4uwIrnI+Xf4oxcKA9Ml8NHmf15+/u4by1JR21eh+Vc0DHn0+3IN3ORCps H3TDlef53lkVw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-07v.sys.comcast.net with SMTP id R0IRcaVhMaRT1R0IRc7IZB; Tue, 10 Jan 2017 17:33:20 +0000 To: insipid@ietf.org References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> From: Paul Kyzivat Message-ID: <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> Date: Tue, 10 Jan 2017 12:33:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHEUG12vmc0rVcGJ6CGa8x3m3W+SH01SEetmoZlQztEDM3/cxJiI1weMpJRmvsxpFayFXl/xnfScP9XuqCDYKa1Ks0Dac6DKyTeQ7+dCqQUl551C/+nx i/Zju3IvMFhudHUQEYhJ5EctpePNoNpd71ml4ZSV6kC4ixRgjtEPfdasUw9z/tey/6ZFYb5OZJJ0gQ== Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:33:23 -0000 I have a couple of comments: On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: >> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"? Is >> there another logging format other than SIP CLF? > > We am not aware of any other SIP logging formats and SIP CLF is expected to be used, but the logging format will be defined in the solutions draft. IIUC, the mechanism for retrieval of the logs is out of scope for this document and the corresponding mechanism document. So why is the format of the logs of any relevance here? >> 6) Is there a missing requirement based on the security considerations that >> requires the this marker MUST be removed at the earliest opportunity if it >> has been incorrectly inserted? > > We can move the text "The presence of a "log me" marker might cause some SIP entities to log signaling. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted." > from s6.2.1 and add a REQ12 in s5.3. What do you mean by "incorrectly inserted"? If this is a syntax issue, then presumably it will be dealt with as a syntax error of the sip message. If the standard sip handling mechanism is "ignore", then how will it be recognized as a "log me" marker so that it may be removed? To act on this the marker must parse syntactically as a "log me" marker (whatever that syntax turns out to be) yet violate some semantic rule. Thanks, Paul From nobody Wed Jan 11 02:39:43 2017 Return-Path: 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 35AE412960C for ; Wed, 11 Jan 2017 02:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham 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 APW1HmElJqId for ; Wed, 11 Jan 2017 02:39:39 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (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 A5FE11294D7 for ; Wed, 11 Jan 2017 02:39:38 -0800 (PST) Received: from [195.245.230.51] by server-4.bemta-3.messagelabs.com id 88/A6-01392-86B06785; Wed, 11 Jan 2017 10:39:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRWlGSWpSXmKPExsWi75nTqZvBXRZ hsP0dl8X8+8+YLB786GVzYPKY/HgOo8eSJT+ZApiiWDPzkvIrElgzVk6YwVxwX6Li7eynbA2M c0W6GLk4hAS2M0r0NdxkhXAOM0pM+/+KCcLZxChx4fF0oAwHB5uAvcSMPTFdjJwcIgLBElseL mUHsYUFHCV2HznMAhF3klh0ZBs7jL361VlGEJtFQFWi59oNsBpegVCJvg3v2SDmn2GU+NJzjx kkwQk0/+rLB2BFjAKyEl8aV4PFmQXEJW49mc8EYksICEgs2XOeGcIWlXj5+B8rRI2OxILdn9g gbG2JZQtfM0MsE5Q4OfMJ2EwhoCP+rVzENIFRZBaSsbOQtM9C0j4LSfsCRpZVjBrFqUVlqUW6 hsZ6SUWZ6RkluYmZObqGBsZ6uanFxYnpqTmJScV6yfm5mxiB8cIABDsYt233PMQoycGkJMp75 nVphBBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3mCusgghwaLU9NSKtMwcYOTCpCU4eJREeKNB0r zFBYm5xZnpEKlTjIpS4rz9IAkBkERGaR5cGyxZXGKUlRLmZQQ6RIinILUoN7MEVf4VozgHo5I wbzLIFJ7MvBK46a+AFjMBLY60KwZZXJKIkJJqYFw8K4wveY9Zl9mbfz8XHT2mqLFve/2yWPMf Etz8NSI3476n5p9KLlMrXFD/T73oAfsKiSsTdrYzXZyQOW9LvFOiivMPqzDPVsszF9cfFGif7 mjUti3u/+ad1xZnhLzicpB789xq48ZT/ZcfJjrlK7wW+mnFffXIxUOqkvreCo7qf19wZRy706 nEUpyRaKjFXFScCABs8GmKEQMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-13.tower-33.messagelabs.com!1484131175!84030576!1 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8900 invoked from network); 11 Jan 2017 10:39:36 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.137) by server-13.tower-33.messagelabs.com with AES256-SHA encrypted SMTP; 11 Jan 2017 10:39:36 -0000 Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 11 Jan 2017 11:39:33 +0100 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH07W.internal.vodafone.com (47.73.211.211) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 11 Jan 2017 11:39:32 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0294.000; Wed, 11 Jan 2017 11:39:30 +0100 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4A== Date: Wed, 11 Jan 2017 10:39:30 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> In-Reply-To: <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 10:39:41 -0000 Hello Paul, Thanks for the comments, replies inline. Regards, Peter > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 10 January 2017 17:33 > To: insipid@ietf.org > Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >=20 > I have a couple of comments: >=20 > On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: >=20 > >> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging > >> format"? Is there another logging format other than SIP CLF? > > > > We am not aware of any other SIP logging formats and SIP CLF is expecte= d > to be used, but the logging format will be defined in the solutions draft= . >=20 > IIUC, the mechanism for retrieval of the logs is out of scope for this > document and the corresponding mechanism document. So why is the > format of the logs of any relevance here? The draft tries to distinguish the format of the logs from the mechanism fo= r retrieval using the words "When and how " in s5.1 "When and how signaling= logs are retrieved is out of scope of this document." It seems helpful to encourage a standard logging format by po= inting to RFC 6873.=20 >=20 > >> 6) Is there a missing requirement based on the security > >> considerations that requires the this marker MUST be removed at the > >> earliest opportunity if it has been incorrectly inserted? > > > > We can move the text "The presence of a "log me" marker might cause > some SIP entities to log signaling. Therefore, this marker MUST be remov= ed > at the earliest opportunity if it has been incorrectly inserted." > > from s6.2.1 and add a REQ12 in s5.3. >=20 > What do you mean by "incorrectly inserted"? >=20 > If this is a syntax issue, then presumably it will be dealt with as a syn= tax error > of the sip message. If the standard sip handling mechanism is "ignore", t= hen > how will it be recognized as a "log me" marker so that it may be removed? >=20 > To act on this the marker must parse syntactically as a "log me" marker > (whatever that syntax turns out to be) yet violate some semantic rule. "incorrectly inserted" means that either a "log me" marker has appeared for= the first time mid-dialog, or that a SIP entity that is controlling the "l= og me" marking sees a "log me" marker that should not be there. For example= , a UAC inserts (maliciously or due to mis-configuration) a "log me" marker= in an initial dialog-creating request but for that network a SIP intermedi= ary has sole responsible for "log me" marking initial dialog-creating reque= sts and this SIP intermediary detects and removes the marker.=20 If you think this is unclear, perhaps we could expand a little to something= like=20 " The presence of a "log me" marker might cause some SIP entities to log signaling. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted (e.g. mid-dialo= g or outside the configured start and stop of "log me" marking)." >=20 > Thanks, > Paul >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Wed Jan 11 07:09:27 2017 Return-Path: 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 A21F612940D for ; Wed, 11 Jan 2017 07:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 WOqBarSwC2ow for ; Wed, 11 Jan 2017 07:09:23 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 33CA5129468 for ; Wed, 11 Jan 2017 07:09:23 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-10v.sys.comcast.net with SMTP id RKWTcDd5MkJTyRKWfccrUf; Wed, 11 Jan 2017 15:09:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484147361; bh=oj5JLp11nFSdcNylfy4vDaeLTgJfwEgnXjqiTAD1/fU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JvXxVWWtIxLuLNKkj68tMgqcWKk7dNA1B9cL3WXkz+J++4rc4JldJVLAkpoTYvhri SYHPUkQP3trMAqifmnChTsFY6bm8CtxA2VSNF7nn0g+Mkrwg7hdosasViCDEfBZ6TF S1qNhbCfpbxpJ+FE6rL3a714dzf8QvNmVSuczfY8CjiT81RxiWTrBjSDqjpA+ptZMr rEibtUwHys5qECenlbJFXRWJOfb/WsY6szpUFnNbjW/zcYfjQ5rVkgEtjst+kaN8OX pzSm8ajYiySkBPzPyhPGINlKQ6eVN4tX+aLIGnRw0rgl+VkGoB0XKpHDzu9PB/jNZ8 lXzS8xwV/Ignw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-19v.sys.comcast.net with SMTP id RKWecz0bMYZITRKWfcLW6x; Wed, 11 Jan 2017 15:09:21 +0000 To: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> From: Paul Kyzivat Message-ID: <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> Date: Wed, 11 Jan 2017 10:09:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFZJnkLlJkenEMoBPbGq0otGfJxugPz9nn7vLOk5TwALAb27yZOqbMNwM3BZyb/UI/zhC0TX4Ta1L6YvpYTkPN/Aq3+d5kg22rJ0fmoCTYfEIzChs/He TmBP0aTLGkfH37XPU+rpbX9zqWV0yus5DFUD9750dn2TQpGGJ3uplN6hW+doGJLk1+/gJfc5ob6PkwomLSmzBF56uzQqr2OAzFg= Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:09:25 -0000 On 1/11/17 5:39 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > Thanks for the comments, replies inline. > > Regards, > Peter > >> -----Original Message----- >> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 10 January 2017 17:33 >> To: insipid@ietf.org >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >> >> I have a couple of comments: >> >> On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: >> >>>> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging >>>> format"? Is there another logging format other than SIP CLF? >>> >>> We am not aware of any other SIP logging formats and SIP CLF is expected >> to be used, but the logging format will be defined in the solutions draft. >> >> IIUC, the mechanism for retrieval of the logs is out of scope for this >> document and the corresponding mechanism document. So why is the >> format of the logs of any relevance here? > > The draft tries to distinguish the format of the logs from the mechanism for retrieval using the words "When and how " in s5.1 "When and how signaling logs are retrieved is out of scope of this > document." It seems helpful to encourage a standard logging format by pointing to RFC 6873. This is not a requirement that can be verified via any published protocol. (Because retrieval is out of scope.) Even if retrieval is subsequently standardized, the requirement would be that the retrieved document be in CLF format, not that the logging be *captured* in that format. I have no objection to a non-normative hint that CLF defined and well suited for capturing the logs. >>>> 6) Is there a missing requirement based on the security >>>> considerations that requires the this marker MUST be removed at the >>>> earliest opportunity if it has been incorrectly inserted? >>> >>> We can move the text "The presence of a "log me" marker might cause >> some SIP entities to log signaling. Therefore, this marker MUST be removed >> at the earliest opportunity if it has been incorrectly inserted." >>> from s6.2.1 and add a REQ12 in s5.3. >> >> What do you mean by "incorrectly inserted"? >> >> If this is a syntax issue, then presumably it will be dealt with as a syntax error >> of the sip message. If the standard sip handling mechanism is "ignore", then >> how will it be recognized as a "log me" marker so that it may be removed? >> >> To act on this the marker must parse syntactically as a "log me" marker >> (whatever that syntax turns out to be) yet violate some semantic rule. > > "incorrectly inserted" means that either a "log me" marker has appeared for the first time mid-dialog, or that a SIP entity that is controlling the "log me" marking sees a "log me" marker that should not be there. For example, a UAC inserts (maliciously or due to mis-configuration) a "log me" marker in an initial dialog-creating request but for that network a SIP intermediary has sole responsible for "log me" marking initial dialog-creating requests and this SIP intermediary detects and removes the marker. > If you think this is unclear, perhaps we could expand a little to something like > " The presence of a "log me" marker might cause some SIP entities to > log signaling. Therefore, this marker MUST be removed at the > earliest opportunity if it has been incorrectly inserted (e.g. mid-dialog or outside the configured start and stop of "log me" marking)." That is much better. Thanks, Paul From nobody Thu Jan 12 05:21:17 2017 Return-Path: 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 DEF371293E3 for ; Thu, 12 Jan 2017 05:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham 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 tpnF_ixoFU6R for ; Thu, 12 Jan 2017 05:21:13 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) (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 9F59D128874 for ; Thu, 12 Jan 2017 05:21:13 -0800 (PST) Received: from [85.158.138.179] by server-16.bemta-3.messagelabs.com id 6E/25-03637-7C287785; Thu, 12 Jan 2017 13:21:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleJIrShJLcpLzFFi42LR98zp0T3eVB5 h0LeVx2L+/WdMFg9+9LI5MHlMfjyH0WPJkp9MAUxRrJl5SfkVCawZF1o1CyYqVXy4t4O1gfGi dBcjF4eQwHZGiRWtM1khnMOMElOmX2aBcI4wSrzqvMUE4cxllPizciZ7FyMHB5uAvcSMPTFdj JwcIgLBElseLmUHsYUFHCV2HznMAhF3klh0ZBs7hO0ncXHCdzCbRUBVYsX8yWwgY3gFQiW6Tj pCjD/NJLH73SM2kBpOoPGfZp1gBbEZBWQlvjSuZgaxmQXEJW49mc8EYksICEgs2XOeGcIWlXj 5+B8rRI2OxILdn9ggbG2JZQtfg9XwCghKnJz5BOw2IaAb/q1cxDSBUXQWkrGzkLTPQtI+C0n7 AkaWVYzqxalFZalFuoZ6SUWZ6RkluYmZObqGBsZ6uanFxYnpqTmJScV6yfm5mxiBMcQABDsYl 390OsQoycGkJMq7yqM8QogvKT+lMiOxOCO+qDQntfgQowwHh5IE77RGoJxgUWp6akVaZg4wmm HSEhw8SiK82iBp3uKCxNzizHSI1ClGRSlx3jUgCQGQREZpHlwbLIFcYpSVEuZlBDpEiKcgtSg 3swRV/hWjOAejkjDvBpApPJl5JXDTXwEtZgJafNEGbHFJIkJKqoEx8vfhizI6d40r11jyLF73 r+q9qe50LybOA4sVEyaLX9dY/ivqwS199qIrguvjZi67d+6OZKhQbeQFrT5W30eV9dxSIcFLu ZWkX1/fJbaJL+7LsuxbM3YeV35YMCfCv/mcV43r/DMLC8IWT5snmFsUkWjvoWqRPtclUTDUzy +Aedv3OG5HzddKLMUZiYZazEXFiQBTkZRGGwMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-9.tower-169.messagelabs.com!1484227270!90055598!2 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23441 invoked from network); 12 Jan 2017 13:21:11 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.140) by server-9.tower-169.messagelabs.com with AES256-SHA encrypted SMTP; 12 Jan 2017 13:21:11 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 12 Jan 2017 13:41:14 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 12 Jan 2017 13:41:11 +0100 Received: from VOEXC27W.internal.vodafone.com (145.230.103.199) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 12 Jan 2017 13:41:11 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc27w ([145.230.103.199]) with mapi id 14.03.0294.000; Thu, 12 Jan 2017 13:41:10 +0100 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4IAAQi0AgAF0fZA= Date: Thu, 12 Jan 2017 12:41:09 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com> References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> In-Reply-To: <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:21:16 -0000 Hello Paul, Mandating a standard logging format means that tools for analysing logs wil= l know what to expect. I take the point that because how and when logs are = retrieved is out of scope then the "log me" solution will not detail how lo= g files are examined, nevertheless log files will be retrieved somehow. Imp= lementations will have to use the specified format in order to claim compli= ance, so it seems a useful requirement.=20 Regards, Peter > -----Original Message----- > From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net] > Sent: 11 January 2017 15:09 > To: Dawes, Peter, Vodafone Group; insipid@ietf.org > Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >=20 > On 1/11/17 5:39 AM, Dawes, Peter, Vodafone Group wrote: > > Hello Paul, > > Thanks for the comments, replies inline. > > > > Regards, > > Peter > > > >> -----Original Message----- > >> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul > >> Kyzivat > >> Sent: 10 January 2017 17:33 > >> To: insipid@ietf.org > >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 > >> > >> I have a couple of comments: > >> > >> On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: > >> > >>>> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging > >>>> format"? Is there another logging format other than SIP CLF? > >>> > >>> We am not aware of any other SIP logging formats and SIP CLF is > >>> expected > >> to be used, but the logging format will be defined in the solutions dr= aft. > >> > >> IIUC, the mechanism for retrieval of the logs is out of scope for > >> this document and the corresponding mechanism document. So why is > the > >> format of the logs of any relevance here? > > > > The draft tries to distinguish the format of the logs from the mechanis= m for > retrieval using the words "When and how " in s5.1 "When and how signaling > logs are retrieved is out of scope of this > > document." It seems helpful to encourage a standard logging format b= y > pointing to RFC 6873. >=20 > This is not a requirement that can be verified via any published protocol= . > (Because retrieval is out of scope.) Even if retrieval is subsequently > standardized, the requirement would be that the retrieved document be in > CLF format, not that the logging be *captured* in that format. >=20 > I have no objection to a non-normative hint that CLF defined and well sui= ted > for capturing the logs. >=20 > >>>> 6) Is there a missing requirement based on the security > >>>> considerations that requires the this marker MUST be removed at the > >>>> earliest opportunity if it has been incorrectly inserted? > >>> > >>> We can move the text "The presence of a "log me" marker might cause > >> some SIP entities to log signaling. Therefore, this marker MUST be > >> removed at the earliest opportunity if it has been incorrectly inserte= d." > >>> from s6.2.1 and add a REQ12 in s5.3. > >> > >> What do you mean by "incorrectly inserted"? > >> > >> If this is a syntax issue, then presumably it will be dealt with as a > >> syntax error of the sip message. If the standard sip handling > >> mechanism is "ignore", then how will it be recognized as a "log me" > marker so that it may be removed? > >> > >> To act on this the marker must parse syntactically as a "log me" > >> marker (whatever that syntax turns out to be) yet violate some semanti= c > rule. > > > > "incorrectly inserted" means that either a "log me" marker has appeared > for the first time mid-dialog, or that a SIP entity that is controlling t= he "log > me" marking sees a "log me" marker that should not be there. For example, > a UAC inserts (maliciously or due to mis-configuration) a "log me" marker= in > an initial dialog-creating request but for that network a SIP intermediar= y has > sole responsible for "log me" marking initial dialog-creating requests an= d this > SIP intermediary detects and removes the marker. > > If you think this is unclear, perhaps we could expand a little to > > something like " The presence of a "log me" marker might cause some SIP > entities to > > log signaling. Therefore, this marker MUST be removed at the > > earliest opportunity if it has been incorrectly inserted (e.g. mid-d= ialog or > outside the configured start and stop of "log me" marking)." >=20 > That is much better. >=20 > Thanks, > Paul >=20 From nobody Thu Jan 12 08:17:17 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCDD1294C9; Thu, 12 Jan 2017 08:17:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148423783701.29293.15508238136822500989.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 08:17:17 -0800 Archived-At: Cc: dromasca@gmail.com, insipid@ietf.org, ietf@ietf.org, draft-ietf-insipid-logme-reqs.all@ietf.org Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:17:17 -0000 Reviewer: Dan Romascanu Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. It's a short, focused and well-written document. It is interesting for the operators of networks that use SIP, as this indicator can be used to trigger testing or debugging in the networks that they operate. It seems that different implications on security and network behavior were considered, although some of them are not explicitly mentioned - such as the potential overload or DoS attacks in case of mis-configuration or malicious configuration of a big number of terminals in a SIP network leading to simultaneous activation of debug modes. It may be good to explicitly mentions these, but otherwise this document is READY from an OPS-DIR perspective. From nobody Thu Jan 12 10:14:08 2017 Return-Path: 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 6F52B129410 for ; Thu, 12 Jan 2017 10:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 1I8oBcAdcJyi for ; Thu, 12 Jan 2017 10:14:04 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 7BE5612953A for ; Thu, 12 Jan 2017 10:14:04 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-09v.sys.comcast.net with SMTP id Rjsbc467R5lLvRjsycVqwt; Thu, 12 Jan 2017 18:14:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484244844; bh=sbV+h28ec2lkKDZ6jhpgNr8bcJOver5N9PJ/xqwwp5k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=amZ1qyTRbZJx2asdo8jfP8CyFmHsWpakHADyE5QYsGBCZ//fBf+FI8TswgGxfgXs8 OXGhCWb49ozL1DCX8conHn3WYzseMzgtrm/s8U/GMGPzuNzLbVWD+sz9x0aM3rOggy K4a/tqTLkFy6NVFir/T4QwQdjT55gwaT3qRnKHecK1MvWu3PiufhGkzKW8Hn7mcXhJ V43echLws+L6r611y6JJpIUcuVwXEyY513W5wH8SPHv9NHVZcMGFBepxOUFqNgY/IB nAUD+aD/LpcUg5GwOMUILUW6e+yC6An07hFEMVVfJOmkKIMSDBI07Hgi1s0yFlveIF 9335XQDgrJUyA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-18v.sys.comcast.net with SMTP id RjswccI0b9HUeRjsxccpc0; Thu, 12 Jan 2017 18:14:04 +0000 To: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com> From: Paul Kyzivat Message-ID: <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@comcast.net> Date: Thu, 12 Jan 2017 13:14:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMyssnkxi/JuLyg/tXfyk1SD042C3DvCCcVprVMw7JPJrceo1DEkdYC3vdnd6nXaYUqVIfbyaoQXDWaQI1wGiuTiTDrswzjYXSR3koaRW9YSOez/XXqT n8sCitgTbUM5fhpG3ELRm7mx2o+BWx+CJkhky3D0vAm93koWc5+uh4i7UK21cIBlKEcAq2RBO3MhTud/iz4ipqbqOkA4fFTlhYY= Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:14:07 -0000 On 1/12/17 7:41 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > Mandating a standard logging format means that tools for analysing logs will know what to expect. I take the point that because how and when logs are retrieved is out of scope then the "log me" solution will not detail how log files are examined, nevertheless log files will be retrieved somehow. Implementations will have to use the specified format in order to claim compliance, so it seems a useful requirement. I remain unconvinced that this requirement belongs in the document. For one thing, there is no way to verify compliance. For another, there could be good reasons to use another format, as long as CLF format can be generated if/when needed. For instance, somebody might find it convenient to capture in wireshark format. But I don't consider this a big deal, so I won't press the issue further. Thanks, Paul > Regards, > Peter > >> -----Original Message----- >> From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net] >> Sent: 11 January 2017 15:09 >> To: Dawes, Peter, Vodafone Group; insipid@ietf.org >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >> >> On 1/11/17 5:39 AM, Dawes, Peter, Vodafone Group wrote: >>> Hello Paul, >>> Thanks for the comments, replies inline. >>> >>> Regards, >>> Peter >>> >>>> -----Original Message----- >>>> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul >>>> Kyzivat >>>> Sent: 10 January 2017 17:33 >>>> To: insipid@ietf.org >>>> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >>>> >>>> I have a couple of comments: >>>> >>>> On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: >>>> >>>>>> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging >>>>>> format"? Is there another logging format other than SIP CLF? >>>>> >>>>> We am not aware of any other SIP logging formats and SIP CLF is >>>>> expected >>>> to be used, but the logging format will be defined in the solutions draft. >>>> >>>> IIUC, the mechanism for retrieval of the logs is out of scope for >>>> this document and the corresponding mechanism document. So why is >> the >>>> format of the logs of any relevance here? >>> >>> The draft tries to distinguish the format of the logs from the mechanism for >> retrieval using the words "When and how " in s5.1 "When and how signaling >> logs are retrieved is out of scope of this >>> document." It seems helpful to encourage a standard logging format by >> pointing to RFC 6873. >> >> This is not a requirement that can be verified via any published protocol. >> (Because retrieval is out of scope.) Even if retrieval is subsequently >> standardized, the requirement would be that the retrieved document be in >> CLF format, not that the logging be *captured* in that format. >> >> I have no objection to a non-normative hint that CLF defined and well suited >> for capturing the logs. >> >>>>>> 6) Is there a missing requirement based on the security >>>>>> considerations that requires the this marker MUST be removed at the >>>>>> earliest opportunity if it has been incorrectly inserted? >>>>> >>>>> We can move the text "The presence of a "log me" marker might cause >>>> some SIP entities to log signaling. Therefore, this marker MUST be >>>> removed at the earliest opportunity if it has been incorrectly inserted." >>>>> from s6.2.1 and add a REQ12 in s5.3. >>>> >>>> What do you mean by "incorrectly inserted"? >>>> >>>> If this is a syntax issue, then presumably it will be dealt with as a >>>> syntax error of the sip message. If the standard sip handling >>>> mechanism is "ignore", then how will it be recognized as a "log me" >> marker so that it may be removed? >>>> >>>> To act on this the marker must parse syntactically as a "log me" >>>> marker (whatever that syntax turns out to be) yet violate some semantic >> rule. >>> >>> "incorrectly inserted" means that either a "log me" marker has appeared >> for the first time mid-dialog, or that a SIP entity that is controlling the "log >> me" marking sees a "log me" marker that should not be there. For example, >> a UAC inserts (maliciously or due to mis-configuration) a "log me" marker in >> an initial dialog-creating request but for that network a SIP intermediary has >> sole responsible for "log me" marking initial dialog-creating requests and this >> SIP intermediary detects and removes the marker. >>> If you think this is unclear, perhaps we could expand a little to >>> something like " The presence of a "log me" marker might cause some SIP >> entities to >>> log signaling. Therefore, this marker MUST be removed at the >>> earliest opportunity if it has been incorrectly inserted (e.g. mid-dialog or >> outside the configured start and stop of "log me" marking)." >> >> That is much better. >> >> Thanks, >> Paul >> > > From nobody Mon Jan 16 07:23:56 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 532A3129575; Mon, 16 Jan 2017 07:23:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148458022933.22524.8438146785464958768.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 07:23:49 -0800 Archived-At: Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-reqs-12.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:23:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID of the IETF. Title : Requirements for Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-reqs-12.txt Pages : 10 Date : 2017-01-16 Abstract: SIP networks use signaling monitoring tools to debug customer reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients, and therefore impractical to monitor SIP signaling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-reqs-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 16 11:24:39 2017 Return-Path: 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 A2BDB129413 for ; Mon, 16 Jan 2017 11:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] autolearn=ham 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 uO26S8ZiUHw9 for ; Mon, 16 Jan 2017 11:24:36 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.114]) (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 C614812961F for ; Mon, 16 Jan 2017 11:24:35 -0800 (PST) Received: from [193.109.254.3] by server-10.bemta-6.messagelabs.com id 19/DC-13192-1FD1D785; Mon, 16 Jan 2017 19:24:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRWlGSWpSXmKPExsVy+MUXQ92PsrU RBjdO8FnMneJnMf/+MyaLBz962RyYPab83sjqMfnxHEaPJUt+MgUwR7Fm5iXlVySwZjT3XmIp WONWMe0rSwPjFssuRi4OIYHtjBIr1m1nhHAOM0o0XLjHBOEcYZT48LyLFcKZC1R28B1bFyMHB 5uAvcSMPTFdjJwcIgLBElseLmUHsZkFHCXurfnGCGILA9m7jxxmgahxklh0ZBs7hB0l8fX7Vm aQMSwCqhK33oKV8AqESrRsA7FBVp1iluhp2A02hxNo1ePfs8BsRgFZiS+Nq5khdolL3Hoynwn ElhAQkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUHY2hLLFr5mhlgmKHFy5hOwxUJAN/xbuYhpAqPY LCRjZyFpn4WkfRaS9gWMLKsY1YtTi8pSi3Qt9ZKKMtMzSnITM3N0DQ3M9HJTi4sT01NzEpOK9 ZLzczcxAqONAQh2MN7dFHCIUZKDSUmU94ZQbYQQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd45Mk A5waLU9NSKtMwcYNzDpCU4eJREeAtA0rzFBYm5xZnpEKlTjIpS4ryvQRICIImM0jy4NliqucQ oKyXMywh0iBBPQWpRbmYJqvwrRnEORiVh3o0gU3gy80rgpr8CWswEtPi6TjXI4pJEhJRUA+Py C7UckyaY3lLz6v9pohBVd/D1HTHhqOcp55r+3zt6pSDjhv41dUFvA4Gj67k3MaherJnjvfvyZ fNMw+r0Xxt/bZa1Nv/r46h64USRBK/rgbzO0zcuu8SdNjl86cbzrI+WMlXC8vlvUldbCDcKrL 3uP8l5xgpLw3DJYx/UVZUk5jqxKjEveqTEUpyRaKjFXFScCAAgVGSFMAMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-3.tower-184.messagelabs.com!1484594672!95993341!2 X-Originating-IP: [195.232.244.49] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26468 invoked from network); 16 Jan 2017 19:24:33 -0000 Received: from msedge4.vodafone.com (HELO voxe04hw.internal.vodafone.com) (195.232.244.49) by server-3.tower-184.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 16 Jan 2017 19:24:33 -0000 Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 16 Jan 2017 20:24:32 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 16 Jan 2017 20:24:32 +0100 Received: from VOEXC27W.internal.vodafone.com (145.230.103.199) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 16 Jan 2017 20:24:32 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc27w ([145.230.103.199]) with mapi id 14.03.0294.000; Mon, 16 Jan 2017 20:24:31 +0100 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4IAAQi0AgAF0fZCAAFFyAIAGI0zw Date: Mon, 16 Jan 2017 19:24:30 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C53766@VOEXM31W.internal.vodafone.com> References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com> <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@comcast.net> In-Reply-To: <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@comcast.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Gonzalo Salgueiro \(gsalguei@cisco.com\)" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 19:24:38 -0000 Hello All, A new version (-12) of logme-reqs is uploaded to https://datatracker.ietf.o= rg/doc/draft-ietf-insipid-logme-reqs/ containing the revisions listed belo= w resulting from the latest reviews and discussion.=20 For the review comment "It seems that different implications on security and network behavior were= considered, although some of them are not explicitly mentioned - such as t= he potential overload or DoS attacks in case of mis-configuration or malici= ous configuration of a big number of terminals in a SIP network leading to = simultaneous activation of debug modes. It may be good to explicitly mentio= ns these, but otherwise this document is READY from an OPS-DIR perspective.= "=20 It seems to us that describing mitigation of any particular attacks fits be= tter in the solutions draft (the requirements draft has the basic considera= tion "maliciously adding a "log me" marker MUST NOT adversely affect a netw= ork"). Our proposal is therefore to not make any related changes in this dr= aft, but to forward this comment to be resolved as part of developing the s= olution. Thanks again to the reviewers and commenters for taking time to check the d= raft and provide corrections and improvements, Peter and Arun (co-authors) -12: January 2017 Moved the following text from section 6.2.1 to become REQ12 in section = 5.3: "The presence of a "log me" marker might cause some SIP entities to lo= g signaling. Therefore, this marker MUST be removed at the earliest opport= unity if it has been incorrectly inserted." Added text in brackets to clarify what "incorrectly inserted" means: "Th= erefore, this marker MUST be removed at the earliest opportunity if it has = been incorrectly inserted (e.g. mid-dialog or outside the configured start = and stop of "log me" marking)." Capitalized the word "must" in the text "All log retrieval mechanisms MU= ST adhere to authorization and privacy protection policies set forth by the= network administrator." Changed "SHOULD" to "MUST" in the following text at the start of section= 6.1 "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 MUST be removed at a= trust domain boundary."=20 Revised REQ3 from=20 REQ3: It MUST be possible to mark a SIP request or response as of intere= st for logging by inserting a "log me" marker. This is known as "log me" m= arking.=20 to=20 REQ3: It MUST be possible to mark a SIP request or response to be consid= ered for logging by inserting a "log me" marker. This is known as "log me" = marking. In section 3.1, expanded the first use of "SBC" to "Session Border Contr= oller (SBC)". Expanded the first use of "UA" to "User Agent" (in REQ9). Simplified the wording of section 3.1 paragraph 2 from "[RFC5853] gives examples of manipulating signaling to prevent the sendi= ng network passing on sensitive information, for example topology hiding, o= r the receiving network protecting itself from signaling that is not under = its control, for example protocol repair. Example SIP device types (see [R= FC7092]) that might manipulate signaling at a network boundary are a Sessio= n Border Controller performing protocol repair or Interconnection Border Co= ntrol Function (IBCF) performing topology hiding." to "Topology hiding and protocol repair (see [RFC5853]) are two common func= tions that manipulate signaling at the network boundary. These functions ar= e performed by SIP device types (see [RFC7092]) such as Session Border Con= troller and Interconnection Border Control Function (IBCF)." > -----Original Message----- > From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net] > Sent: 12 January 2017 18:14 > To: Dawes, Peter, Vodafone Group; insipid@ietf.org > Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 >=20 > On 1/12/17 7:41 AM, Dawes, Peter, Vodafone Group wrote: > > Hello Paul, > > Mandating a standard logging format means that tools for analysing logs= will > know what to expect. I take the point that because how and when logs are > retrieved is out of scope then the "log me" solution will not detail how = log > files are examined, nevertheless log files will be retrieved somehow. > Implementations will have to use the specified format in order to claim > compliance, so it seems a useful requirement. >=20 > I remain unconvinced that this requirement belongs in the document. > For one thing, there is no way to verify compliance. > For another, there could be good reasons to use another format, as long a= s > CLF format can be generated if/when needed. For instance, somebody might > find it convenient to capture in wireshark format. >=20 > But I don't consider this a big deal, so I won't press the issue further. >=20 > Thanks, > Paul >=20 > > Regards, > > Peter > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net] > >> Sent: 11 January 2017 15:09 > >> To: Dawes, Peter, Vodafone Group; insipid@ietf.org > >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 > >> > >> On 1/11/17 5:39 AM, Dawes, Peter, Vodafone Group wrote: > >>> Hello Paul, > >>> Thanks for the comments, replies inline. > >>> > >>> Regards, > >>> Peter > >>> > >>>> -----Original Message----- > >>>> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul > >>>> Kyzivat > >>>> Sent: 10 January 2017 17:33 > >>>> To: insipid@ietf.org > >>>> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 > >>>> > >>>> I have a couple of comments: > >>>> > >>>> On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote: > >>>> > >>>>>> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging > >>>>>> format"? Is there another logging format other than SIP CLF? > >>>>> > >>>>> We am not aware of any other SIP logging formats and SIP CLF is > >>>>> expected > >>>> to be used, but the logging format will be defined in the solutions = draft. > >>>> > >>>> IIUC, the mechanism for retrieval of the logs is out of scope for > >>>> this document and the corresponding mechanism document. So why is > >> the > >>>> format of the logs of any relevance here? > >>> > >>> The draft tries to distinguish the format of the logs from the > >>> mechanism for > >> retrieval using the words "When and how " in s5.1 "When and how > >> signaling logs are retrieved is out of scope of this > >>> document." It seems helpful to encourage a standard logging > >>> format by > >> pointing to RFC 6873. > >> > >> This is not a requirement that can be verified via any published proto= col. > >> (Because retrieval is out of scope.) Even if retrieval is > >> subsequently standardized, the requirement would be that the > >> retrieved document be in CLF format, not that the logging be *captured= * > in that format. > >> > >> I have no objection to a non-normative hint that CLF defined and well > >> suited for capturing the logs. > >> > >>>>>> 6) Is there a missing requirement based on the security > >>>>>> considerations that requires the this marker MUST be removed at > >>>>>> the earliest opportunity if it has been incorrectly inserted? > >>>>> > >>>>> We can move the text "The presence of a "log me" marker might > >>>>> cause > >>>> some SIP entities to log signaling. Therefore, this marker MUST be > >>>> removed at the earliest opportunity if it has been incorrectly inser= ted." > >>>>> from s6.2.1 and add a REQ12 in s5.3. > >>>> > >>>> What do you mean by "incorrectly inserted"? > >>>> > >>>> If this is a syntax issue, then presumably it will be dealt with as > >>>> a syntax error of the sip message. If the standard sip handling > >>>> mechanism is "ignore", then how will it be recognized as a "log me" > >> marker so that it may be removed? > >>>> > >>>> To act on this the marker must parse syntactically as a "log me" > >>>> marker (whatever that syntax turns out to be) yet violate some > >>>> semantic > >> rule. > >>> > >>> "incorrectly inserted" means that either a "log me" marker has > >>> appeared > >> for the first time mid-dialog, or that a SIP entity that is > >> controlling the "log me" marking sees a "log me" marker that should > >> not be there. For example, a UAC inserts (maliciously or due to > >> mis-configuration) a "log me" marker in an initial dialog-creating > >> request but for that network a SIP intermediary has sole responsible > >> for "log me" marking initial dialog-creating requests and this SIP > intermediary detects and removes the marker. > >>> If you think this is unclear, perhaps we could expand a little to > >>> something like " The presence of a "log me" marker might cause some > >>> SIP > >> entities to > >>> log signaling. Therefore, this marker MUST be removed at the > >>> earliest opportunity if it has been incorrectly inserted (e.g. > >>> mid-dialog or > >> outside the configured start and stop of "log me" marking)." > >> > >> That is much better. > >> > >> Thanks, > >> Paul > >> > > > > From nobody Tue Jan 17 14:20:19 2017 Return-Path: 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 585111294A1; Tue, 17 Jan 2017 14:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 24UOBfnF51TB; Tue, 17 Jan 2017 14:20:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99041294B2; Tue, 17 Jan 2017 14:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2269; q=dns/txt; s=iport; t=1484691612; x=1485901212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NXz1SM067YM//8+H32E9SULjGitpr8+AQit933bimzQ=; b=jy5blQK5g3ev9kr4M0Jv14QNUbLHbvAjkkKRdzZGqyoiWUAxwPIzcI8x aAp3YLVSb1NT0r65c7DV+PaOVkku/oPgRmPgtQTDF3WDF/RYDeLqZnmZF aiwo6Y/Je9E/Gro+QT4BFViwO5gq0scLe7nd7kPQ/rW2Y03laeRegXbaw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC4l35Y/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9fgQkHjVGSGIgEjSiCCx8LhS5KAoFePxgBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQEBAwEBATgtBwsFCwIBCA4KHhAhBgslAgQOBRuITQMQCA6xWYc8D?= =?us-ascii?q?YJhAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIR4JlglCBeIMzgjEFiGeSGzgBjVq?= =?us-ascii?q?EBJBtihiIUwEfOIFEFToQAYYhc4dLgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,246,1477958400"; d="scan'208";a="196216035" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 22:20:11 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0HMKCCD027945 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 22:20:12 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 16:20:11 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 16:20:11 -0600 From: "Arun Arunachalam (carunach)" To: Dan Romascanu Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 Thread-Index: AQHSbO9bbCtSiQ1pmUGC2nUSCFaAdqE9qnKA Date: Tue, 17 Jan 2017 22:20:11 +0000 Message-ID: <8CA648A4-7DDC-4EA7-B7B4-0BF69957DA83@cisco.com> References: <148423783701.29293.15508238136822500989.idtracker@ietfa.amsl.com> In-Reply-To: <148423783701.29293.15508238136822500989.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.254.159] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ops-dir@ietf.org" , "insipid@ietf.org" , "ietf@ietf.org" , "draft-ietf-insipid-logme-reqs.all@ietf.org" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:20:14 -0000 Hi Dan, Thanks for taking the time to review the LogMe requirements draft and provi= ding feedback! We will discuss about load related attacks and recommended approaches to mi= tigate in LogMe solutions draft under security considerations section.=20 Thanks! Arun > On Jan 12, 2017, at 11:17 AM, Dan Romascanu wrote: >=20 > Reviewer: Dan Romascanu > Review result: Ready >=20 > I have reviewed this document as part of the Operational directorate's >=20 > ongoing effort to review all IETF documents being processed by the > IESG. These=20 > comments were written with the intent of improving the operational > aspects of the=20 > IETF drafts. Comments that are not addressed in last call may be > included in AD reviews=20 > during the IESG review. Document editors and WG chairs should treat > these comments=20 > just like any other last call comments.=20 >=20 > This informational document describes requirements for adding an > indicator to the SIP > protocol data unit (PDU, or a SIP message) that marks the PDU as a > candidate for logging. Such marking will typically be applied as > part of network testing controlled by the network operator and not > used in regular client signaling. However, such marking can be > carried end-to-end including the SIP terminals, even if a session > originates and terminates in different networks. >=20 > It's a short, focused and well-written document. It is interesting for > the operators of networks that use SIP, as this indicator can be used > to trigger testing or debugging in the networks that they operate. It > seems that different implications on security and network behavior > were considered, although some of them are not explicitly mentioned - > such as the potential overload or DoS attacks in case of > mis-configuration or malicious configuration of a big number of > terminals in a SIP network leading to simultaneous activation of debug > modes. It may be good to explicitly mentions these, but otherwise this > document is READY from an OPS-DIR perspective.=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Sat Jan 28 01:41:08 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B903312946F; Sat, 28 Jan 2017 01:41:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148559646171.17936.13169778377127397507.idtracker@ietfa.amsl.com> Date: Sat, 28 Jan 2017 01:41:01 -0800 Archived-At: Cc: insipid@ietf.org, ietf@ietf.org, draft-ietf-insipid-logme-reqs.all@ietf.org Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-12 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 09:41:02 -0000 Reviewer: Stewart Bryant Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-insipid-logme-reqs-?? Reviewer: Stewart Bryant Review Date: 2017-01-28 IETF LC End Date: 2017-01-13 IESG Telechat date: 2017-02-02 Summary: Version 12 is ready for publication Major issues: None Minor issues: None Nits/editorial comments: None From nobody Tue Jan 31 08:31:29 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5331299B3; Tue, 31 Jan 2017 08:31:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148588026351.2436.5177963089384572158.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 08:31:03 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-insipid-logme-reqs-12=3A_=28with_COMMENT=29?= X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:31:03 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-insipid-logme-reqs-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-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't see a value in publishing this draft as a stand-alone document. If needed content can be merged into draft-ietf-insipid-logme-marking (maybe in the appendix); especially the security considerations belong in the spec itself.