Subject: RE: [Sip] SCTP and TLS

From: Adam Roach <[email-masked]>
Date: Fri, 12 Dec 2003 23:59:09 -0600

Cullen Jennings [mailto:[email-masked]] wrote:

> On 11/25/03 9:10 PM, "Adam Roach" <[email-masked]> wrote:
> 
> > Alternately, we could retain backwards compatibility (but have
> > people forever wonder about the TCP aberration) by using
> > designations like:
> > 
> > UDP:       SIP/2.0/UDP
> > UDP+TLS:   SIP/2.0/TLS/UDP
> > TCP:       SIP/2.0/TCP
> > TCP+TLS:   SIP/2.0/TLS
> > SCTP:      SIP/2.0/SCTP
> > SCTP+TLS:  SIP/2.0/TLS/SCTP
> > DCCP:      SIP/2.0/DCCP
> > DCCP+TLS:  SIP/2.0/TLS/DCCP
> > 
> > Because of practical considerations, I would propose that the
> > second approach is probably the best path forward.
> > 
> > /a
> > 
> 
> I think I prefer this too. However, "TLS/DCCP" would not be a 
> valid token

The idea here is to *fix* the syntax, not define new tokens. In
other words, we would redefine "via" to contain:

sent-protocol     =  protocol-name SLASH protocol-version
                     [ SLASH presentation ] [ SLASH session ]
                     SLASH transport

presentation      = token

session           = "TLS" / token

(Hopefully this explains some logic behind my ordering as well).

There aren't any concerns about backwards compatibility for hosts
receiving, say, a "Via" that says "SIP/2.0/TLS/SCTP", because this
very flaw guarantees that no such nodes can exist yet.

/a

P.S. In retrospect, having that "presentation" parameter in there
     to begin with would have made the whole "how do we indicate
     SigComp?" question much more obvious:

     Via: SIP/2.0/SIGCOMP/TLS/TCP 192.168.0.14;branch=z9Hg5bK284921

     Ah, water under the bridge.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 14 Dec 2003 08:53:54 -0800

Adam, I don't understand why you are arguing for a delimiter to be a "/"
instead of a "+".  There are things that know how to Parse a VIA that do not
do SCTP or whatever the protocol is. Network sniffers are one, login and
debugging tools that work from log files are another. There are also people
that get that get their SIP stack from a different vendor or internal group
and would need to wait for that group to do this before they could add SCTP
with TLS. Yes, if I was doing it over again, I would do it differently
(including compression). Yet here we are. My goal is to make SIP security
easy enough that someone might actually do it. What is the advantage to
using a "/" over something else that would not break all of the 3261 stuff?

If it is just a perception of having presentation, session, and transport
parameter vs. having one parameter that specifies all three, I have no
problem with a BNF like

sent-protocol     =  protocol-name SLASH protocol-version
                    SLASH transport ["+" session "+" presentation ]

transport = "UDP" / "DCCP" / "TCP" / "SCTP" / token-no-plus

presentation  = "none" / token-no-plus
 
session       = "none" / "TLS" / token-no-plus

token-no-plus =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                     / "_"  / "`" / "'" / "~" )

Personally, I find the presentation session stuff and mapping that to
compression and protocol security layers is taking the OSI model way too
seriously but whatever - not really relevant to the discussion on hand.
There are so few combination of transports, security methods, and other
things we might mix in that I don't really care if we define them as above
or as a list of tokens that result in the same end protocol on the wire as
the stuff above. We are talking syntax sugar one way or the other.

Cullen

PS. I don't like you BNF below because when you get SIP/2.0/foo/TCP you
can't tell if foo is a session or presentation and when you get
SIP/2.0/SIGCOMP/foo/bar you can't tell what foo is until after you see there
is a white space after bar instead of being after foo. I could put this in
much more theoretical impressive sounding terms but you get the idea :-)