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

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Aug 2011 16:06:04 -0500

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

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Aug 2011 16:30:46 -0500

(As an individual contributor)

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