Subject: Re: [sip-clf] Problem Statement - Source/Dest Fields & Contact

From: Peter Musgrave <[email-masked]>
Date: Wed, 6 Oct 2010 12:54:56 -0400

I think this may hinge on what the semantics are for SRC/DST. I view
these as a way of telling me where the message *actually* came
from/was sent.

So if e.g. a message comes through a NAT - which fails to update the
Via then I would see the public IP of the NAT in the L3 IP address as
the src and this would allow me to see why things are breaking.

The From is free to tell me the logical entity sent the message -
either as a DNS name or IP address. The contact would tell me the
specific instance which sent it.

(Which is why I am in favour of making logging the Contact part of the
mandatory fields).

Peter
(as individual)

On Wed, Oct 6, 2010 at 12:49 PM, Brian Trammell <[email-masked]> wrote:
> Hi, Vijay,
>
> One clarifying question below.
>
> Cheers,
>
> Brian
>
> On Oct 6, 2010, at 6:37 PM, Vijay K. Gurbani wrote:
>
>>Since SIP is an application-layer protocol, DNS names are always
>>available.  That said, I do realize that IP addresses are used quite
>>a bit SIP today, but I would not like to impose this as
>>a requirement to the SIPCLF mechanism.
>
>>For reasons why, let's look at generating SIPCLF records at a proxy
>>since it is the most general of the SIP entities and consumes both
>>the UAC and UAS halves of the SIP transaction.
>
>>The case of mandating IP addresses is more strong on the UAS
>>side.  When a UAS gets a request the topmost Via header
>>may contain the DNS name in the host production rule.  On the
>>chance that NATs were involved, rfc3261 exhorts implementations
>>to add a "received" parameter to the topmost Via header.  So it
>>seems reasonable to log IP addresses for a UAS.
>
>>However, the case for mandating IP addresses is not as clear on
>>the UAC side.  A UAC will execute rfc3263 resolution on the SIP
>>AUS (the R-URI, in essence.)  R-URIs will mostly be identifiers
>>of the form sip:[email-masked].  It seems reasonable (and certainly
>>more readable) to allow the logging of the DNS name corresponding to
>>the server that resulted from rfc3263 resolution on the SIP AUS.
>
> Wait... SIP still runs over IP, right? The UAS/UAC has to have
> received the packet that triggers the log message from somewhere. And
> that packet will have an IP address on it. _That_ is the (source) IP
> address to log, and the destination address would be the address of
> the interface on which it was received. Vice-versa in the case of sent
> messages. Not sure where DNS lookups come in here. The R-URI is still
> logged, in its own information element / field...
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 6 Oct 2010 18:49:59 +0200

Hi, Vijay,

Cheers,

Brian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Oct 2010 12:02:49 -0500

Hello Brian:

> received the packet that triggers the log message from somewhere.
> And that packet will have an IP address on it. _That_ is the (source)
> IP address to log, and the destination address would be the address
> of the interface on which it was received. Vice-versa in the case of
> sent messages. Not sure where DNS lookups come in here.

Right, SIP still runs over IP.  However, the difference in our
views is dominated by the lens --- IPFIX or indexed-ASCII --- that
we are using to look at this problem.

Since IPFIX operates at the IP layer, it is capturing packets
with populated source and destination IP addresses.  However, in
the view of the indexed-ASCII approach, a UAC can generate a SIPCLF
record the moment it is ready to send the SIP PDU to its transaction
layer.  That is, at that time, the UAC knows through rfc3263-resolution
which host the request is destined to, and it has both the IP address
and DNS name at its disposal.  Requiring it to only log IP address
seems an overkill.  Why not make it general enough that it can also log
the DNS name?

> The R-URI is still logged, in its own information element / field...

Note that the DNS name is different than the R-URI.  On the UAC side,
the R-URI is used to trigger which specific host the request is
destined to and in that sense, R-URI and DNS name of the specific host
are two distinct, though related, pieces of information.

Thanks,

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Oct 2010 12:15:05 -0500

> the src and this would allow me to see why things are breaking.

Peter: Note that it is not the NAT that updates the Via, but rather
the receiving SIP entity updates the Via header and adds a
";received" parameter.  This is to ensure that responses go to
the right destination.  So in the SIPCLF record of received
requests, it makes sense to log IP addresses (as my earlier
email said as well.)

> specific instance which sent it.

The Contact is for subsequent requests and does not play into the
logging of the current transaction that is being handled.  So, more
concretely, assume a normal INVITE/200 OK transaction being logged
and then a subsequent ACK being logged.

The Contact header does not play any role in logging the INVITE/200 OK
SIPCLF records.  It plays a role in logging the ACK SIPCLF record since
the ACK will be destined to the Contact header present in the 200 OK.
But the ACK is a separate request.

> (Which is why I am in favour of making logging the Contact part of the

I remain unsure on the juxtaposition of the Contact with the
logging of the SIPCLF record.  Maybe I am missing something.  The
Contact is useful to log as a piece of information, but it does not
have any bearing on transactional identification, nor does it have
any bearing on dialogue identification.  For the dialogue 
identification, the From header plus the URI is more important.

Thanks,

- vijay

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 6 Oct 2010 13:29:03 -0400

Hi Vijay,

I took your remark to keep the "DNS or" for src/dst as a desire to not
have just IP.

To be clear -  when you are saying DNS you expecting the value to come
from the top-most via (i.e. written by the stack) or from the packet
IP L3? (I can't think of a case where these could be different
underlying IPs - other than a flawed implementation. Did I miss
anything?) The Via could have a DNS entry, the L3 would require a
reverse DNS to get one.

As for Contact - yes I agree it is not part of the current
transaction. However, in looking at logs to debug issues I am
constantly finding Contact headers which did not get NATed - and this
is the reason why a subsequent transaction fails. This occurs often
enough that I am in favour of logging this by default. I can live with
it as an extension if there is not broader support for this.

Peter
(as individual)

On Wed, Oct 6, 2010 at 1:15 PM, Vijay K. Gurbani <[email-masked]> wrote:
> any bearing on dialogue identification.  For the dialogue identification,
> the From header plus the URI is more important.
>
> Thanks,
>
> - vijay
> --

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Oct 2010 13:24:57 -0500

On 10/06/2010 12:29 PM, Peter Musgrave wrote:
> Hi Vijay,
>
> I took your remark to keep the "DNS or" for src/dst as a desire to
> not have just IP.

Peter: Right, allow for DNS names as well.

> To be clear -  when you are saying DNS you expecting the value to
> come from the top-most via (i.e. written by the stack) or from the
> packet IP L3?

Note that the topmost Via providing any information is only
pertinent to generating a SIPCLF record for an incoming request.
When a SIP server gets a request, it will populate the received
header from the source address of the packet.  And this is what gets
logged.  However, when sending requests, you have a choice of
logging the DNS name as well.

> transaction.

Right.

> However, in looking at logs to debug issues I am constantly finding
> Contact headers which did not get NATed - and this is the reason why
> a subsequent transaction fails. This occurs often enough that I am in
> favour of logging this by default. I can live with it as an extension
> if there is not broader support for this.

I am okay either way.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Oct 2010 12:08:53 -0400

> it as an extension if there is not broader support for this.

I'm sympathetic to the Contact being interesting for REGISTER requests, but so is the Via and Path, and that kinda shows the problem we keep running into: what is the purpose of the SIP-CLF really?  

If it's for actual, direct troubleshooting and debugging, then it doesn't have nearly enough info and frankly the only thing that will is a pcap-type log of the whole message.  We don't need a new format for that. (Well, arguably we do, but the IPFIX group is quickly going down that path already, even if they don't mean to)

ISTM that the real value of SIP-CLF is:
a) a log that doesn't need a SIP parser (SIP code) to read
b) small size entries, to reduce file sizes and performance impacts
c) enables calculating SIP traffic stats/trends/patterns
d) let's you see that something has gone wrong - not what the root cause is (i.e., not that header X has a wrong param Y), but instead that a request got rejected/timed-out or got routed to the wrong place, for example.  Then you need enough info in the log for that event that you can turn on detailed logging (pcap-style and system logs) for that particular scenario to try to determine the root cause when it happens again.  In other words, the value of SIP-CLF is to record as little as possible but enough to determine something's gone wrong and who it happened to, in order to drill down on that. 

So the question is: do you really need Contact-URI for that?  Isn't the To-URI of the REGISTER enough to go drill-down and figure out why a later INVITE to that AoR failed?  I don't know the answer.  Maybe we really do need the Contact, just so we can figure out the INVITE that was sent to it (i.e., match the request-URI of the INVITE to the Contact of the REGISTER).  One "issue" with this, though, is there could be multiple Contacts in a REGISTER (and none in a MESSAGE request, though that's easy to deal with).  So far every mandatory field we have is inherently single-instance.

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 7 Oct 2010 12:39:49 -0400

Hi Hadriel,

I take your point that in the end serious debugging will require more
info than sipclf generates.

The problem statement does state that it may be useful for "cursory
troubleshooting" but make no assertion that it it be useful for "deep"
debugging.

In the spirit of those statements, I agree that making Contact
mandatory is not necessary.

Peter

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 13:32:55 -0500

> mandatory is not necessary.

Peter: I think that is reasonable.

Thanks,

- vijay