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

[Hadriel Kaplan <[e-mail]>]

On Oct 7, 2010, at 3:06 PM, Vijay K. Gurbani wrote:
> 
> Unambiguous how?  In finding the exact host?  What happens if it
> was a DHCP address and re-assigned later on to someone else?  What
> does the unambiguity of an IP address get you then?  I don't think
> that just because we have a raw IP address, all other problems
> associated with that will simply vanish.

It's unambiguous in the sense that it identifies the server you sent the SIP Message to, at the time the record was generated.  Of course the IP could change at some later time (and hostnames can be reassigned), but there is no time-invariant identifier available.  It's not ambiguous to what it refers to, namely the layer-3 IP destination address - whereas if it's a hostname, it can have one of multiple meanings: the host-domain portion of the target URI, the target name of an SRV response entry, or a hostname from a local policy.

For example, Alice generates a "INVITE" to sip:[e-mail], and sends it to her local proxy.  The Proxy's target URI is "sip:[e-mail]".  It generates a NAPTR for "voip.ssp.com", which returns an entry for "_sip._udp.voip.ssp.com".  It does an SRV lookup of that and gets "sip-access.voip.ssp.com", with A records for 1.1.1.1 and 1.1.1.2.  Does it encode "voip.ss.com" or "sip-access.voip.ssp.com"?  
Suppose instead, voip.ssp.com did not have a NAPTR entry nor SRV, so it performs an A/AAAA lookup for "voip.ssp.com" (per 3263 section 4.2).  Does it encode "voip.ssp.com" as the destination this time?
Now suppose instead the proxy has a local policy to use an on-box hosts-file, which has an entry for "voip.ss.com" to IP Address 2.2.2.2, bypassing 3263.  Does it encode "voip.ss.com"?  

In all the cases above, none of the domain names are the "Destination" next-hop server.  They're domain names.  They're just names used to resolve to a destination.  They may be hostnames, or sub-domain names, or whatever.

Don't get me wrong - I'm not against recording a domain name - I just think it's of a different "type" than a destination IP Address, and not the same field.  I mean it doesn't represent the same ultimate property.  You're losing important details by replacing one with the other, because they're not synonymous.


> First off, I never claimed that an intermediate step of rfc3263 be
> used as a DNS name, it is the target name that is of interest here.

Umm... but you did. :)
You said: "I am making a case to log the final (resolved) DNS name ---
either cocoa.cc.columbia.edu or eclair.cc.columbia.edu,
NOT columbia.edu."

Those names are actually from a step in the middle of RFC 3263, afaict.  The input to RFC 3263 is the SIP Target URI ("sip:columbia.edu" in your example).  The "TARGET" name in 3263 is the host-domain portion of that, "columbia.edu" in your example.  The output of 3263 is the triple {transport protocol, port, IP address}.  Not a name received in an SRV.  "cocoa.cc.columbia.edu" was just from one of the possible middle steps inside 3263.  No?


> Second, if the name is taken from a hostfile instead of rfc3263/DNS,
> then what difference does it make?  The contents of the hostfile are
> pertinent to and of interest to the administrative domain
> interpreting the SIPCLF log file since we are not claiming that log
> files be sent from one domain to another.

Because a hosts-file, like DNS, is just a mapping from a name to one or more IP Addresses - the name it maps from is *not* actually guaranteed to be a "hostname" of a specific server/next-hop.  It's just a name.  And what's worse, hosts-files are famous for being wrong or maliciously subvert-able, so if the SIP-CLF only records the domain name, you can't tell the UAC is actually sending the Message to the wrong place.

-hadriel