Hi Med, all, I see also the section 3.7 on femto cells with high security demands for tunneled (mobile) data via IPSec through the fixed network.
Another question is whether to include also a scenario for NAT46 addressing IPv4 clients at end user nodes connected to both IPv6 RGW and IPv6 access network? I think while many operators are starting to deploy IPv6 in their core and aggregation networks there will always be (maybe old fashioned) customers which continue to use their available equipment, e.g. for telephony. Perhaps this is already handled, e.g. in UC 3.6, but I couldn't find NAT46 to be mentioned. Did I miss something? What do you think? Thanks! Best regards Dirk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Dienstag, 7. Mai 2013 16:51 To: 'Joshua Shire'; [email protected]; [email protected] Cc: [email protected] Subject: Re: [fmc] draft-boucadair-intarea-host-identifier-scenarios Dear Joshua, Apologies for the delay to answer this message. I see your point. I will add it to the list of items to be considered for the next iteration of the document. BTW, -03 already included some of requirements which cover security aspects (see for instance REQ#1, REQ#2, REQ#3, REQ#9). Once we have a stable requirements list, we will identify the requirements which are valid for each use case: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-03#section-4.1 Cheers, Med >-----Message d'origine----- >De : Joshua Shire [mailto:[email protected]] >Envoyé : vendredi 25 janvier 2013 08:17 >À : BOUCADAIR Mohamed OLNC/OLN; [email protected]; [email protected] >Cc : [email protected] >Objet : RE: draft-boucadair-intarea-host-identifier-scenarios > >Hello, > >I do not believe a pointer to >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys >is-04#section-3 will be satisfactory for the security >considerations section. > >http://www.ietf.org/rfc/rfc3552.txt states that when writing >a security considerations section, the process "...should be >approached as an effort to perform "due diligence" in >describing all known or foreseeable risks and threats to >potential implementers and users." Normally we see RFCs >describing more applied topics such as protocols, so the >specific language and examples given in the above mentioned >RFC may not seem directly applicable. However, "in spirit", >the document seems clear in requiring all RFCs to examine in >detail their potential security impact. > >As I'm sure we're all aware, some of the use cases identified >are purposefully implemented to maintain the confidentiality >of a client's identity (e.g. NAT to obfuscate the structure of >an enterprise network, Open-Wifi to conceal the identity of a >client under threat of persecution [or prosecution], etc.). > >Thus, in identifying these scenarios as sharing the "issue" of >host identification, the author would seem to be required to >discuss the potential security implications of treating the >lack of host identification as such, rather than a desirable feature. > >Thanks, > >Joshua Shire >Information Systems Manager >Hyduke Energy Services Inc. > >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of >[email protected] >Sent: Monday, December 03, 2012 2:08 AM >To: [email protected]; [email protected] >Cc: [email protected] >Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios > >Dear all, > >We submitted an updated version of this draft to list use >cases which encounter the issue of host identification. The >following use cases are discussed in the draft: > > (1) Carrier Grade NAT (CGN) > (2) A+P (e.g., MAP ) > (3) Application Proxies > (4) Provider Wi-Fi > (5) Policy and Charging Architectures > (6) Cellular Networks > (7) Femtocells > (8) Overlay Networks (e.g., CDNs) > >The document does not include any solution-specific >discussion. Its main goal is to identify the use cases and >describe them. > >If you think your use case is not included in this version, >please share it with us. > >Comments are welcome. > >Cheers, >Med > > >-----Message d'origine----- >De : [email protected] >[mailto:[email protected]] De la part de >[email protected] Envoyé : lundi 3 décembre 2012 08:26 >À : [email protected] Objet : I-D Action: >draft-boucadair-intarea-host-identifier-scenarios-02.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Host Identification: Use Cases > Author(s) : Mohamed Boucadair > David Binet > Sophie Durel > Tirumaleswar Reddy > Brandon Williams > Filename : >draft-boucadair-intarea-host-identifier-scenarios-02.txt > Pages : 14 > Date : 2012-12-02 > >Abstract: > This document describes a set of scenarios in which host > identification is required. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-i >dentifier-scenarios > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-intarea-host-identif >ier-scenarios-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-i >dentifier-scenarios-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >Int-area mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ fmc mailing list [email protected] https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
