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 13:11:12 +0200

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". 

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. 

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.

Keep on signaling!
Georg

_______________________________________________________
Georg Mayer - Siemens AG

> -----Ursprungliche Nachricht-----
> Von: Neil Deason [mailto:[email-masked]]
> Gesendet: Freitag, 12. Oktober 2001 12:20
> An: Miguel A. Garcia
> Cc: [email-masked]
> Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts
> 
> 
> > -----Original Message-----
> > From: Miguel A. Garcia [mailto:[email-masked]]
> > 
> > Neil Deason wrote:
> > > 
> > > Thanks to Miguel et al from the 3GPP for putting
> > > this ID together. After reading this and some of
> > > the relevant TS docs I have some questions.
> > > 
> > > How does bis-04 meets the hiding requirements? (6.12)
> > 
> > bis-04 already shows examples of hidden Via headers.
> > Hiding is done by the SIP hiding proxy, typically a
> > stateless proxy.
> 
> Text relating to encrypting Vias was removed in bis-02 
> when the Via hiding mechanism was taken out. Indeed Table 
> 5 marks Via as a header that needs to be read by proxies 
> so cannot be encrypted. There is an example of a hidden 
> Via at the end of 10.46 but it looks like a remnant from 
> earlier drafts, how this is used is not clear to me 
> from bis-04. Maybe the editorial clean up of 05 will
> shed some light on this. 
> 
> The term 'SIP hiding proxy' is certainly not one defined 
> by bis so needs stating somewhere. Do you mean stateless 
> in the sense of SIP transaction or the way that it tokenises 
> and de-tokenises headers. How would encrypting Via headers 
> work with loop detection?
> 
> > > To meet these requirements is it expected/accepted
> > > that state will be stored somewhere in the network
> > > for the duration of:
> > > 
> > > - Transactions for Via headers.
> > > - Sessions for Route headers.
> > > - UA/E registration lifetimes for Path and Contact
> > > headers.
> > 
> > No, the current working assumption in 3GPP is to provide
> > a SIP hiding proxy that is stateless. This proxy will
> > tokenize/detokenize headers (Via, Record-Route...). 
> > You don't need to store a state anywhere in the network.
> > Responses are routed back through the same hiding proxy,
> > and it will detokenize the appropriate headers.
> 
> Sorry I wasn't being clear, I didn't mean the tokenisation
> of info retained in messages here but the removal of parts
> and its storage in network servers. For example I believe 
> that on call setup a P-CSCF would hide network structure 
> by stripping the Via headers from an INVITE and save that 
> information to avoid passing it to the terminating UE. The 
> server would need to store this info for the duration 
> of the transaction to route back responses. Similarly 
> Record-Route headers are not passed from P-CSCFs to UEs 
> and so the Route set calculated from them needs to be stored 
> 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.
> 
> Cheers,
> Neil
> --
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> 
> > > The graceful session release requirement (6.14.2)
> > > would appear to necessitate a B2BUA in the
> > > network. Where is that functionality expected to
> > > feature within the various 3GPP x-CSCF entities?
> > > 
> > 
> > My understanding is that the graceful session release is
> > just needed for the prepaid service. As such, a B2BUA is
> > probably needed. This functionality will be part of the
> > "prepaid Application Server". So it is not part of any
> > x-CSCF. If you are not a prepaid user, you don't need
> > to route your session through this special application
> > server.
> 
> _______________________________________________
> 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
> 

_______________________________________________
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 12:50:39 +0100

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

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.

> 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 ;)

> de-crypt it. By doing so we still enable the network to still

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.

Cheers,
Neil.