Subject: Re: [fmc] New Version Notification for draft-pularikkal-opsawg-lawful-intercept-spwifi-00.txt

From: <[email-masked]>
Date: Mon, 4 Mar 2013 17:59:28 +0100

Dear Byju, all,

Thanks for sharing your considerations with this list.

I think that this draft also in a wider sense may add to the use cases for the host identification issue we have considered so far as a typical fmc server (here the Wireless Access Gateway, WAG) originated challenge, i.e. lawful intercept to require a unique Target identifier to locate and address a user across WiFi and other access networks.
(BTW I suggest not to use 'Home Gateway' for LMA or similar subscriber anchor point as it may be mixed up with 'Residential Gateway' at a users' home)

Furthermore we had the IPv6 prefix sharing use case http://www.ietf.org/internet-drafts/draft-sarikaya-fmc-prefix-sharing-usecase-01.txt for residential gateways where some networks may be unable to assign different prefixes to different visiting mobile hosts.

Other - more general - fmc related issues arising from application servers e.g. used both during fixed and mobile access to same service also underline the need for unique host identification. A plurality of use cases are described in http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-02. As Med mentions in that draft typical  hurdles to service usage may occur to all hosts with same IP address which also applies to fmc scenarios. Those problems cover e.g. unwanted sharing of
o  Blacklist for misbehaviour
o  Enforced policy (tayloring service offering)
o  Access denial due to failing service invoking
o  Missing correct correlation between internal address:port and external address:port required for policy issues

Finally the Unified User Identification use case (here mainly related to NAT/CGN) is described in http://www.ietf.org/internet-drafts/draft-sun-fmc-use-case-01.txt.

I would invite you to discuss details on the host ID use cases and further ideas how to proceed on this list. In any case there will be an FMC-related BarBOF organised in Orlando ... Further details will be announced shortly (although unfortunately I myself will be unable to attend the upcoming meeting ;-()
Thanks!

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: Byju Pularikkal (byjupg) [mailto:[email-masked]]
Gesendet: Montag, 18. Februar 2013 23:21
An: [email-masked]
Cc: Sri Gundavelli (sgundave)
Betreff: FW: New Version Notification for draft-pularikkal-opsawg-lawful-intercept-spwifi-00.txt

Hello,

Attached is a document on LI Architecture for SP WIFI. Comments appreciated

Thanks & Regards

Byju

On 2/18/13 3:15 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D,
>draft-pularikkal-opsawg-lawful-intercept-spwifi-00.txt
>has been successfully submitted by Byju Pularikkal and posted to the
>IETF repository.
>
>Filename:       draft-pularikkal-opsawg-lawful-intercept-spwifi
>Revision:       00
>Title:          Lawful-Intercept Support for SP Wi-Fi Deployments
>Creation date:  2013-02-18
>Group:          Individual Submission
>Number of pages: 20
>URL:
>http://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-lawful-interce
>pt-spwifi-00.txt
>Status:
>http://datatracker.ietf.org/doc/draft-pularikkal-opsawg-lawful-intercept-s
>pwifi
>Htmlized:
>http://tools.ietf.org/html/draft-pularikkal-opsawg-lawful-intercept-spwifi
>-00
>
>
>Abstract:
>   Lawful Intercept stands for legally authorized capture & delivery of
>   subscriber communications data by a communications provider to a law
>   enforcement agency.This document describes Generic Lawful Intercept
>   Architecture Models & implementation considerations for Service
>   Provider Wi-Fi deployments.
>
>
>
>
>
>The IETF Secretariat
>

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 14:40:14 +0000

Hi Byju,

Thanks for sharing this document and please apologize for my very late answer :-) I've read your document with the operator hat and outside the FMC scope, as I think your work is more generic than FMC. Firstly, I'd say that this contribution well reflects current evolution of wifi architectures and LI considerations are in line with operator practices. However, the goal of the document is not clear to me. Architecture considerations are very interesting and relevant but what do you expect from the IETF? Do you way to go for a best practices document or do you have protocol extensions in mind? 

Then, I've just clarifying questions. Why don't you consider architecture scenarios without WAC ?

The document is limited to the case where the user session is not active when LI is configured; what if the session is ongoing?

In the scenario with inter-operator roaming, it's assumed that it's the WAG will be responsible for sending the authorization request towards the roaming partner's AAA server. So, you implicitly assume AAA proxy in the WAG, right? This assumption may not be always valid. So wouldn't it rather be the AAA in the WiFi Operator's network responsible for contacting the roaming partner's AAA server also for the authorization purposes?

As already mentioned in the I-D, it seems that it may get quite complicated in the case when WAG would be capable of SIPTO-like functionality. do you plan to give more details on this topic?

CU,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 4 mars 2013 17:59
> À : [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [fmc] New Version Notification for draft-pularikkal-opsawg-
> lawful-intercept-spwifi-00.txt
> 
> Dear Byju, all,
> 
> I think that this draft also in a wider sense may add to the use cases
> for the host identification issue we have considered so far as a
> typical fmc server (here the Wireless Access Gateway, WAG) originated
> challenge, i.e. lawful intercept to require a unique Target identifier
> to locate and address a user across WiFi and other access networks.
> (BTW I suggest not to use 'Home Gateway' for LMA or similar subscriber
> anchor point as it may be mixed up with 'Residential Gateway' at a
> users' home)
> 
> Furthermore we had the IPv6 prefix sharing use case
> http://www.ietf.org/internet-drafts/draft-sarikaya-fmc-prefix-sharing-
> usecase-01.txt for residential gateways where some networks may be
> unable to assign different prefixes to different visiting mobile hosts.
> 
> Other - more general - fmc related issues arising from application
> servers e.g. used both during fixed and mobile access to same service
> also underline the need for unique host identification. A plurality of
> use cases are described in http://tools.ietf.org/html/draft-boucadair-
> intarea-host-identifier-scenarios-02. As Med mentions in that draft
> typical  hurdles to service usage may occur to all hosts with same IP
> address which also applies to fmc scenarios. Those problems cover e.g.
> unwanted sharing of o  Blacklist for misbehaviour o  Enforced policy
> (tayloring service offering) o  Access denial due to failing service
> invoking o  Missing correct correlation between internal address:port
> and external address:port required for policy issues
> 
> Finally the Unified User Identification use case (here mainly related
> to NAT/CGN) is described in http://www.ietf.org/internet-drafts/draft-
> sun-fmc-use-case-01.txt.
> 
> I would invite you to discuss details on the host ID use cases and
> further ideas how to proceed on this list. In any case there will be an
> FMC-related BarBOF organised in Orlando ... Further details will be
> announced shortly (although unfortunately I myself will be unable to
> attend the upcoming meeting ;-() Thanks!
> 
> Best regards
> Dirk
> 
> >http://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-lawful-
> inte
> >rce
> >pt-spwifi-00.txt
> >Status:
> >http://datatracker.ietf.org/doc/draft-pularikkal-opsawg-lawful-
> intercep
> >t-s
> >pwifi
> >Htmlized:
> >http://tools.ietf.org/html/draft-pularikkal-opsawg-lawful-intercept-
> spw
> >ifi
> >-00
> >
> >
> >Abstract:
> _______________________________________________
> fmc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.