Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

From: <[email-masked]>
Date: Tue, 7 May 2013 16:50:38 +0200

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-masked]] 
>Envoyé : vendredi 25 janvier 2013 08:17
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]
>Cc : [email-masked]
>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-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Monday, December 03, 2012 2:08 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>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-masked] 
>[mailto:[email-masked]] De la part de 
>[email-masked] Envoyé : lundi 3 décembre 2012 08:26 
>À : [email-masked] 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-masked]
>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-masked]
>https://www.ietf.org/mailman/listinfo/int-area
>

---

From: <[email-masked]>
Date: Wed, 29 May 2013 17:11:01 +0200

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Dienstag, 7. Mai 2013 16:51
To: 'Joshua Shire'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [fmc] draft-boucadair-intarea-host-identifier-scenarios

Dear Joshua,

Cheers,
Med

_______________________________________________
fmc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fmc