[sip-clf] AD review: draft-ietf-sipclf-problem-statement-07

Robert Sparks <rjsparks@nostrum.com> Thu, 04 August 2011 21:05 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: sip-clf@ietfa.amsl.com
Delivered-To: sip-clf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4C62311E8078 for <sip-clf@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bZafdzIjwQK4 for <sip-clf@ietfa.amsl.com>; 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 <sip-clf@ietf.org>; Thu, 4 Aug 2011 14:05:49 -0700 (PDT)
Received: from [] (pool-173-71-50-10.dllstx.fios.verizon.net []) (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 <sip-clf@ietf.org>; Thu, 4 Aug 2011 16:06:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
From: Robert Sparks <rjsparks@nostrum.com>
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 <sip-clf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 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 <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=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 
   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 From record field that really belongs in
   other parts of the document. The From description should look like the To description. 
   The extra text pointing to whether the values in the URIs are trustable should be moved 
   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 '' in position 30; 
     draft-ietf-sipclf-problem-statement-07.txt(873): Found possible IPv4 address '' in position 30;
   Both of those should probably have been

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 
   to the actual SIP traffic, but does have access to the log files (especially in 
   real time), gets enough information to mount many of the attacks he would if he 
   were able to eavesdrop on the traffic. The paragraph encrypting SIP traffic is 
   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

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). 
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 
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 
does not see (and therefore will not log) the ACK".