Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Fri, 12 Oct 2001 14:40:24 +0200

Hello Neil,

thanks for your comments.

> -----Ursprüngliche Nachricht-----
> Von: Neil Deason [mailto:[email-masked]]
> Gesendet: Freitag, 12. Oktober 2001 13:51
> An: Mayer Georg ICM N MC MI E71
> Cc: [email-masked]
> Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts
> 
> 
> > -----Original Message-----
> > From: Mayer Georg ICM N MC MI E71 
> [mailto:[email-masked]]
> >
> > Hello Neil,
> >
> > may I give some more comments on the following issue:
> >
> > > in the P-CSCF for the duration of the session. The Path
> > > discovered at registration meanwhile would need to be stored
> > > for the lifetime of the registration. I take it this is
> > > what is being referred to in section 6.2.3 of the draft
> > > to increase security, persumably by hiding network
> > > structure.
> >
> > Section 6.2.3 talks about Removal of Headers and what you
> > wrote about it is
> > exactly what 3G requires (from my point of view). But this
> > requrirement is
> > compeletely different from the one in section 6.12 "Hiding
> > requirements".
> 
> I appreciate there are two types of network structure hiding
> at play. Headers are removed before msgs are passed to end
> users/UEs (which also reduces msg size). Headers are tokenised
> before passing between network operators.

In fact the removal of certain headers when sending messages from P-CSCF to
the UE is only for bandwith saving purposes, but not intended for network
hiding. 

> 
> > Network hiding is done by a proxy of the home network (the so-called
> > I-CSCF). In fact it hides only information in messages going
> > OUT of the home
> > network, by looking into Via/Route/Record-Route/Path (is 
> there a Path
> > header?) headers and encrypting the entries of its home
> > network entities.
> > This is done as some operators do not want to let their
> > competitors know how
> > many S-CSCFs they have in their network.
> 
> I have to say I find this bizzare. Why don't they just
> multihome S-CSCFs to intimidate competitors ;)
> 
> > Assume it is an INVITE that is going out from the home
> > network (of user B)
> > to the visited network. If network hiding is required, the
> > INVITE will pass
> > through an I-CSCF / proxy in the home network, it will
> > encrypt the above
> > stated information.
> >
> > If the (e.g.) 180 Ringing response for that INVITE comes 
> back from the
> > visited network, the I-CSCF / proxy looks for encrypted
> > information and will
> > de-crypt it. By doing so we still enable the network to still
> > detect loops /
> > spirals.
> 
> Detecting loops/spirals is important on the request path.
> Responses just follow the Via's back so as long
> as the server that can de-tokenise the headers is
> reached first that should be OK. Issues on the request
> path could arise if loops occur back to a server that
> then fails to recognise itself in the Via headers as
> they have been tokenised downstream.
>

Yes, that's true, but the proposed mechanism will not prevent loop detection
from working.

A message outgoing from home1.net ist sent through home1's I-CSCF
i2.home1.net. Assume the i2.home1.net receives a Via header like that (for
simplification I left out all the "sip:" etc.):

Via: p.visited1.net, i1.home1.net, s1.home1.net

It then will send out a Via header looking the following way:

Via: p.visited1.net, token(i1.home1.net, s1.home1.net), i2.home1.net

So, if the request is routed back to p.visited1.net, this entity will still
be able to detect the loop / spiral.

If the request is sent back to home1.net, it will always be routed to an
I-CSCF (because for network hiding the I-CSCF's will be the switches known
in DNS when a request has to be routed to the home1.net - this is one of the
key things in this mechanism). This I-CSCF will then decrypt the
token(i1.home1.net, s1.home1.net), so that also the home1.net entities will
be able to recognize loops. 

> Cheers,
> Neil.
> --
> Ubiquity Software Corporation, UK        http://www.ubiquity.net

Keep on signaling!
Georg
_______________________________________________________
Georg Mayer - Siemens AG Germany

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Neil Deason" <[email-masked]>
Date: Fri, 12 Oct 2001 15:20:38 +0100

> From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
> Hello Neil,
>

6.2.3 of the 3G reqt's draft says that headers are removed
to 'increase security'. I was assuming that this meant
security is increadsed by hiding network information from end
users. Admittedly this doesn't buy you that much security
for the state overhead needed to store info in the P-CSCF.
But then I also wonder how much BW it saves you after
compression.

> be able to recognize loops.

This is true as long as some assumptions hold true -
such as the only ingress points to home1.net are the
I-CSCFs and if there are multiple I-CSCFs they can
all decrypt headers encrypted by any other I-CSCF.
Seems odd to me to introduce such scope for problems just
to hide how many S-CSCFs you have from other network
operators.

Cheers,
Neil.