Re: Connection Reuse draft to focus on TLS connections

One should note it's not applicable to just "TLS" - it's only applicable to mutual-TLS.  I don't mean to sound negative, but really you might as well limit it's applicability to IPv6 as well at this rate.  :(

Can this draft at least remove the statement in section 8.1 that the client SHOULD NOT add an alias parameter to TCP/SCTP transports?   There's actually nothing wrong with adding one - it's the server side of the connection that needs to not use/honor it based on its policy. (and if you think adding one would be malicious, then trust me malicious devices will simply add one and ignore this draft's SHOULD NOT statement)  All the parameter says is effectively: "I am willing to accept requests on this connection I created, if you wish to send them to me over it".

-hadriel


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Dean
> Willis
> Sent: Monday, March 02, 2009 3:04 PM
> To: SIP WG
> Cc: Cullen Jennings; Keith Drage
> Subject: [Sip] Connection Reuse draft to focus on TLS connections
>
>
> We intend to slightly rescope the Connection Reuse draft:
>
> http://tools.ietf.org/id/draft-ietf-sip-connect-reuse-12.txt
>
> Based on input from our ADs, the WG chairs and the editor of the have
> agreed to eliminate the part of the draft that discusses the
> implementation of reusing non-TLS connections. The stage for this is
> set in the abstract of the current draft, from which I quote:
>
> > From the security perspective, it is bad practice to reuse a single
> > connection for the TCP or SCTP transport between two peers, and this
> > document provides specific insights into why this is the case. As a
> > remedy, it suggests using two TCP connections (or two SCTP
> > associations), each opened pro-actively towards the recipient by the
> > sender.
>
>
> We may  discuss at a later date the idea of developing a draft for
> connection reuse in the absence of TLS.
>
> I'm really not expecting anybody to object strongly to this approach,
> but am bringing this to the list to avoid surprises down the road. If
> you have major issues with doing it this way, please bring them up now.
>
> --
> Dean Willis (as chair, ten years and counting . . .)
>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip