From rjsparks@nostrum.com Thu Aug 4 14:05:51 2011 Return-Path: X-Original-To: sip-clf@ietfa.amsl.com Delivered-To: sip-clf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62311E8078 for ; Thu, 4 Aug 2011 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZafdzIjwQK4 for ; Thu, 4 Aug 2011 14:05:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFE711E8077 for ; Thu, 4 Aug 2011 14:05:49 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p74L64SI092549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2011 16:06:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 16:06:04 -0500 Message-Id: <856A6315-BB66-4575-9EFB-8725A9278DC9@nostrum.com> To: SIP-CLF Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) Subject: [sip-clf] AD review: draft-ietf-sipclf-problem-statement-07 X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:05:51 -0000 Summary: There are a few issues to address before IETF LC 1) Shouldn't this document be titled something like "framework and data = model"? 2) Why does this document talk about the 4096 byte limit? Shouldn't this = be moved to the encoding draft? 3) The presentation of requirements on devices that forward requests and = responses is under-documented. The notion of "UAS-half" is not explained. = Looking at what we ended up with for Table 1 from the "new reader" perspective, I = suggest that the document doesn't actually need it. The whole section can be = simplified=20 with the details focusing on handling R-RUI, Status, Server-Txn, and = Client-Txn 4) It is not sufficiently clear what it means when a record MUST contain = an element that is not applicable to the element. Are you trying to say "Must be = present with a non-empty value that is not a valid value for the field"? (If so, why = does it have to be non-empty? The -format- document will eventually need to = explain why the group chose "-" there over the empty string.) 5) There is prose in the definition of the =46rom record field that = really belongs in other parts of the document. The =46rom description should look like = the To description.=20 The extra text pointing to whether the values in the URIs are = trustable should be moved=20 to the security considerations section. The text on the utility of = the value for separating first or third party registrations could be moved to an example or = dropped. 6) As the writeup notes, there are bugs in the IP addresses in the = examples: draft-ietf-sipclf-problem-statement-07.txt(853): Found possible = IPv4 address '198.51.1.100' in position 30;=20 draft-ietf-sipclf-problem-statement-07.txt(873): Found possible = IPv4 address '198.51.1.100' in position 30; Both of those should probably have been 198.51.100.1? 7) In the security considerations section, what does it mean to mount a = replay attack by modifying existing records in a log file - a replay attack = against what? The section should call out that an attacker that doesn't have = access=20 to the actual SIP traffic, but does have access to the log files = (especially in=20 real time), gets enough information to mount many of the attacks he = would if he=20 were able to eavesdrop on the traffic. The paragraph encrypting SIP = traffic is=20 trying to get to this point, but it misses an essential issue. Even = if the SIP traffic is hop-hop encrypted - if the attacker can see these log = messages in real time, he can mount many of the attacks he could mount if he could see = the SIP traffic unencrypted. A few editorial nits: The last sentence of the abstract leaves out normal user agents. Section 2 paragraph 1: There are lots of log records that are not summaries of PDUs (skim your = local system.log, daemon.log, or messages.log).=20 The sentence should be adjusted to either say "some log records are" or = be removed. What is the phrase "increasingly used for other services besides session = establishement" in the first sentence of section 3 adding to the draft? I suggest deleting = it. It would help to call out that the source-addresses and = destination-address can be either=20 IPv4 or IPv6 in section 8.1. Section 8.1, next to last paragraph: A B2BUA is not a degenerate case of = a proxy. I think this would be better stated "The fields applicable to a = SIP proxy are also applicable to a B2BUA acting as a SIP proxy". The last paragraph of section 8.1 is confusing, mostly because the = sentence starting "We limit..." is partially redundant with the last sentence in the paragraph. I suggest deleting = the sentence starting "We limit". Section 9 refers to "the templated defined in section 8.2". There is no = template defined in section 8.2. I think you meant to say "The examples below show the values for the = mandatory fields defined in 8.2." In section 9 this statement is not accurate: "The absence of an ACK = request signifies that the ACK was exchanged end-to-end." You cannot infer that an end to end ACK happened because = you don't see a log record for the ACK here. What would be correct to say "Because the ACK request in this case would = be exchanged end-to-end, this element=20 does not see (and therefore will not log) the ACK". From rjsparks@nostrum.com Thu Aug 4 14:30:33 2011 Return-Path: X-Original-To: sip-clf@ietfa.amsl.com Delivered-To: sip-clf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC15E800E for ; Thu, 4 Aug 2011 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HxM53wtCFqn for ; Thu, 4 Aug 2011 14:30:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1C445E800D for ; Thu, 4 Aug 2011 14:30:31 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p74LUkAp094725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 16:30:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <856A6315-BB66-4575-9EFB-8725A9278DC9@nostrum.com> Date: Thu, 4 Aug 2011 16:30:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <15E26452-E508-42E8-A341-BCFA6D33CC5A@nostrum.com> References: <856A6315-BB66-4575-9EFB-8725A9278DC9@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) Cc: SIP-CLF Mailing List Subject: Re: [sip-clf] AD review: draft-ietf-sipclf-problem-statement-07 X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:30:33 -0000 (As an individual contributor) Following up on: > 3) The presentation of requirements on devices that forward requests = and responses > is under-documented. The notion of "UAS-half" is not explained. = Looking at what > we ended up with for Table 1 from the "new reader" perspective, I = suggest that > the document doesn't actually need it. The whole section can be = simplified=20 > with the details focusing on handling R-RUI, Status, Server-Txn, and = Client-Txn Here is some proposed text that could replace the description of Table 1 = and Table 1 itself in section 8.2: In the following cases, an element will not have a sensical value to = provide for one of these fields, even though the field is mandatory. For these = cases, the encoding of the model must define how to represent "not applicable". The = R-URI field is not applicable when logging a response. The Status field is not = applicable when logging a request. The Client-Txn field is always applicable to a UAC. The Server-Txn field does not apply to a UAC unless the element is also acting as a = UAS, and=20 the message associated to this log record corresponds to a message handled by that UAS. For instance, a proxy forwarding a request will populate both the Client-Txn and Server-Txn fields in the record corresponding to the forwarded request. The Server-Txn field is always applicable to a UAS. The Client-Txn field does not apply to a UAS unless the element is also acting as a = UAC, and the message associated to this log record corresponds to a message handled by that UAC. For instance, a proxy forwarding a response will populate both the Server-Txn and Client-Txn fields in the record = corresponding to the forwarded response. However, a proxy would only populate the = Client-Txn field when creating a log record corresponding to a request.