From nobody Wed Nov 8 20:30: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 EC47C12E041 for ; Wed, 8 Nov 2017 20:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 lG-ufz2msRmU for ; Wed, 8 Nov 2017 20:30:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28EC12E040 for ; Wed, 8 Nov 2017 20:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7083; q=dns/txt; s=iport; t=1510201832; x=1511411432; h=from:mime-version:subject:message-id:date:cc:to; bh=jsWZdoj3ovAwrLhLWcksdlDv1V8RVx9ooC4ncrLPveE=; b=iEE8hdRTC9IuHaaKt+2ZJndQzvWxOW5yRE54wVwzVkKZsrw2uqmpVEag lFpbMIhfb7N+0h5P1Ovi1ClTPGLfdmfhLTNX/SVK1h4xazxR1j7fTAHPy ceU8taK12w1KgFIlqVq8yyVrlPCKO/7z5+CVPOGSSphvvQDJ5L82x492M M=; X-Files: signature.asc : 833 X-IronPort-AV: E=Sophos;i="5.44,367,1505779200"; d="asc'?scan'208";a="312118516" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Nov 2017 04:30:32 +0000 Received: from rtp-vpn2-447.cisco.com (rtp-vpn2-447.cisco.com [10.82.241.191]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vA94UV7T013013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2017 04:30:31 GMT From: Paul Giralt Content-Type: multipart/signed; boundary="Apple-Mail=_3EA575A8-7DFD-46FA-9FEE-D3CE3EB9090B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Message-Id: Date: Wed, 8 Nov 2017 23:30:29 -0500 Cc: "Arun Arunachalam (carunach) (carunach@cisco.com)" , "Dawes, Peter, Vodafone Group" To: insipid@ietf.org X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: [Insipid] Review of draft-ietf-insipid-logme-marking-08 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 04:30:36 -0000 --Apple-Mail=_3EA575A8-7DFD-46FA-9FEE-D3CE3EB9090B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is my review of draft-ietf-insipid-logme-marking-08: Section 3.6 - Does this specification require that the entire SIP = message be logged? If so, it should be called out as a normative = statement (SIP messages MUST be logged). If not, we should be more = specific and indicate that they SHOULD be logged. Section 3.7 - "ends with the final 200 OK of dialog1=E2=80=9D first of = all doesn=E2=80=99t really indicate which 200 OK it is referring to = (I=E2=80=99m assuming 200 OK in response to BYE), but there is a good = chance, especially if someone is trying to diagnose a call failure, that = the dialog will terminate with a reason code other than a 200 OK. I = think this should read something like =E2=80=9Cends when the last = message in the dialog is sent or received.=E2=80=9D Subsequent sentences = in this section have similar wording indicating the last message in the = dialog instead of a 200 OK. While the example shown in section 3.7 is clear, I don=E2=80=99t think = it represents a typical example of a call transfer and the more typical = case highlights a potential hole in the draft - namely, what happens = when the device wishing to initiate the logging is the UAS instead of = the UAC? A more typical call transfer scenario would be Alice = *receiving* the call from Bob and transferring to Carol (as opposed to = Alice calling Bob then transferring to Carol). If, as stipulated in the = draft, Alice is the one reporting issues transferring calls and = therefore is where we have enabled =E2=80=9Clog me=E2=80=9D marking, how = would this work? Section 4 clearly stipulates that =E2=80=9Clog me=E2=80=9D= marking is initiated on a dialog creating side which seems to imply = that devices receiving a call cannot initiate a =E2=80=9Clog me=E2=80=9D = request. This seems like a hole to me. Of course allowing the UAS to initiate a =E2=80=9Clog me=E2=80=9D = request has implications on the UAC that supports =E2=80=9Clog me=E2=80=9D= , but did not intend to log the call when it created the dialog. If we = were to allow the UAS to insert a =E2=80=9Clog me=E2=80=9D in response = to a request that did not have a =E2=80=9Clog me=E2=80=9D parameter, it = would be desirable for the UAC to also log the dialog-initiating = request. This means that a device supporting this specification must = maintain a copy of any dialog-initiating request at least until the = point where it can determine whether or not the receiving endpoint would = like to log the call or not. This could be upon receiving the first = response other than a 100 Trying. Has any thought been put into this = scenario? Section 4.2 - This first part of the section is talking specifically = about intermediaries being configured to handle =E2=80=9Clog me=E2=80=9D = markings on behalf of a user agent, but then the subsections (4.2.1 and = 4.2.2) revolve around handling of the marking by intermediaries = independent of whether or not it=E2=80=99s being done on behalf of a UA. = I think this should just be organized better so that 4.2.1 and 4.2.2 are = peers with what=E2=80=99s in the 4.2 section as opposed to subsections = as they seem to describe entirely different things. Section 4.2.2.2.2 - In this scenario Proxy 1 is removing the =E2=80=9Clog = me=E2=80=9D parameter so as to not impose logging on Network B, however = it would still be beneficial for Network A to log all requests and = responses from Proxy 1 to Proxy 2, as these messages are still being = initiated / terminated in Network A. This section indicates that Proxy 1 = does not log the INVITE request F2 (and subsequent messages between = Proxy 1 and Proxy 2). I feel we should at the very least indicate it is = permissible and perhaps even desirable to log these messages even though = the =E2=80=9Clog me=E2=80=9D indication has been removed. Instead of = "Proxy 1 does not log INVITE request F2=E2=80=9D perhaps say =E2=80=9CProx= y 1 MAY log INVITE request F2 even though it does not contain a =E2=80=9Cl= og me=E2=80=9D marking=E2=80=9D Section 4.2.2.2.4 - Related to the comment above, this section does not = stipulate at all which messages Proxy 1 MUST / SHOULD / MAY log. Are the = messages between Proxy 1 and Proxy 2 logged by Proxy 1? Nits: Section 3.1 - sentence "This ability requires "log me" marker to be = passed through SIP intermediaries. Session-ID header defined in = ([RFC7989]) was chosen to carry the "log me" marker as a "logme" = parameter since the session identifier is passed through SIP B2BUAs or = other intermediaries.=E2=80=9D I think should read: "This ability requires a "log me" marker to be passed through SIP = intermediaries. The Session-ID header defined in ([RFC7989]) was chosen = to carry the "log me" marker as a "logme" parameter since the session = identifier is passed through SIP B2BUAs or other intermediaries.=E2=80=9D Section 3.5 - This is a comma splice and should be separated into two = sentences or use a semicolon. For example: An originating or terminating user agent and SIP entities on the signaling path can log multiple SIP dialogs simultaneously. These dialogs are differentiated by their test case identifier (the local UUID of the Session-ID header field at the originating device). Section 4.2 - This scenario suggests the following principles when a SIP intermediary is configured to initiate or handle "log me" marking on behalf of user agent: Should have the word =E2=80=98a=E2=80=99 added before =E2=80=98user = agent': This scenario suggests the following principles when a SIP intermediary is configured to initiate or handle "log me" marking on behalf of a user agent: --Apple-Mail=_3EA575A8-7DFD-46FA-9FEE-D3CE3EB9090B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6UlwVQyHEGzN+6QJANZXtwMicqwFAloD2eYACgkQANZXtwMi cqwAVxAAh488auWQU/ZAa6QY/f4uVqIsGxXOwE6E9zbmyYehh9eLg7XIW22m7s8n rDVJQ8+JC9BPN1BdpFaJc+/SXJ+32ShlI8Q1TYDyFk6COSp/7ECimcbfs+B2Hqk8 I68zxSAQdJqAA4ssjnszY85xWwCJ3cksnMNxH2YAjIrn03AOUwyzOvgY6VuKVBDo 8BjfeDwS/jS4anw7W8l6v6QC2ykm+CHemyoHq5MjRR3w/5tYyTncEduppjU3VNqO Of4JCTnoHhBvwBPqOTEzRcfJ2GyRFyyL9ofxBbVMBz22WPjLQnS6ewJ254sBzVE6 Q6lwnRliN75/fo0xOSweoQqqU3pZeJgTTBOhIWO/pvHjYOydvVuqLQE+lsjUrvzP XKLcZ1YZ1/m9Auj59DZs9cl6zJqOZmOU7RxQhgkvRiRK8W/ihaKLPJVa2xSMomUQ /5kUB2fra8Hc5jwW+rohtXyXBa4UaNDb9m6RRoIuiYpg3th7EkbPtNbKRiYe/XBK LSbh/3MOUpx67Y/itx0Y/Kqcnn2IVPTBKQpoloXDP+14R1Uj9QWVxve1qW0iAs4c tG5EH7L22zCnyr6FZ5zHYi6yjWiPf03MlX0eyWfmUeENuG/BJR9rhh+MXKe2j3Eu Vg9haP5imJmuFA2FylXqFGnGgc8zt2BBPXM9MZDodi2RsCKrcBw= =nL0Q -----END PGP SIGNATURE----- --Apple-Mail=_3EA575A8-7DFD-46FA-9FEE-D3CE3EB9090B-- From nobody Tue Nov 28 11:43:36 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 F3381128DE7 for ; Tue, 28 Nov 2017 11:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 2g5V3XnEsuVI for ; Tue, 28 Nov 2017 11:43:32 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7A128B88 for ; Tue, 28 Nov 2017 11:43:31 -0800 (PST) X-AuditID: 1207440f-a43ff70000007960-91-5a1dbc604dd4 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 48.79.31072.16CBD1A5; Tue, 28 Nov 2017 14:43:29 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vASJhRJn007561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 28 Nov 2017 14:43:28 -0500 References: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu> To: "insipid@ietf.org" From: Paul Kyzivat X-Forwarded-Message-Id: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu> Message-ID: Date: Tue, 28 Nov 2017 14:43:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYndR1E3aIxtlsHGikMX8+8+YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W/7M/aCF0oVi1u2szYwbpXuYuTkkBAwkdh1eBdLFyMXh5DA DiaJNzvvs0I4P5gkvm48xwhSJSxgKjH9+HsWEFtIwF7iROMVVhBbREBT4uONc8wgNpuAlsSc Q/9ZIKZ6SyzZvpwdxOYFql/14xlYnEVAVaLnzy82EFtUIE1iz4UOFogaQYmTM5+A2ZwCDhIt Ny+D9TIL2ErcmbubGcIWl7j1ZD4ThC0vsf3tHOYJjAKzkLTPQtIyC0nLLCQtCxhZVjHKJeaU 5urmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmKEhCv/Dsau9TKHGAU4GJV4eC+skI0SYk0s K67MPcQoycGkJMr7aSFQiC8pP6UyI7E4I76oNCe1+BCjBAezkghv5SSgHG9KYmVValE+TEqa g0VJnFd9ibqfkEB6YklqdmpqQWoRTFaGg0NJgjduN1CjYFFqempFWmZOCUKaiYMTZDgP0PDt IDW8xQWJucWZ6RD5U4zGHD09N/4wcTyb+bqBWYglLz8vVUqc1xmkVACkNKM0D24aLOW8YhQH ek6YdxFIFQ8wXcHNewW0iglo1c390iCrShIRUlINjBN0/sc8VuS2fiLO8u6KndsJbn3pP3E2 kgrPqjbmTy55UyDzyDpbX1qzKdxgSutm4dlhG5lV63orD5uxRZ76vW76bRG21afsbd3tMvZs Mgt6E2mwgLfScHdw/07lv/eFLj3M3vmQ/fau/iVXS/7d0hJK8qlmUyv8989T8tmGrfd+2ZV3 zdU3V2Ipzkg01GIuKk4EAN5TYfAUAwAA Archived-At: Subject: [Insipid] Fwd: Re: draft-ietf-insipid-logme-marking-08 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 19:43:34 -0000 I had sent these comments to the authors. Peter asked me to forward them to the list. Here they are. Thanks, Paul -------- Forwarded Message -------- Subject: Re: draft-ietf-insipid-logme-marking-08 Date: Thu, 26 Oct 2017 17:32:41 -0400 From: Paul Kyzivat To: Dawes, Peter, Vodafone Group CC: Arun Arunachalam (carunach) (carunach@cisco.com) Peter, On 10/26/17 5:38 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > > Just a kind reminder to ask if you are able to review the latest > logme-marking draft and post to the insipid list? We authors would very > much like to conclude logme J Oh, sorry. I see -08 has addressed a number of my comments on -07. Reviewing the recent changes: In section 3.7: In the example shown in Figure 2 below, Alice has reported problems making call transfers and her terminal is configured to log signalling for a call transfer. ... IIUC it isn't really feasible to configure to log just call transfers. The logging has to commence at the start of a dialog, before it is known whether there will be a transfer. The signaling is consistent with this, but the description above ought to reflect reality. Also in 3.7: Some of the message contents aren't right. I didn't check everything, but here are a few problems I noted: - F1 is supposed to be from transferor to transferee, but the From and To URIs are backwards from this. - in F4, IIUC the To URI ought to be the Contact URI from F3, but instead has the From-URI from F3. These all need to be rechecked. ADAM: can you check the that the REFER stuff is correct according to the most recent definitions? In section 4.2: The terms "originating SIP intermediary" and "terminating SIP intermediary" are used in this section without definition. Since these are used in a normative way they ought to be defined. But I have a feeling this will not be easy. (I *think* you mean 'first' and 'last' here, rather than the IMS notion of simply being on the originating or terminating side.) While a device will know if it is acting as an intermediary, I don't think it in general has any way to know if it is first or last intermediary. Nor do I think it is necessary for it to know to make your mechanism work. Rather it simply has to recognize whether the request matches its internal state for the dialog. But describing it this will will require some rewording. In section 4.2.2.2.4: I have a question on this. IIUC Proxy 2 is logme-aware but by policy is removing logme marking coming from outside network B. If that is the intent, wouldn't it be better for it to maintain state and insert the logme marking on messages headed back to network A? Or are you assuming the Proxy 2 isn't logme-aware and actively removes stuff it doesn't understand? (If so it is really a B2BUA rather than a proxy.) Section 5.1: I think the text here is not very precise on which cases are error cases, and how to distinguish them from cases where a neighbor doesn't support logme marking. ISTM the condition described here must be evaluated separately for each neighbor. It is an error if the neighbor has previously sent logme in the dialog and then stops, regardless of what has been happening on the other "side". The examples are pretty clear about this, but the text here is not so clear. Otherwise it looks fine to me and my comments on -07 have been addressed. Thanks, Paul > Best regards, > > Peter > > *From:*Dawes, Peter, Vodafone Group > *Sent:* 19 September 2017 10:18 > *To:* 'pkyzivat@alum.mit.edu' > *Subject:* draft-ietf-insipid-logme-marking-08 > > Hello Paul, > > Thanks very much for being one of the people who reviewed the logme > solution draft in detail, it took us a while but we co-authors uploaded > an update and posted a summary of changes to the insipid exploder > https://mailarchive.ietf.org/arch/msg/insipid/6iAK8HspcC7nXNBsQEARYNoC3TA > > It would be very helpful if you could check the changes listed and post > any comments to the list (the summary of changes lists the ones that are > specific to each review). We are hoping to resolve any remaining > comments and then we can request a security review of the draft. > > Best regards, > > Peter >