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

[Hadriel Kaplan <[e-mail]>]

A DNS name is neither necessary nor sufficient.  It's not necessary because you don't need to have one to use SIP, whereas everyone needs an IP Address of some form or other.  It's not sufficient because a DNS name can resolve to multiple IP's (or even address families), and thus not be sufficiently unique or meaningful to log as the source/dest info.

And ultimately recording it as a DNS name requires the recording to be done at a high level of the SIP stack.  My receive parser, for example, may have no idea what the received message's  host DNS name is, but it always knows the IP (e.g., from the socket).  And lastly, it would require a lot of reverse DNS lookups, since we can't possibly trust the Via to be true/legit.

-hadriel

On Oct 6, 2010, at 12:37 PM, Vijay K. Gurbani wrote:

> 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:[e-mail].  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/
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf