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

[Anders Nygren <[e-mail]>]

On Tue, Mar 15, 2011 at 3:37 PM, Gonzalo Salgueiro <[e-mail]> 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

> Gonzalo
> On Mar 15, 2011, at 4:57 PM, Peter Musgrave wrote:
>
> 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)
> On 2011-03-15, at 3:58 PM, Gonzalo Salgueiro wrote:
>
> 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
>
> On Mar 15, 2011, at 3:13 PM, Anders Nygren wrote:
>
> On Tue, Mar 15, 2011 at 12:38 PM, Gonzalo Salgueiro <[e-mail]>
> wrote:
>
> On Mar 15, 2011, at 1:49 PM, Anders Nygren wrote:
>
> Hi
>
> I will start writing one email for each issue in order to make it
>
> easier to track the different discussions.
>
> Thanks. That should help.
>
> 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.
>
> I have no real preference on this one. I'll let others weigh in with their
>
> thoughts.
>
> 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.
>
> 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
>
> Regards,
>
> Gonzalo
>
> /Anders
>
> _______________________________________________
>
> sip-clf mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/sip-clf
>
>
>
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf
>
>
>