Subject: [Sigtran] security issues

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 4 Dec 2002 15:41:16 -0800

Hi Folks,

The remaining issues with security are currently a roadblock to IESG
approval of further UA documents.  One issue in particular is whether
to mandate implementation of IPSec or TLS for security, as one 
mechanism should be selected for interoperability.  I would like to
hear if people have opinions on this either way.

If the issue is unclear to people, I'm also wondering if it might make
sense to form some type of design team to address this.

Cheers,

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

---

From: [email-masked]
Date: Thu, 5 Dec 2002 12:26:53 +0200

Lyndon,

the IPSec looks as much more practical way:
 - possibility to use network solution: work in Tunnel mode if one of the
Sigtran peers does not support security protocol by itself;
 - general solution for all signaling interfaces supported in certain unit
(different UAs, Media Control, inter-switch signaling, etc. ).

Regards,
Lev

> -----Original Message-----
> From: ext Ong, Lyndon [mailto:[email-masked]]
> Sent: 05 December, 2002 01:41
> To: [email-masked]
> Subject: [Sigtran] security issues
>
> Hi Folks,
>

---

From: [email-masked]
Date: Thu, 5 Dec 2002 12:28:12 +0200

Hi Brian,

> Looking at the draft it looks fine (however, I am not conversant on all
> the technical details of IPSec and TLS).  One significant issue,
> however, is that the recommendations rely on two drafts (TLS draft and
> SCTP IPSec draft) which are work in progress.  This begs two 
> questions:
> 
> 1)  How can a SIGTRAN UA RFC security section rely on a Work in
>     Progress?

Thanks for tossing me an easy one.  

	draft-ietf-tsvwg-tls-over-sctp-00.txt is in the RFC Editor's queue.

	draft-ietf-ipsec-sctp is stuck in the IESG, small technical issues 
remain. I'll bug the ADs about it. I actually think that this draft could
be made as a non-normative reference.
 
> 2)  How can a SIGTRAN UA properly address security issues which TSVWG
>     has not yet put in place for SCTP?

Well, IPsec works with SCTP; the draft recommends some changes for IKE if
IKE is used.  If manual keying is used, then it should be OK.
 
> In fact, few (if any) of the security issues appear to be related to any
> SIGTRAN UA.  They appear to be all related to SCTP and whether SCTP can
> provide its services (multi-homing, multiple streams) transparently
> under a security regime.

Agreed.

> How can SIGTRAN be expected to address SCTP security issues within the
> SIGTRAN charter?  Are these not the responsibility of TSV (where the
> cited works in progress have not been advanced)?

Not necessarily, as we did work on SCTP some time ago. If you have
better suggestions on how to provide security for UAs, I am all ear.
 
John

---

From: [email-masked]
Date: Thu, 5 Dec 2002 18:19:12 +0200

Hi Ray,

> In discussing security you would have to consider whether the solution is
> really security of the adaptation protocol or network security.  

The IESG has already told us that we need to secure the protocol, security
the network is not sufficient. 

> One issue to consider if it is a requirement to use IPsec encapsulation 
> at the node supporting the adaption layer and the SS7 application, is 
> that it would impact the use of monitoring systems (e.g., SS7 link 
> monitoring systems). Specifically, for M2PA we were envisioning a solution where 
> IPsec tunnel mode is used to provide secure tunnels between gateway 
> routers and the SS7 node itself (e.g., SG and MGC) would not have to support 
> IPsec.  This would allow link monitoring systems to be used at the SS7 nodes the 
> way they are being used in SS7 networks today.

What is being required is the support of IPsec, not the use of IPsec.

> Therefore, in specifying requirements for nodes to support TLS and IPsec
> encapsulation, please consider that certain network providers would like to
> continue use of their link monitoring systems.

Of course the service provider could turn on or off the security, as
they see fit, but what the IESG wants is that all of the implememenations
support some sort of security mechanisms.  Turning it on is at the
discreation of user. It is like a safety belt - all cars need to have
them, whether you wear it is your business.

John

---

From: [email-masked]
Date: Thu, 5 Dec 2002 13:39:39 -0500

John,

Just to clarify, you are saying that it would be mandatory that an
adaptation implementation be capable of supporting IPsec.  However, use of
IPsec  end-to-end would not be mandatory?

This should be ok, because I don't think that it would be practical to
impose a protocol requirement to use IPsec end-to-end for all applications
of the UA protocols.

Ray

                    john.loughney                                                                  
                    @nokia.com           To:     [email-masked]                              
                                         cc:     [email-masked], [email-masked],                
                    12/05/02             [email-masked], [email-masked], (bcc: Ray 
                    11:19 AM             P. Singh/Telcordia)                                       
                                         Subject:     RE: [Sigtran] security issues                

Hi Ray,

John

---

From: [email-masked]
Date: Thu, 5 Dec 2002 22:00:57 +0200

Hi Ray,

> adaptation implementation be capable of supporting IPsec.  
> However, use of IPsec  end-to-end would not be mandatory?

You are exactly correct.

> impose a protocol requirement to use IPsec end-to-end for all 
> applications of the UA protocols.

Agreed.  

The proposal is this: if users can count on implementations supporting
end-to-end security, thus making it possible for two parties to engange
in end-to-end security.  It is much harder to acheive end-to-end
security if one party has implemented IPsec, while another has not.

thanks,
John

---

From: Kevin McCandless <[email-masked]>
Date: Fri, 6 Dec 2002 12:05:55 -0800

Lyndon:

As I shared with the small group in Atlanta we are in the process of
deploying SCTP/M3UA.  Prior to that we deployed TALI.  We internally agreed
that a security method was needed not for ISUP but for TCAP queries (LIDB
dips etc).  So, we reviewed several options and selected IPSEC.  Now, this
is only used for unsecure networks. For secure networks we do not use any
IPSEC.

So, yes we should have a security option in the documents and recommendation
of when to use them.

Make sense?

Kevin....

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 5:41 PM
> To: [email-masked]