RE: Evaluation: draft-ietf-sigtran-security - Security Considerations for SIGTRAN Protocols to Proposed Standard

["Peterson, Jon" <jon.peterson@neustar.biz>]

Some notes below.

- J

> -----Original Message-----
> From: Ted Hardie [mailto:hardie@qualcomm.com]
> Sent: Monday, April 14, 2003 6:34 PM
> To: IESG Secretary
> Cc: Internet Engineering Steering Group
> Subject: Re: Evaluation: draft-ietf-sigtran-security - Security
> Considerations for SIGTRAN Protocols to Proposed Standard
> 
> 
> > Ted Hardie          [   ]     [   ]       [ x  ]      [   ]
> >
> 
> 
> DISCUSS comment:
> 
> Section 6. on TLS usage notes that SIGTRAN  protocols use the same
> port number and payload protocol identifier when run over TLS, and
> that a session upgrade procedure has to be used to initiate the TLS 
> based
> communication.  There are, however, no pointers to a specification for
> this (even an example).  I think _something_ is required here, because
> the consequences of doing an upgrade here may not be obvious.

Agreed - the text is underspecified in this regard (in fact, the TLS text
largely seems to exist in the document as a concession in the inevitable
religious wars, or perhaps a stub). I imagine that the authors don't
envision session upgrade a la HTTP UPGRADE, but rather a situation in which
TLS establishment MAY precede the initation of a SIGTRAN connection, but
I'll check with them about it. I doubt that some SIGTRAN-layer upgrade
procedure will be defined for the various SIGTRAN protocols.

> RFC 3436 notes in section 6.2, for example:
> 
>     TLS requires that the underlying transport delivers TLS records in
>     strict sequence.  Thus, the 'unordered delivery' feature of SCTP MUST
>     NOT be used on streams which are used for TLS based user data
>     transmission.  For the same reason, TLS records delivered to SCTP for
>     transmission MUST NOT have limited lifetimes.
> 
> If you UPGRADE, in other words, there are consequences to how you use
> SCTP that you may need to take into account.  If these don't apply to
> SIGTRAN, great, but a worked example or additional text on the
> UPGRADE scenario would really help.
> 

I also agree that this is worthy of mention - the choice to use TLS over
SCTP does have some noteworthy consequences.

> Note:
> 
> Section 3., "Security in Telephone Networks" seems to report things
> like "the trusted network principle" without any comment on how
> valid these principles are.  Purely as a personal note, I would find
> some more cynicism here comforting.  This does not, of course,
> change the specification in any substantive way.
> 

Cynicism. Yes. 

I think it might more accurately be called the 'closed network principle',
the one in which end-users do not have the ability to interject arbitrary
packets onto SS7 networks (and where ISDN signaling from end-user devices is
meticulously groomed by edge policy points). Of course, the rise of CLECs
and so forth made that closed network much more diverse and less trustable
than it was in the past, so cynicism is warranted. 

> 							regards,
> 								
> 	Ted Hardie
> 
> 
>