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

[Gonzalo Salgueiro <[e-mail]>]

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

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
>