Subject: RE: [Sip] SCTP and TLS

From: Adam Roach <[email-masked]>
Date: Wed, 26 Nov 2003 12:26:23 -0600

I thought of throwing that in as another example
of a kind of change that isn't backwards compatible.
The problem is, keeping the necessary state also
disqualified it from being elegant, so I didn't
see any advantage that made it worth mentioning.

/a

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 1:02
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] SCTP and TLS
> 
> 
> Why isn't it enough to state that if a request was received 
> using TLS, the response must sent using TLS? It requires 
> proxies and UASs to keep a state though.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> > Adam Roach
> > Sent: 26.November.2003 07:10
> > To: 'Cullen Jennings'; Vijay Gurbani
> > Cc: Adam Roach; [email-masked]
> > Subject: RE: [Sip] SCTP and TLS
> > 
> > 
> > Cullen Jennings [mailto:[email-masked]] wrote:
> > 
> > > There is not really any SCTP or TLS over SCTP or UDP or DCCP 
> > > deployed so I think we could be backwards compatible with
> > > existing TLS stuff. I'm not seeing a way to be backwards
> > > compatible with everything but the current stuff looks broken
> > > so I think the odds of something other than what is currently
> > > specified deploying are fairly high. This is not a "I don't
> > > like the current thing issues" this is the current thing can't 
> > > construct a usable via for a stateless proxy using SCTP with TLS.
> > 
> > Actually, I think we have a choice between backwards-compatibility
> > and elegance.
> > 
> > For example, we could choose designations like the following
> > for a sort of elegance:
> > 
> > UDP:       SIP/2.0/UDP
> > UDP+TLS:   SIP/2.0/TLS/UDP
> > TCP:       SIP/2.0/TCP
> > TCP+TLS:   SIP/2.0/TLS/TCP
> > SCTP:      SIP/2.0/SCTP
> > SCTP+TLS:  SIP/2.0/TLS/SCTP
> > DCCP:      SIP/2.0/DCCP
> > DCCP+TLS:  SIP/2.0/TLS/DCCP
> > 
> > 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
> > 
> > _______________________________________________
> > 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
> > 
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 02 Dec 2003 12:37:12 -0600

> However, this leaves the issue of Via headers.
> 
> I can say:
> 
>   Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds
> 
> Or:
> 
>   Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds
> 
> But there is no standardized syntax that allows me to say
> both at the same time.
> 

Record-in, record out. Use two Via header fields, one for each
interface. Just like a dual-homed proxy.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 Dec 2003 14:41:55 -0800

> second approach is probably the best path forward.

I think I prefer this too. However, "TLS/DCCP" would not be a valid token so
perhaps it would need to switch the "/" to something that is valid in a
token such as "+" so it would be "TLS+DCCP". I would switch the order (for
no good reason) to be "UDP+DCCP". Agee or am I missing the boat on something
here?

Cullen

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Dec 2003 18:13:18 -0600

Okay; I can't bring myself to spend time arguing about this.
Use a plus sign.

/a

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, December 14, 2003 10:54
> To: Adam Roach
> Cc: [email-masked]
> Subject: Re: [Sip] SCTP and TLS
> 
> 
> 
> 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 :-)
>  
> 
> On 12/12/03 9:59 PM, "Adam Roach" <[email-masked]> wrote:
> 
> >> 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.
> >