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

"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 06 October 2010 16:34 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A14F3A70E8 for <sip-clf@core3.amsl.com>; Wed, 6 Oct 2010 09:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.463
X-Spam-Level:
X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkmIMiQNnR-t for <sip-clf@core3.amsl.com>; Wed, 6 Oct 2010 09:34:37 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id EBD493A70F3 for <sip-clf@ietf.org>; Wed, 6 Oct 2010 09:34:36 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o96GZWuu010907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2010 11:35:32 -0500 (CDT)
Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o96GZVrc000810; Wed, 6 Oct 2010 11:35:32 -0500 (CDT)
Message-ID: <4CACA5BD.7080807@bell-labs.com>
Date: Wed, 06 Oct 2010 11:37:17 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
MIME-Version: 1.0
To: Peter Musgrave <peter.musgrave@magorcorp.com>
References: <AANLkTime-SfqMydvu8gKENvk=iBZsNq_q_4J-DpTh1aX@mail.gmail.com>
In-Reply-To: <AANLkTime-SfqMydvu8gKENvk=iBZsNq_q_4J-DpTh1aX@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: List SIP-CLF Mailing <sip-clf@ietf.org>
Subject: Re: [sip-clf] Problem Statement - Source/Dest Fields & Contact
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 06 Oct 2010 16:34:40 -0000

On 10/01/2010 06:23 AM, Peter Musgrave wrote:
> Hi all,

Peter: Catching up with pending email.  Please see inline.

> In the problem statement/datamodel the source/dest information is
> listed as "DNS name or IP address".  This is for the upstream node/NIC
> which received it (and not the eventual destination covered by the AOR
> in To/From).
>
> As I implemented both formats I had assumed this was an IP address
> (and in the IPFIX format this is explicit). In the indexed ascii doc
> example it is a DNS name - the same as the AOR [Aside-I'd suggest we
> make it different simply so the example covers the general case].
>
> In typical implementations I would expect the logger to look at the IP
> headers to get source/dest information. I would not expect the DNS
> name to be available (unless a reverse DNS lookup is performed).

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:user@example.com.  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.

> Q: Can we remove the "DNS or" phrase and mandate that source/dest be
> an IP address?

My preference would like to preserve the "DNS or" phrase if possible.

> Also, since I'm on the topic of IP addresses...
>
> Do we think that the logging of the Contact: header should be
> mandatory (when the header is present)? I find I am constantly
> checking Contact  headers in cases where Nat traversal is involved to
> confirm things are not FOOBAR.

Earlier versions of the the pure ASCII draft [1] carried the
Contact header in the SIPCLF record.  However, the indexed approach
[2,3] makes that a TLV field.  I don't have any specific leanings
one way or the other on whether or not we make the Contact field
mandatory, although I do have a slight preference for leaving it
as a TLV field (as it is in [3].)

[1] http://tools.ietf.org/html/draft-gurbani-sipping-clf-01
[2] http://tools.ietf.org/html/draft-roach-sipping-clf-syntax-01
[3] http://tools.ietf.org/html/draft-salgueiro-sipclf-indexed-ascii-01

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/