Subject: [sip-clf] draft-ietf-sipclf-format-01, Flag field

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 11:49:26 -0600

Hi
I will start writing one email for each issue in order to make it
easier to track the different discussions.

I would like to propose that the Flag Field is moved from the
<IndexPointers> to <MandatoryFields>. That way the <IndexPointers>
will be pure metadata that can be ignored if wanted and all interesting
data about the message is in the second line of the record.

Also I think it would be good to change the Sent/Received flag from

Sent/Received flag

         u = received UDP mesage
         t = received TCP mesage
         l = received TLS mesage
         U = sent UDP mesage
         T = sent TCP mesage
         L = sent TLS mesage

To
Sent/Received flag [1 byte]
         r = received message
         s = sent message

And add
Protocol [1 byte]
         u = UDP
         t = TCP
         l = TLS

Since the proposed CLF already requires quite a lot of space there is
little reason to
try to pack different parameters into the same byte.

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 14:38:06 -0400

> easier to track the different discussions.
Thanks. That should help.

> data about the message is in the second line of the record.
I have no real preference on this one. I'll let others weigh in with their thoughts.

> try to pack different parameters into the same byte.

This is what was proposed early on, but the group decided on consolidating the two. I'm not violently opposed or in favor of either, but I don't see any real benefit to separating the two out since all permutations are covered in a single easy byte.

Regards,

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

---

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 13:13:19 -0600

On Tue, Mar 15, 2011 at 12:38 PM, Gonzalo Salgueiro <[email-masked]> wrote:
> This is what was proposed early on, but the group decided on consolidating
> the two. I'm not violently opposed or in favor of either, but I don't see
> any real benefit to separating the two out since all permutations are
> covered in a single easy byte.

It is not a big deal but for instance if You want to find all sent messages it
is 3 tests instead of one for each record, (and if we add SCTP, see below),
then it would be 4. And when searching for all messages on a specific protocol
it is 2 tests instead of one.

A quick check found RFC 4168, "The Stream Control Transmission
Protocol (SCTP) as a Transport for the Session Initiation Protocol
(SIP)"

So maybe SCTP should be added as a protocol. I do not know if there is something
similar to TLS over SCTP, but I suspect things may get messy with a lot of
permutations in the future.

So maybe we should consider 3 parameters
send/receive    sent, received
protocol           tcp, udp, sctp
secure             encrypted, plain text

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 15:58:39 -0400

Anders - 

The notion of adding both SCTP and TLS the flag was brought up on the list back in October and it went unreplied to (far as I can tell). Here is the snippet:

Although, given that TLS can ride on top of UDP or TCP, we may want to think of a second letter added to "L" to
denote TLS-over-TCP and TLS-over-UDP (I doubt any implementations are using TLS-over-UDP for signaling only, but given that SCTP is starting
to appear in kernels, maybe our flags ought to be "u, t, s, lu, lt, ls, U, T, S, LU, LT, LS").

The fact that this is the second time this has been raised leads me to believe there is a need. I will raise this as a discussion topic in the upcoming meeting Prague.

Regards,

Gonzalo

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 15 Mar 2011 16:57:27 -0400

Hi, 

I am a fan of keeping separate things separate. So I agree transport and send/receive would benefit from being untangled (IIRC, I may be the one responsible for entangling them).

The transport field was intended to match the SIP transport protocol - so I think one byte for UDP, TCP, TLS, SCTP is ok. 

I don't see the need to have a separate security field (since we already have TCP/TLS sharing a byte) - so I would continue in the same vein. It's not a biggie for me - so if others want a secure/not secure byte that would be okay. 

Peter Musgrave
(as individual)

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 17:37:31 -0400

I agree Peter. Based on Ander's search example and some further thought on the matter has led me to the conclusion that we really do need to have these two separated. As far as the separate security field, I think it comes down to whether it is descriptive enough to say it is using TLS versus TLS over <blah>.

Gonzalo

---

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 16:01:32 -0600

On Tue, Mar 15, 2011 at 3:37 PM, Gonzalo Salgueiro <[email-masked]> wrote:
> I agree Peter. Based on Ander's search example and some further thought on
> the matter has led me to the conclusion that we really do need to have these
> two separated. As far as the separate security field, I think it comes down
> to whether it is descriptive enough to say it is using TLS versus TLS over
> <blah>.

Since TLS can be run over TCP, UDP or SCTP, (I don't know if all alternatives
apply for SIP), I think it may be useful to separate the transport protocol from
the encryption. It is not something I feel very strongly about but I
prefer to keep
things separate and orthogonal.

/Anders

> I am a fan of keeping separate things separate. So I agree transport and
> send/receive would benefit from being untangled (IIRC, I may be the one
> responsible for entangling them).
> The transport field was intended to match the SIP transport protocol - so I
> think one byte for UDP, TCP, TLS, SCTP is ok.
> I don't see the need to have a separate security field (since we already
> have TCP/TLS sharing a byte) - so I would continue in the same vein. It's
> not a biggie for me - so if others want a secure/not secure byte that would
> be okay.
> Peter Musgrave
> (as individual)
> The notion of adding both SCTP and TLS the flag was brought up on the list
> back in October and it went unreplied to (far as I can tell). Here is the
> snippet:
> denote TLS-over-TCP and TLS-over-UDP (I doubt any implementations are using
> TLS-over-UDP for signaling only, but given that SCTP is starting
> The fact that this is the second time this has been raised leads me to
> believe there is a need. I will raise this as a discussion topic in the
> upcoming meeting Prague.
> Regards,
> Gonzalo
>
> I have no real preference on this one. I'll let others weigh in with their
>
> thoughts.
>

---

From: Anders Nygren <[email-masked]>
Date: Wed, 16 Mar 2011 10:16:57 -0600

> I have no real preference on this one. I'll let others weigh in with their

Just one more comment on this. In draft-01 ch. 4 it says

  "1.  Index Pointers - The first 64-bytes of this format.  This
      portion is primarily composed of a list of pointers that indicate
      the beginning of both the variable length mandatory and optional
      fields that are logged as part of this record.  These pointers are
      implemented as a mechanism to improve processing of these records
      and to allow a reader to expeditiously skip right to the desired
      field without unnecessarily going through the entire record."

and ch 4.1.  Index Pointers

   "The <IndexPointers> portion of the SIP CLF record (shown in Figure 3)
   is a 64-byte header that indicates meta-data about the record."

And finally ch 6.  Text Tool Considerations

"Index lines may be rapidly discarded by checking the first character
 of the line: index lines will always start with an alphabetical character..."

All these sections together gives the impression that the  <IndexPointers>
portion only contains meta data and can safely ignored if wanted.

So I would prefer that the flags field is moved to the <MandatoryFields>
part. And if not then I think that the descriptions in ch 4, ch 4.1 and ch 6
should be updated.

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 16 Mar 2011 13:16:44 -0400

This is first time this has been raised and is a valid point. I see value in moving it to <MandatoryFields>. Let's let others chime in as well.

If we don't get some critical mass on this issue, I'll add it to the discussion agenda for Prague.

Regards,

Gonzalo