De : Sri Gundavelli (sgundave) [mailto:[email protected]]
Envoyé : mercredi 24 septembre 2014 19:48
À : SEITE Pierrick IMT/OLN; Charles E. Perkins; [email protected]
Objet : Re: [DMM] Fwd: New Version Notification for 
draft-perkins-dmm-4283mnids-00.txt

Hi Pierrick,

The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 
23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is seen 
as a confidential IE. But, I agree on the need to include some text on how the 
signaling message can be protected with privacy / confidentiality service set, 
when the identifier is based on some confidential data.

>> I agree, thanks.


Regards
Sri

From: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [DMM] Fwd: New Version Notification for 
draft-perkins-dmm-4283mnids-00.txt

Hi Charlie,

Thanks for the list... it looks good. I'm just wondering about security 
considerations... Actually, from 3GPP standpoint, security constrains on IMSI 
and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very rarely 
sent on the air (maybe only one time at the beginning of the 3GPP 
authentication process) for security reasons. So, I'm wondering if adding IMSI 
to the list of IDs, without any warnings, is somehow introducing security 
weakness to the 3GPP security process.   Consequently, I'm not sure about the 
following statement "This document does not introduce any security mechanisms, 
and does not have any impact on existing security mechanisms." It's maybe not 
so true from the 3GPP point of view...

Maybe we should state that the ID option MUST be used in a way that it does not 
harm existing security mechanisms (i.e. use the option with caution :)). For 
example, to address the issue above (maybe there are other examples... I don't 
know...), we could state that the IMSI should be transmitted only during first 
binding update, and not transmitted anymore as long as the association 
IMSI/HoA/HNP is done.... Or... simpler way to address the issue:  if nobody has 
use-case for transmitting the IMSI, we can simply remove the IMSI from the list 
:)

BR,
Pierrick


De : dmm [mailto:[email protected]] De la part de Charles E. Perkins
Envoyé : mardi 23 septembre 2014 21:10
À : [email protected]<mailto:[email protected]>
Objet : [DMM] Fwd: New Version Notification for 
draft-perkins-dmm-4283mnids-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is mainly for
reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.


-------- Original Message --------
Subject:

New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Date:

Tue, 23 Sep 2014 10:43:12 -0700

From:

<[email protected]><mailto:[email protected]>

To:

Charles E. Perkins <[email protected]><mailto:[email protected]>, Vijay 
Devarapalli 
<[email protected]><mailto:[email protected]>,
 Charles E.Perkins <[email protected]><mailto:[email protected]>



A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to the

IETF repository.



Name:         draft-perkins-dmm-4283mnids

Revision:     00

Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option

Document date: 2014-09-23

Group:        Individual Submission

Pages:        4

URL:            
http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt

Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/

Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00





Abstract:

   Additional Identifier Types are proposed for use with the Mobile Node

   Identifier Option for MIPv6 (RFC 4283).









Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to