Subject: [sigtran] draft-ietf-sigtran-security-01.txt

From: Andrew Booth <[email-masked]>
Date: Mon, 03 Feb 2003 11:12:26 -0500

Hi All,

I'm not overly familiar with IPSec or TLS, but here are some questions 
anyway.

1) Section 6. TLS Usage says
 "A SIGTRAN node that initiates a SCTP association to another SIGTRAN
  node acts as a TLS client according to [3], and a SIGTRAN node that
  accepts a connection acts as a TLS server."

I'm under the impression that an SCTP Endpoint can act as both a client 
and server simultaneously while trying to establish an association.  Can 
a TLS endpoint act a both a client and server also?  Would it just mean 
more certificate exchanges?

2) line 424
  "It is recommended that SIGTRAN peers use the same security mechanism
  (IPSec or TLS) across all its sessions with other SIGTRAN peers."

  This recommendation seems to encourage the use of IPSec, since peers 
are required to support IPSec while TLS is optional.  For example, 
suppose that a server interacts with implementations from several 
vendors, where additional vendors could be added later, then there is no 
guarantee that the new implementations would support TLS.   So the 
server would be "recommended" to use IPSec.  All of this is technically 
fine, it just seems to stack the odds against general TLS support.

Comments?
Andrew

[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Signaling Transport Working Group of 
> the IETF.
>
>     Title        : Security Considerations for SIGTRAN Protocols
>     Author(s)    : J. Loughney et al.
>     Filename    : draft-ietf-sigtran-security-01.txt
>     Pages        : 13
>     Date        : 2003-1-31
>     
> This documents discusses how TLS and IPSec can be used to secure the
> communication for SIGTRAN protocols.  The support of IPSec is
> mandatory for all nodes running SIGTRAN protocols and the support of
> TLS is optional.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sigtran-security-01.txt
>
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the 
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>     "get draft-ietf-sigtran-security-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     [email-masked].
> In the body type:
>     "FILE /internet-drafts/draft-ietf-sigtran-security-01.txt".
>     
> NOTE:    The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>        
>        
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>  
>

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Feb 2003 22:06:49 +0100

Hi Andrew,

see my comments below.

Best regards
Michael

On Monday, Feb 3, 2003, at 17:12 Europe/Berlin, Andrew Booth wrote:

> I'm under the impression that an SCTP Endpoint can act as both a 
> client and server simultaneously while trying to establish an 
> association.  Can a TLS endpoint act a both a client and server also?  
> Would it just mean more certificate exchanges?
You are correct, SCTP supports the peer-to-peer model, whereas TLS uses 
the client-server model.
> vendors, where additional vendors could be added later, then there is 
> no guarantee that the new implementations would support TLS.   So the 
> server would be "recommended" to use IPSec.  All of this is 
> technically fine, it just seems to stack the odds against general TLS 
> support.
We had to make a choice and selected IPSec. So if you are in a 
multivendor environment the only assumption
you can make is, if you only buy equipment which is compliant to this 
'RFC', it supports IPSec. Even without
the recommendation that you use only one technology. So if wou provide 
the environment, you will focus on IPSec.
But I think the operators will make a choice and request that from the 
vendors. And if an operator wants to
use TLS he can use it, if he want to use IPSec he can do it.
--
[email-masked]