Subject: Re: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt

From: Chip Sharp <[email-masked]>
Date: Mon, 10 Apr 2000 08:15:22 -0400

At 09:44 PM 4/5/00 +0000, Donovan, Steven R. wrote:
>Jonathan Rosenberg wrote:
> >
> >
> > "Donovan, Steven R." wrote:
> > >
> > > One quick comment on the security section of this draft.  I
> > agree that it is
> > > true that the security section in SIP that discusses
> > end-to-end encryption
> > > of the SIP message body should be sufficient to meet the
> > security concerns
> > > associated with carrying ISUP and QSIG message bodies.
> > >
> > > I would, however, suggest that the following be added to the spec:
> > >
> > > "Due to the potentially sensitive nature of the information
> > contained in
> > > ISUP and QSIG message bodies, the UAC SHOULD perform
> > end-to-end encryption
> > > on ISUP and QSIG message bodies."
> >
> > Lets be careful here. It depends on the application of SIP-T.
> > For single
> > provider networks among a set of  softswitches, its easy to
> > manage keys
> > in such a way that e2e encryption is possible. For
> > multi-provider, wide
> > area operation, e2e encryption is harder, and I'm reluctant to make it
> > SHOULD. It requires the originator to know the key of the ultimate
> > recipient before sending the request. Since the entity the
> > request will
> > terminate on can't always be known ahead of time (due to forwarding or
> > routing to a remote gateway), this requirement is overly strong.
> >
>
>I don't know, there are some pretty serious regulatory issues involved.  I'm
>almost inclined to say that SHOULD is to weak and that if the encryption key
>information is not available then the ISUP information SHOULD NOT be
>included in the SIP message.

I believe this may be too strong.  ISUP doesn't use end2end encryption 
today over the SS7 network which is essentially a connectionless packet 
network.  There is no reason to require end2end encryption for SIP-T when 
carrying ISUP over a similarly designed (in terms of security) IP network.

If a carrier doesn't want to carry ISUP in the clear over an IP network due 
to regulatory reasons, there is not reason it has to.  The carrier can 
require its vendors to provide the requisite features for this (such as you 
describe).

BTW, what (US) regulation covers security of ISUP?  I'd like to look it up.

Thanks,
Chip

>This doesn't break the call, it just weakens the interoperability between
>the SIP and PSTN networks.  All of the information necessary for the call to
>be re-originated from the SIP network to the PSTN exists in the SIP headers.
>The only loss is some of the information carried in the ISUP message (caller
>id, reason codes, etc.).  This is analogous to interoperability between an
>SS7 ISUP network and a CAS network, where information is lost when the call
>is handed off to the CAS network.  The calls still work, just with a limited
>set of features.
>
>If it is absolutely necessary to include the ISUP for all call related
>features to work then the calling gateway can insist on use of the security
>pre-condition mechanism defined in the manyfolks draft.
>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.			
------------------------------------------------------------------------

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip