Subject: RE: [Sipping] 3GPP requirements to SIP

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 11 Oct 2001 11:45:41 +0100

Regarding the question on dialled numbers, Miguel has answered the question,
but it is worth pointing out that the reason for the requirement IS to keep
it the same as existing mobile phones. 

Therefore the user requirement is to dial a E.164 subscriber or national
number, and have it interpreted as a E.164 subscriber number or national
number according to the usage of the visited network rather than the home
network. When the user walks down the street and sees a national number
displayed (on the side of taxi or whatever) when he dials those digits he
will get the taxi firm, rather than some number in the home network. The
obvious place to put the responsibility for getting this number into a form
where the home network can handle it is in the proxy in the visited network.

When of course we do away with telephone numbers and get the world using
only SIP URLs...

Regarding the IPv6 question, the main point of the requirement is that we
are using IPv6, and the SIP application will have use of an already
allocated IPv6 address. How it is obtained does not affect SIP.

Keep the comments flowing.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Miguel A. Garcia[SMTP:[email-masked]]
> Sent: 	11 October 2001 7:04
> To: 	Paul Kyzivat
> Cc: 	[email-masked]
> Subject: 	Re: [Sipping] 3GPP requirements to SIP
> 
> Paul Kyzivat wrote:
> > 
> > While reading through this document I came up with a number of
> > questions. Note that I have no ax to grind and no stake in this game, I
> > am simply interested.
> 
> Fair enough.
>  
> > - The following:
> > 
> >   "The visited network contains a SIP outbound proxy to support the UA.
> >    The SIP outbound proxy in the visited network may translate locally
> >    dialed digits into international format,..."
> > 
> >   seems backwards to me. It implies that the translation of dialed
> >   numbers will vary depending on where I am visiting. This seems
> >   less than useless. Why would I want to be subject to the whims of
> >   the place I am visiting? This just makes it harder to use, and
> >   ultimately the call will be processed through my home network
> >   anyway.
> 
> No, I don't agree with you. You can always dial the full international
> number, and this number does not depend on the location you are. This
> is how it works in GSM today. If I visit another country, and my address
> book contains a fully international number, then I can dial that number
> without modifications.
> 
> If I am visiting another country, I can dial a local number, as any local
> user would do. This number will be internationalized by the SIP outbound
> proxy, and send it to the home network. By doing this you achieve a few
> things:
> - First, the user can dial fully international or local numbers.
> - The home network always gets fully international numbers. Therefore,
>   it does not need to know the local numbering plans all around the world.
> - The SIP outbound proxy needs to know about the local numbering plan in 
>   its own network and country. Nothing wrong with this, it is only in its
>   own network.
> 
> > 
> > - "The terminals first connect to the GPRS network to get an
> >    IPv6 address. In order to do this, the terminals must perform a
> >    (GPRS) Attach procedure followed by a (GPRS) PDP Context Activation
> >    procedure."
> > 
> >   Why? The whole point of IPv6 is that there are enough addresses for
> >   every possible device to have one permanently assigned.
> 
> Typically the IPv6 address belongs to the address space of the visited
> network. Therefore, it changes when you change your visited network,
> that is, when you roam to another visited network. There is GPRS procedure
> 
> get an IP address, similar to what DHCP does. The statement above only
> says that the terminal needs to get an IP address before doing anything
> else. 
> 
> > 
> > - The logic of requiring registration for initiating calls has been
> >   flagged before. I won't say more because others can say it better.
> 
> Me neither.
> 
> > 
> >         Paul Kyzivat
> >         Cisco Systems
> > 
> 
> Regards,
> 
>          Miguel
> > "Miguel A. Garcia" wrote:
> > >
> > > Hi:
> > >
> > > In the last IETF meeting our Area Director requested 3GPP to write
> down all the requirements that 3GPP has to SIP.
> > >
> > > A few people have gathered those requirements and put them into an
> Internet Draft. The I-D has been recently submitted to the IETF. It might
> take a few hours to be available in the repositories. In the meantime, you
> can download the I-D from:
> > >
> > >
> http://standards.ericsson.net/sip/drafts/draft-garcia-sipping-3gpp-reqs-00
> .txt
> > >
> > > Regards,
> > >
> > >        Miguel
> > > --
> > > Miguel-Angel Garcia                     Oy LM Ericsson AB
> > >                                         Jorvas, Finland
> > > mailto:[email-masked]     Phone:  +358 9 299 3553
> > > mailto:[email-masked]        Mobile: +358 40 5140002
> > >
> > > _______________________________________________
> > > 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
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> _______________________________________________
> 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: Thu, 11 Oct 2001 16:16:00 +0100

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)

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.

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?

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 12 Oct 2001 09:19:57 +0300

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

> - UA/E registration lifetimes for Path and Contact

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.

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

> Neil.

/Miguel

---

From: "Neil Deason" <[email-masked]>
Date: Fri, 12 Oct 2001 11:19:59 +0100

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]]
> 
> Neil Deason wrote:
> > 

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?

> 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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 12 Oct 2001 13:58:28 +0300

> from bis-04. Maybe the editorial clean up of 05 will

Perhaps bis-04 is not consistent, I agree with you. The Via
header definition in section 10.46.6 allows the Via-hidden
parameter. 

On the other hand, 3GPP is hiding more headers than the Via
header (Record-Route/Route being the most significant ones).
But as we discussed before, I don't think there is an impact
on the SIP protocol or any node in the network: the contents
of some headers are tokenized/detokenized by a network entity.

> work with loop detection?

I agree with you, we need ot include a section on terminology.
Certainly even 'SIP hiding proxy' is not a 3GPP term. Future
versions of the draft may include a terminology section.

The working assumption in 3GPP is that the SIP hiding
proxy is transaction stateless. The loop detection should 
be done based on the From, To, Call-ID, Cseq, Request-URI
etc parameters, rather than the Via header comparison.
Therefore, I think the SIP hiding proxy may need to be
transaction or call stateful to make these comparisons. 
There seems to be a contradiction here. I need to investigate
this.

> to increase security, persumably by hiding network

Yes, the P-CSCF (SIP outbound proxy) will store, remove and
restore all the above parameters. The main motivation is not
hiding though, but other like saving time to transmit the
SIP message over the air interaface (call setup delay time).

/Miguel

---

From: "James Undery" <[email-masked]>
Date: Fri, 12 Oct 2001 12:28:28 +0100

Hi,

All these discussions about Via Hiding scare me from a security stand
point. Please correct me if I am wrong, but, Via Hiding is mainly for
commercial reasons (i.e. hiding info from competitors). (If not it's
security through obscurity which is acknowledged as a bad practise.)
This Via-Hiding must occur on the all the P-CSCFs and I-CSCFs (incase
of reINVITEs). 3GPP TS 33.203 section 7.2.2 says "When the P-CSCF
receives a SIP message, which is integrity, [sic] protected and the
integrity check fails the P-CSCF shall silently discard that message".
This implies to me integrity protection can never be enabled, opening
the system to all manner of MITM attacks. If the integrity is hop by
hop the authentication of the UA to its home network is going to be
open to replay attacks (or include the original message exposing the
info trying to be hidden).

James

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 12 Oct 2001 14:41:45 +0300

James:

I think you are mixing two different issues.

1) Via-hiding: this happens at the I-CSCF, and yes, it is mainly for
   commercial reasons.

2) Via-stripping: this happens at the P-CSCF and has nothing to do
   with commercial reasons, but with efficient transport of signalling.

As far as I know, there is not agreement on how integrity protection is
going to be handle in 3GPP networks. There are proposals to integrity 
protect all the SIP messages and bodies between the P-CSCF and the
terminal, and run IP sec betwen the P-CSCF and the rest of the network.
The integrity protection will not apply to the first ever message.

/Miguel

---

From: "James Undery" <[email-masked]>
Date: Fri, 12 Oct 2001 14:00:31 +0100

> 1) Via-hiding: this happens at the I-CSCF, and yes, it is mainly for

Glad to hear it, so the only entity in the Path passed to the P-CSCF
from the registration is the I-CSCF which then stores it's own info
about the S-CSCF to use internally. I-CSCF also creates integrity
info. This is pushing a lot of state that should be in the S-CSCF.

>    with commercial reasons, but with efficient transport of

This occurs at the P-CSCF closest to the UAS (recipient of a request),
removing vias from messages will mean it is harder to authenticate the
Home network to the UA (i.e. the UA doesn't trust the P-CSCF just the
home network).

> The integrity protection will not apply to the first ever message.

Without integrity checking in the first message, this is open to
passive replay with modification attacks.

My concern about having the integrity checking between the UA and
P-CSCF, then between the P-CSCF and the home network, is also how to
protect against replay of credentials (i.e. how the UA authenticates
itself to the P-CSCF in a way that the P-CSCF can pass onto the home
network in a secure manner that the home network can trust.)

James

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 13 Oct 2001 11:33:10 +0300

James:

I was checking version 0.6.0 of 3GPP TS 33.203, and section 7.2 is gone.

So the text you referred does not apply anymore.

/Miguel

---

From: Dean Willis <[email-masked]>
Date: Sat, 13 Oct 2001 12:55:57 -0500

Hop-by-hop integrity protection at a lower layer is assumed.

--
Dean