Last Call Review of draft-ietf-sipclf-problem-statement-
review-ietf-sipclf-problem-statement-secdir-lc-barnes-2012-01-05-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document provides a set of goals and a data model for a "common logging
format" for SIP, in analogy to the widely-used Apache log format for HTTP.  As
the document correctly notes, the primary concern for this document is the
protection of potentially private data protected in such logs.  I do not think
that the document misses any serious security considerations.

A couple of relatively minor comments:

Section 5.1:
s/of a B2BUA/or a B2BUA/

Section 6:
It seems to me that the document would read better if this section were swapped
with Section 5.

Section 6:
You mention training anomaly-detection systems based on SIPCLF logs.  It seems
to me that this approach could be much more limited for SIP than it is for
HTTP, both because of the greater inherent diversity in SIP and because of
SIPCLF does not have visibility into the media path.  So it could be good to
comment on what these systems would and would not detect, either here or in the
Security Considerations.   Are you aware of any existing anomaly detection
systems that would be able to use SIPCLF data?

Section 8.1, Source-Address / Destination-Address:
These definitions are a little ambiguous.  I assume you mean the address of the
source/destination for a particular UDP/DTLS datagram or TCP/TLS connection, as
opposed to an address for a SIP-layer recipient.  For example, for an INVITE in
the following topology...
  UAC -> ProxyA -> ProxyB -> UAS
... If ProxyB were logging in SIPCLF, then the inbound invite would have
Source-Address=IP(ProxyA) and Destination-Address=IP(ProxyB).

Section 9.1:
It would be helpful to have SIP messages to refer to here, either by including
them in this document, or by referring to a document containing them, such as
RFC 3665.

Section 10:
It seems important to note here that both operators and users have private
information at stake here -- topology mapping vs. identity correlators and
calling patterns.

Section 10:
With regard to transmitting logs over the Internet, the reference to RFC 3552
is not very useful.  More concrete examples would be better, e.g., HTTPS, SSH. 
Might it also be possible/useful to convey SIPCLF messages over Syslog?