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

["Vijay K. Gurbani" <[e-mail]>]

On 08/04/2011 04:06 PM, Robert Sparks wrote:
> Summary: There are a few issues to address before IETF LC

Robert: Thank you for your extensive review and suggestions for
cleaning up the document.  I apologize on attending to your
comments after a delay, but nonetheless, please see inline
for more discussions.

I will submit a revision as soon as the blackout period for
submitting new I-Ds is lifted on Nov-14.

 > 1) Shouldn't this document be titled something like "framework and
 > data model"?

We could do so; however, here's a quick history on the draft ... it
started off life as a problem statement plus solution rolled in one.
As the work progressed on this, it was deemed more beneficial to
address issues such as transport and a data model.  Then it was decided
to spin off the representation format in at least one, possibly two,
different drafts and have a framework-type approach specified in this draft.

Through all this, the title of the draft remained as an artifact from
its origins.  If you'd like me to change it to reflect the framework and
data model part, I can easily do so.  I do not know whether changing the
title of a draft midstream will cause any problems to the tools that
track the draft, but if not, I have no problem changing the title.  As
I understand it,the name of the draft must remain the same ---
draft-ietf-sipclf-problem-statement.

 > 2) Why does this document talk about the 4096 byte limit? Shouldn't
 > this be moved to the encoding draft?

The consensus to put a 4096 byte limit was reached during WG
deliberations (see thread starting at [1]).  What was decided during
this thread was that the problem-statement draft would mandate a
4096 byte limit on a SIP record, including bodies.  However, whether or
not to log a complete body is left up to the specific representation
draft.  Thus, this 4096 byte limit applies to the existing indexed-
ASCII representation draft as well as any other representational
draft that comes along.

 > 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

OK, fair enough.  I will adopt the text you had suggested in a follow-up
email to the list [2], modified slightly to read as follows (this text
will replace Table 1 in the current draft):

   In the following cases, an element will not have an appropriate
   value to provide for one of these fields, even though the field
   itself is mandatory and must appear in the SIP CLF record.  For
   these cases, the representation document MUST define how to
   represent such "not applicable" values.  For example, the R-URI
   field is not applicable when logging a response, the Status field
   is not applicable when logging a request, the To-tag is not known
   when a request is first sent out, etc.

   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 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.

 > 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"?

Yes.

 > (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.)

As to why we chose a "-" instead of an empty string --- having a
printable character appear where an element would have normally
appeared if it were present is visually helpful for the system
operators who are observing the SIP CLF records on the screen.

 > 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.

Changed as suggested.  The prose in From is a holdover from early stages
of the work.  To be sure, the changes made reflect the From header
prose to be like the To header prose; the text on the utility of the
value for separating first or third party registrations has been
removed as has the text pointing whether the values in the URIs are
trustable (determining trust is not a matter for this draft).

 > 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;
 > 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?

Yes, indeed.  I will correct these.

 > 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

Good point.  I will modify the text as follows:

OLD (Section 9):
   o  An attacker may mount a replay attack by modifying existing
      records in the log file or inserting new records;

NEW (Section 9):
   o An attacker who is unable to eavesdrop real-time SIP traffic
     on the network but nonetheless can access the log file, is able to
     easily mount reply attack or other attacks that result from channel
     eavesdropping.  Encrypting SIP traffic does not help here because
     the SIP entity generating the log file would have decrypted the
     message for processing and subsequent logging.

 > 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 unencrypted.

Another good point.  The modifications above (last sentence) contains
some text to warn the reader of this as well.

You had a bunch of nits in the remaining email; I will incorporate
these as specified.

[1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00228.html
[2] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00510.html

Thank you so much for your review.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/