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

["Vijay K. Gurbani" <[e-mail]>]

On 10/07/2010 04:20 PM, Hadriel Kaplan wrote:
> 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.

Hadriel: Our disconnect is that you seem to think that I want
to log the host-domain portion of the target URI --- I do not.  I
am pushing for logging the Target field of the SRV lookup, which
will correspond to one IP address.  To be more specific, the last
field in the output below:

$ host -t SRV _sip._udp.sip.columbia.edu
_sip._udp.sip.columbia.edu has SRV record 10 10 5060 cocoa.cc.columbia.edu.
_sip._udp.sip.columbia.edu has SRV record 10 10 5060 eclair.cc.columbia.edu.

Now, I realize that you have made a case that the DNS lookup of
the Target field may result in multiple RRs.  However, my
contention is that the multiple RRs are of different types (e.g.,
A and AAAA) and not multiple RRs of A (a la round-robin DNS).

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

Why do you presume that a A lookup for a Target returned on a SRV
search will result in multiple A records.  If the service provider
wanted to do load balancing, multiple SRV records are a much better
option than to have multiple A records corresponding to a SRV target.

> Does it encode "voip.ss.com" or "sip-access.voip.ssp.com"?

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?

Yes.  Because anyone doing a DNS lookup on voip.ssp.com will get
the IP address (again, assuming round-robin DNS is not being used.
I don't think round-robin DNS for SIP servers is very prevalent,
and from what I understand there are other problems with round-robin
DNS as well.)

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

Yes.  Whoever analyzes the logfile is not going to do so in isolation.
I presume that they will be aware that the DNS resolution was done in
the context of local policy.

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

I am not replacing one by the other, I am making a case for logging
either format depending on what the implementer wants to do.

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

No.  columbia.edu is a high-level identifier used as input to
rfc3263; _sip._udp.columbia.edu and _sip._tcp.columbia.edu are
intermediary names,  but cocoa.cc.columbia.edu and
eclair.cc.columbia.edu are the final destinations to which the IP
packet is sent to over a certain transport and on a certain port.

The disconnect is that you assume multiple A RRs for
cocoa.cc.columbia.edu and I do not.

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

Whether or not an administrative domain decides to use host-files
is their prerogative.  If they do use them, they should understand
that any interpretation of the names in the SIPCLF records is a
function of their host-files.  Beyond that, I don't think there is
value in discussing host-files.

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/