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

From: Peter Musgrave <[email-masked]>
Date: Fri, 1 Oct 2010 07:23:20 -0400

Hi all,

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

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

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.

Regards,

Peter Musgrave
(as individual)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Oct 2010 11:37:17 -0500

> Hi all,

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

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

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

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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 6 Oct 2010 13:46:55 -0400

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:

> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

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

On 10/06/2010 12:46 PM, Hadriel Kaplan wrote:
> 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.

Hello Hadriel: Sure, the above is true of anything that uses IP not
only SIP.  But I think we are talking over each other based on what you
write below ...

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

Nowhere have I made a case for implementations to log DNS names on
received requests; indeed, as you noted that will mean a lot of
reverse DNS lookups with more latency and increased load, etc.

Instead, all I am doing is making a case for logging DNS names for
UAC side of the SIPCLF equation.  Here, you have taken a SIP AUS and
converted it to a specific {IP, port, transport} tuple using rfc3263.
The request is going to a server on that tuple, as are all
retransmissions.  Why can't we allow the logging of the DNS name for
SIPCLF records resulting from sending a request downstream?

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 6 Oct 2010 15:34:45 -0400

Oh... sure you can log whatever you want - I mean both formats support extending it with non-mandatory formats.
The questions' really what is *mandatory* to record, no?

Logging the DNS name is fine, but that's a different field/info than the IP - even for a UAC, it can log the DNS name, but that shouldn't relieve it of logging the dest/src IP.  The DNS name would just be another, additional field on top of that (which should not be mandatory, methinks).  Just like it could log a P-Asserted-Identity header, or the phase of the moon. :)

-hadriel

---

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

On 10/06/2010 02:34 PM, Hadriel Kaplan wrote:
> Oh... sure you can log whatever you want - I mean both formats
> support extending it with non-mandatory formats. The questions'
> really what is *mandatory* to record, no?
>
> Logging the DNS name is fine, but that's a different field/info than
> the IP - even for a UAC, it can log the DNS name, but that shouldn't
> relieve it of logging the dest/src IP.

I dunno ... I think logging the FQDN (or DNS) name is preferable
if you have it.  After all the machinations of rfc3263, you will
still end up with a A RR.

All I am saying is that if you are generating SIPCLF records at
the SIP application layer, and you have the FQDN information
on a request going downstream, then why should we preclude
implementers from using it?  If they want to substitute the IP
address, sure, they can do so. But why mandate it?  I don't
understand.

Thanks,

- vijay

---

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

Hi

I had assumed we were down at the transaction layer (since we log retransmits). I think the src/dst log should be as close to the wire as it can be. I may not even know if i went out as IP4 or IP6 if I log out the dst as a FQDN...

I would like to see L3 ip sec/dst as required and a fqdn for the same could be optional.

Peter
(as individual)

Sent from my iPad

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Oct 2010 16:10:48 -0500

On 10/06/2010 03:41 PM, Peter Musgrave wrote:
> I had assumed we were down at the transaction layer (since we log
> retransmits).

Implementations are different, I don't think we should make any
assumptions on how they are architected.  Someone may have a pointer
to the data structure containing information of the SIP client
transaction even at the transaction layer, or someone may provide the
FQDN as a string array to the SIP structure passed to the the
transaction layer, allowing the transaction layer to use it as it sees
fit.

> I think the src/dst log should be as close to the wire
> as it can be. I may not even know if i went out as IP4 or IP6 if I
> log out the dst as a FQDN...

True, but that is only a problem if your host changes IP versions
periodically or if it is multi-homed and has both A and AAAA DNS RRs.
The former probably does not happen too much, the latter is a definite
possibility.

> I would like to see L3 ip sec/dst as required and a fqdn for the same

Sure, that is not a problem.  I just did not want us to completely
preclude the population of the src/dest fields with FQDNs.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 6 Oct 2010 17:34:15 -0400

> preclude the population of the src/dest fields with FQDNs.

I think this is where we're disagreeing - you're talking about populating a generic "src" and "dest" fields with different data types, whereas we're talking about having an "IP-src" and "IP-dst" fields, and optionally also encoding a separate "Domain-Name-src" and "Domain-Name-dst" fields.

There's a really good reason to separate them out (other than just that they're semantically and syntactically different): if you have a domain name, you should STILL record the IP address.  A Domain name isn't a unique identifier.  It can resolve to multiple IP's, of different address families, and the point is to record which specific one you received the message from or sent it to.

-hadriel

---

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

On 10/06/2010 04:34 PM, Hadriel Kaplan wrote:
> There's a really good reason to separate them out (other than just
> that they're semantically and syntactically different): if you have a
> domain name, you should STILL record the IP address.  A Domain name
> isn't a unique identifier.  It can resolve to multiple IP's, of
> different address families, and the point is to record which specific
> one you received the message from or sent it to.

Hadriel: OK, help me understand this.

I have a AUS of sip:[email-masked] (I pick Columbia because
they have populated SRV RRs.)

$ host -t NAPTR columbia.edu
columbia.edu has NAPTR record 1 0 "s" "SIP+D2U" "" 
_sip._udp.sip.columbia.edu.
$ 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.
$ host -t A cocoa.cc.columbia.edu
cocoa.cc.columbia.edu has address 128.59.59.199
$ host -t A eclair.cc.columbia.edu
eclair.cc.columbia.edu has address 128.59.59.79

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.  The ultimate host I sent the request to was
either cocoa.cc.columbia.edu or eclair.cc.columbia.edu.  Both
of these hosts have a distinct IP address that do not change
(unless administratively mandated.)

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 6 Oct 2010 19:45:29 -0400

> (unless administratively mandated.)

Because in your case "eclair.cc.columbia.edu" happened to return one A record.  It doesn't have to.

Here's one for another hostname:
Hadriel-MacBook:~ hadrielk$ dig -t A lb1.www.ms.akadns.net

; <<>> DiG 9.6.0-APPLE-P2 <<>> -t A lb1.www.ms.akadns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1620
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;lb1.www.ms.akadns.net.		IN	A

;; ANSWER SECTION:
lb1.www.ms.akadns.net.	143	IN	A	207.46.170.10
lb1.www.ms.akadns.net.	143	IN	A	207.46.170.123

;; Query time: 0 msec
;; SERVER: 10.0.111.115#53(10.0.111.115)
;; WHEN: Wed Oct  6 19:13:13 2010
;; MSG SIZE  rcvd: 71

And per RFC 2782 (which RFC 3263 uses), for the SRV target field:
   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 6 Oct 2010 22:00:00 -0400

BTW, I'm not arguing just to be difficult or pedantic - in deployed IMS networks the servers often return multiple address records.

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 7 Oct 2010 06:08:41 -0400

Hi Vijay, Hadriel,

The multiple A lines is a good point.

Can I suggest the src/dst in the mandatory block be the IP address
from L3 and that additional info (such as a list of potential DNS
records returned etc.) could be logged as extensions?

Peter
(as individual)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 08:09:41 -0500

> A record.  It doesn't have to.

Hadriel: I am aware that rfc2782 allows multiple address records
to be returned, but it does not constrain the address records to
be of the same type.

In other words, if you are doing SRV lookups, why would you want
to return multiple A records for the resolution of the target?
Normally, multiple A records are used to do some sort of round-robin
DNS balancing, which is what you show with the DNS lookup of
lb1.www.ms.akadns.net.  SRV provides far more fine grained control
on load balancing, so why would one want to load up multiple A
for a target when using SRV?  I don't understand.

I suspect that the intent of rfc2782 was to allow multiple address
records of different type to be returned, i.e., a target can
have a A and AAAA record, for instance.

In an subsequent email, Hadriel Kaplan wrote:
 > BTW, I'm not arguing just to be difficult or pedantic -

I understand, no worries.

 > in deployed IMS networks the servers often return multiple address
 > records.

I don't think majority of IMS networks are using SRV today.  They
probably populate multiple A records and do round-robin load balancing
to access their P-CSCFs.  If there are DNS records used in deployed IMS
networks today that use SRV but populate multiple A records for a
target, I'd like to know about them (because in that case, the point I
am trying to make is moot.)

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 08:18:31 -0500

> The multiple A lines is a good point.

Peter: Please see my follow-up email from this morning.

If indeed it is the case that there are IMS SIP networks in
use today that do SRV resolution --- not round-robin DNS ---
on a SIP AUS but return multiple A records, then my point is moot.

> records returned etc.) could be logged as extensions?

I still remain unsure on why we cannot simply leave it implementation-
defined and why we want to impose a raw IP address?  Depending
on where you are generating the SIPCLF record, you will have access
to only one or both.  Let the implementer decide.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Oct 2010 10:10:32 -0400

> for a target when using SRV?  I don't understand.

Heck, I don't know *why* some of them do what they do. :)
I assume they put in an SRV for each host, but these are multi-interface hosts.  They love multi-interface hosts in IMS networks. (for example, for doing SCTP) 

> am trying to make is moot.)

I believe one example of someone doing this would be your company's largest IMS customer in North America, with your server's IPs. (although I could be remembering that one wrong)  I only know people do it because my company's systems weren't handling that case the way they wanted us to a few years ago, and had to fix it.

And actually, now that I think of it, why would even having multiple A records for the same hostname for round-robin load-balancing not also be a problem?  Once again you can't simply record the hostname/domain-name for that case either - SIPCLF needs to record the IP Address.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Oct 2010 10:21:43 -0400

> to only one or both.  Let the implementer decide.

I cannot imagine a SIPCLF implementation that knows the request-URI and CSeq and such but does not also know what Layer-3 IP Address the packet came-from/is-going-to.  And if one could be made, I'd argue it's not a very _useful_ SIPCLF recorder.

But anyway how about this: let's imagine you want to record BOTH, because you have 'em.  How would you record both in ascii-clf?  Which one would you put in the mandatory field?  Let's say you picked DNS in the mandatory field, and added the IP in an extension, while I did the opposite.  Now the reader of these files has different semantic and syntactic information in one of two different field locations, depending on vendor. 

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 7 Oct 2010 10:44:57 -0400

Hi Vijay,

I am very reluctant to leave this implementation defined.
- if we can be specific in a draft, we should be
- in some implementations (IPFIX) this could affect what kind of field
is used for the mandatory entry
- I regard having the basic L3 "where the packet came from/went to" a
basic and essential item of information when debugging using logs

Is there a specific reason for wanting DNS if it available? (And would
it be a unique DNS name not found in the reqUri, To or From)?

I continue to believe the IP should be mandatory - and if a DNS name
is desired it can be in the extension info.

Also, the problem statement specifies "SIP CLF operates natively at
the transaction layer ..." (5.1). I had taken this to mean it was
logging at the level of the transaction state machines as per section
17 of RFC3261. Hence my view the logging is "close to the wire".

Regards,

Peter

---

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

On 10/07/2010 09:10 AM, Hadriel Kaplan wrote:
> I assume they put in an SRV for each host, but these are
> multi-interface hosts.  They love multi-interface hosts in IMS
> networks. (for example, for doing SCTP)

... and having NAPTR return a _sip._sctp.example.com is just as easy.

> I believe one example of someone doing this would be your company's
> largest IMS customer in North America, with your server's IPs.
> (although I could be remembering that one wrong)

Hey, that's not fair ;-)  I think you are remembering it wrong ;-)

> And actually, now that I think of it, why would even having multiple
> A records for the same hostname for round-robin load-balancing not
> also be a problem?  Once again you can't simply record the
> hostname/domain-name for that case either - SIPCLF needs to record
> the IP Address.

Yes, I will concede that round-robin DNS makes a stronger case for
logging an IP address, but again, let the implementer decide.  Why
mandate ONLY raw IP addresses?  Not all deployments use round-robin
DNS.

Ciao,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 10:34:06 -0500

On 10/07/2010 09:21 AM, Hadriel Kaplan wrote:
> I cannot imagine a SIPCLF implementation that knows the request-URI
> and CSeq and such but does not also know what Layer-3 IP Address the
> packet came-from/is-going-to.  And if one could be made, I'd argue
> it's not a very _useful_ SIPCLF recorder.

First of all, the "packet came from" is not at issue.  I agree
that for inbound packets, doing reverse DNS is not a good
solution simply to log the host name.

At issue is whether a recorder knows the host name associated
with that IP address to which a request is destined, and if
so, should it log that host name instead?

In IPFIX, packets are picked off the network, right?  When a UAC
sends a request after doing rfc3263 resolution, all that is
available at the packet level is the destination IP address in
the IP header, not the target of the host used in the resolution.
That information is lost at the packet level, and the R-URI of
the request is not a substitute for it.

In indexed-ASCII, a recorder will have both pieces of information ---
the Layer-3 IP address and the target host name (and before someone
else  flames me that I am saying that the indexed-ASCII is better, let
me pre-emptively and categorically be clear that I am not making a
judgement call.  I am merely question above.)

> But anyway how about this: let's imagine you want to record BOTH,
> because you have 'em.  How would you record both in ascii-clf?  Which
> one would you put in the mandatory field?  Let's say you picked DNS
> in the mandatory field, and added the IP in an extension, while I did
> the opposite.  Now the reader of these files has different semantic
> and syntactic information in one of two different field locations,
> depending on vendor.

The reader of the file reads a sequence of bytes encoded as
pointer/length pairs.  The fact that these bytes contain a host name
or an IP address does not matter.  The semantic accorded to the
destination field in the SIPCLF record is that it can contain a host
name or an IP address.  Simple.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 11:05:06 -0500

> is used for the mandatory entry

Peter: If we make it an either-or decision, IPFIX can continue logging
raw IP addresses.

> basic and essential item of information when debugging using logs

DNS names are just as useful in debugging, sometimes more than IP
addresses.  Again, I will concede that round-robin DNS makes a
stronger case for logging an IP address, but not all deployments use
round-robin DNS.

> it be a unique DNS name not found in the reqUri, To or From)?

The domain names in To, From are not of importance to SIPCLF.  It is
the resolution that results from rfc3263 lookup of the SIP AUS.

> is desired it can be in the extension info.

I am afraid I'll have to respectfully disagree.  I think the
notion of only raw IP being mandatory is rather restrictive.
In the end it is a sequence of bytes of certain length.  The
semantic accorded to this sequence of bytes is that it can be an
IP address or a DNS name.

> 17 of RFC3261. Hence my view the logging is "close to the wire".

I pointed out earlier that we should not make any assumptions about
how a particular piece of software is architected.  It may very well
be that the information on the target lookup is available at the
transaction layer.  If it is, why not log it?

In the end, you as the chair have the unenviable task to determine
if rough consensus has been reached.

I have made my case that we should allow for the logging of either
names or IP addresses.  Recorders that pull SIP packets off
the wire will most probably log raw IP addresses.  Others that log
in the application itself can have more flexibility, and we
should not inhibit this aspect.

I will abide by any decision made through our consensus processes,
of course; although I will like to at least indicate my preference for
allowing both the formats to be logged.  The cost to doing so is low,
I believe.

Thanks,

- vijay

---

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

I can understand the desire to have a DNS name if it's available and
unique - but I still prefer an IP address.

I guess we're not likely to persuade each other.

I also am happy to go with the consensus view on this issue.

Can we get more opinions?

Should src/dst field in the mandatory logging be
1. DNS OR IP address (implementors choice)
2  IP address only

Thanks,

Peter Musgrave
(as individual)

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Oct 2010 13:27:06 -0400

> so, should it log that host name instead?

No, that's not really the issue.  Nobody's saying "you must not record the hostname".  What we're saying is "you must record the IP Address, and may optionally *also* record the hostname separately".

It's that word "instead" you used above that's the issue.  That implies the same *field* carries two different types of information.  And it's not just syntactically different fields - they're *Semantically* different.  A Layer-3 IP destination address is unambiguous when we say it's the layer-3 IP.  But using a hostname is _ambiguous_: which hostname is it?  Is it the input into the 3263 process (ie, the domain portion of the target URI), or is it an intermediate step of 3263? or if 3263 isn't used, is it one from a local-policy of proxy-routing which might use a hostfile instead of 3263/DNS?  In other words, can the reader of the file know which hostname it is without knowing the internals of the recorder?

> name or an IP address.  Simple.

No, not simple.  The semantic of the IP Address field is one of being a Layer-3 IP.  For example, getting the layer-3 IP in a SIP-CLF lets me go create an ACL or BPF for that... to block or capture packets from it in more detail, for example.  You can't do that with a hostname.  Furthermore, it means in a database/table storing the individual fields I have to have a string or blob or complex type instead of a uint32[4] for ip.  And it also means my reader/tool/grep has to deal with determining which type it is (ip vs hostname) by its content instead of by it's position or type value.

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Oct 2010 14:06:02 -0500

On 10/07/2010 12:27 PM, Hadriel Kaplan wrote:
> No, that's not really the issue.  Nobody's saying "you must not
> record the hostname".  What we're saying is "you must record the IP
> Address, and may optionally *also* record the hostname separately".

No surprise, I disagree on the word "separately" above ;-)

> It's that word "instead" you used above that's the issue.  That
> implies the same *field* carries two different types of information.
> And it's not just syntactically different fields - they're
> *Semantically* different.  A Layer-3 IP destination address is
> unambiguous when we say it's the layer-3 IP.

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.

> But using a hostname is _ambiguous_: which hostname is it?  Is it
> the input into the 3263 process (ie, the domain portion of the
> target URI), or is it an intermediate step of 3263? or if 3263 isn't
> used, is it one from a local-policy of proxy-routing which might use
> a hostfile instead of 3263/DNS?  In other words, can the reader of
> the file know which hostname it is without knowing the internals of
> the recorder?

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

> No, not simple.  The semantic of the IP Address field is one of being
> a Layer-3 IP.  For example, getting the layer-3 IP in a SIP-CLF lets
> me go create an ACL or BPF for that... to block or capture packets
> from it in more detail, for example.

Yes, you can do that but if the IP address was re-assigned by DHCP
you will inadvertently block good traffic.

> You can't do that with a hostname.  Furthermore, it means in a
> database/table storing the individual fields I have to have a string
> or blob or complex type instead of a uint32[4] for ip.  And it also
> means my reader/tool/grep has to deal with determining which type it
> is (ip vs hostname) by its content instead of by it's position or
> type value.

The position is invariant irrespective of the contents, so I do not
see why the reader/tool/grep cannot simply interpret it.  If you
want to store the SIPCLF record contents in a database, yes, you'd
have to do a bit more work, but by no means is this extra work
a showstopper, is it?

Thanks,

- vijay

---

From: Saverio Niccolini <[email-masked]>
Date: Thu, 7 Oct 2010 19:29:12 +0000

2  IP address only

Cheers,
Saverio

> > allowing both the formats to be logged.  The cost to doing so is low,

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
NEC*NET Phone: 800-49-33-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Oct 2010 17:20:31 -0400

> 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:[email-masked], and sends it to her local proxy.  The Proxy's target URI is "sip:[email-masked]".  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.

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

> 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 08 Oct 2010 11:17:29 -0500

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:

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:[email-masked], and
> sends it to her local proxy.  The Proxy's target URI is
> "sip:[email-masked]".  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.

> 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