Subject: IPv6 for mobile telephony

From: Hossam Afifi <[email-masked]>
Date: Thu, 24 Jun 1999 19:53:11 +0200

A draft has been sent to the internet draft secretary on IPv6 in Mobile
Telephony
 the document is also available from
http://www.rennes.enst-bretagne.fr/~afifi/e164ipv6.asc

 your comments are welcomed.

Hossam

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 28 Jun 1999 16:31:25 +0200

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Monday, June 28, 1999 4:21 PM
> To: Thomas Eklund
> Cc: 'Hossam Afifi'; [email-masked]; [email-masked]'
> Subject: Re: IPv6 for mobile telephony 
> 
> 
> > Chapter4:
> > You will NEVER use IPsec over GSM or GPRS due to the 
> overhead! You already
> > have ciphering today over the air and that does not introduce any
> > overhead... This is handeled at layer 2 in GSM/GPRS....
> 
> link-layer encryption is not end-to-end encryption; most importantly,
> the trust properties are completely different.

But what do we mean here, I also agre that e-2-e security have a totally
different trust delegation  arhitecture than only ciphering over the air...
But read my answers and see what I mean. I have never talked about not being
able to use IPsec as e-2-e security mechanism probably over PPP... I said
that we will never use IPsec internally in GSM (between MS and BSC,
MSC!!)....!

> 
> Also NEVER is a very strong word.  Certainly, I can see that some
> applications would be willing to pay the additional overhead when they
> need end-to-end encryption (rather than sending in the clear over the
> internet to the GSM base station and then trusting the GSM base
> station to encrypt for them).
Then you will have to change the entire GSM spec... And that is a huge task
and a lot of Politic!!! :-(

/Thomas Eklund, SwitchCore

> 					- Bill

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 28 Jun 1999 16:25:09 +0200

> From: Hossam Afifi [mailto:[email-masked]]
> Sent: Monday, June 28, 1999 11:52 AM
> To: Thomas Eklund; [email-masked]; 
> [email-masked];
> [email-masked]
> Thank you for your comments
> 
>  The drafts was written in a hurry to meet with the ietf 
> submission deadline.
Thats ok.

> 
>  What we propose for addressing  is the use of a 32 bit long 
> prefix identifying
> the MSC and
>  the rest holding the user MS-ISDN number to keep track of 
> his mobility through
> different MSCs.
So what you are saying is that the MSC will allocate its MCC and MNC from
the TLA domain or what? (MCC - Mobile Country Code consists of three
digits.cc identifies uniquely the country of the mobile subcriber, MNC -
Mobile Network Code consists of two digits for GSM applications. The MNC
identifies the home GSM PLMN operator of the mobile subsciber., MSIN -
Mobile Subsciber Identification Number identifies the mobile subsciber
within a GSM PLMN., NMSI - National Mobile Subscriber Identity consits the
Mobile Network Code and the Mobile Subsciber Identification Number.)
And the MCC + MNC is 32 bits...

And what do you mean with the rest? a MS-ISDN is 120 bits????

That means 32+120 bits.... (You probably mean MSIN that is 80 bits long)

I would recommend  to allocate a prefix bit from the 3 bits in the address
instead...

> 
>  In what concerns the security, we would like to be able de 
> disable any packets
> from outside the GSM
>  network if the user wishes so. So we suggest a label that 
> would be put in
> every packet to filter the
>  packets that are not welcomed and to protect your air resources.
What do you really mean here? Because if you want to protect from evil
packets you will set up a firewall filter in the GGSN node entering the
packet based GPRS network and not entering circuit switched GSM..

> 
> 
>  For the differences with GPRS we say that you should not 
> have a separate
> entity called GGSN because
What do you mean with say??? Its already there at the GSM operators... You
cant just say something and expect the telecom world to follow. They
standardize within ETSI, ITU TIA and others and its a long standadization
proccess to define a system. And GPRS solve most (practically everything)
you suggest... GPRS is also specified to use IPv6 addresses... But what is
not there is a nice migration of e.164 addressing into IPv6 address domain
in a nice way and I my sugesstion is to allocate a bit in the prefix for
this...

>  it will add complexity to the system and it will need 
> updates between MSC and
> GGSN. We would like
>  to modify the CC and MM messages to include all that without 
> the need of
> encapsulation protocols as
>  described in GPRS.
What do you really what to solve here that is NOT part of GPRS yet?

Best Regards 
 Thomas Eklund, SwitchCore

---

From: Thomas Eklund <[email-masked]>
Date: Tue, 29 Jun 1999 14:20:26 +0200

> From: Ignatios Souvatzis [mailto:[email-masked]]
> Sent: Tuesday, June 29, 1999 12:50 PM
> To: [email-masked]; Thomas Eklund
> Cc: [email-masked]
> On Mon, Jun 28, 1999 at 11:49:53AM -0400, Perry E. Metzger wrote:
> > 
> > Thomas Eklund <[email-masked]> writes:
> > > Chapter4:
> > I must respectfully disagree with this statement.
> > 
> > 0) GSM's link encryption is, to put it bluntly, garbage.
> 
> ... and only used (in practice) from your phone to the base 
> station, but not
> in between base stations. This is a feature demanded by the 
> ... uhm... 
> security agencies. At least in Europe.
> 
> That is: if you are near the line of sight between two base 
> stations, you
> can copy the traffic in clear{voice,text}.
Yes, and why do you want to use IPsec from BS and uplink in the MSC area?
Whats the purpose of having a mechanism of encryption from the MSC using
IPsec to only protect the air interface if its already there? The reason why
the ciphering mechanism is there  is to encrypt it over the air (from BS to
MS). 

You have several hundreds of millions of terminals that uses this and they
use their terminals only for voice and for circuit switched data (and only a
circuit switched data connection that runs PPP over it and then that PPP
connection protects the wireless hop in GSM from BS to MS using the
ciphering mechanism already there). The intent is to stop eavesdropping on
phone-conversations and data transmissions in the air. Nothing else.

When you have a more always connected mode like GPRS then it makes more
sense, but then its already there... In products and specifications...
---------
The authentication procedure works very much like the Radius/Diameter auth
procedure but it runs on level 2!! So its for subscriber auth. and for
establish ciphering procedures ... It uses the AuC for generating the
ciphering key and store it in HLR/VLR (MSC).

And the Ciphering procedure relies on a predefined shared key and IMSI
between the MS and the AuC. The MS store this info in the SIM card. And when
the MS enters a MSC/VLR,HLR area it generates these ciphering keys  and
store them in the MS, BS and MSC/VLR. And that is very much the same thing
as when you generates session keys in IP sec (SA:s)!!!

So yes its the same mechanisms. And you can use different ciphering
algorithm and different lenghts of the predefined keys but I still dont
understand what benefit IP sec would give in circuit switched GSM for
protecting the air, beside a re-write of all standardization documents!!!?
For packet based systems, ok, but for circuit switched GSM??

Note: There is also a draft written by a former collegue of mine when I
worked for Ericsson, Fergal Ladley, that specifies how Diameter can do link
authentication using IPsec
(http://www.ietf.org/internet-drafts/draft-ladley-diameter-pr-00.txt), the
interested could have a look.

(You can also check on the IMEI number also if you want, but thats another
thing)

Regards 
 Thomas Eklund SwitchCore