Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 5 Jun 2014 14:57:20 +0000

> -----Original Message-----
> From: S Moonesamy [mailto:[email-masked]]
> Sent: Thursday, June 05, 2014 7:47 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-
> identifier-scenarios-04
> 
> Hi Tiru,
> At 05:06 05-06-2014, Tirumaleswar Reddy (tireddy) wrote:
> >I support adoption of this draft.
> 
> May I ask why you support adoption of this draft ?  

My interest in this draft is that it helps solve the problem of identifying host after NAT to enforce identity based policies. 

Cheers,
-Tiru

FYI - I am also the co-author of the draft.

> Please note that I consider
> the question as a difficult one.
> 
> Regards,
> S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 05 Jun 2014 08:19:59 -0700

Hi Tiru,
At 07:57 05-06-2014, Tirumaleswar Reddy (tireddy) wrote:
>My interest in this draft is that it helps solve the problem of 
>identifying host after NAT to enforce identity based policies.

Ok.

>FYI - I am also the co-author of the draft.

I noticed that. :-)

According to RFC 6967:

   "HOST_ID specification document(s) should explain the privacy impact
    of the solutions they specify, including the extent of HOST_ID
    uniqueness and persistence, assumptions made about the lifetime of
    the HOST_ID, whether and how the HOST_ID can be obfuscated or
    recycled, whether location information can be exposed, and the impact
    of the use of the HOST_ID on device or implementation fingerprinting."

 From draft-boucadair-intarea-host-identifier-scenarios-05:

   "Privacy-related considerations that apply to means to reveal a host
    identified are discussed in [RFC6967].  This document does not
    introduce additional privacy issues than those discussed in
    [RFC6967]."

It does not look like the privacy impact has been considered by the 
authors of the document.

HOST_ID is an identifier, which according to the use cases, can be 
used in many places.  Anyone in the spying business would welcome 
such an identifier.  Will the authors be taking that into 
consideration or is it out of scope?

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 07:59:28 +0000

Hi SM,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Int-area [mailto:[email-masked]] De la part de S Moonesamy
>Envoyé : jeudi 5 juin 2014 17:20
>À : Tirumaleswar Reddy (tireddy); [email-masked]
>Objet : Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-
>identifier-scenarios-04
>
>Hi Tiru,

[Med] FWIW, the scenarios draft is not a "HOST_ID specification document". 

>It does not look like the privacy impact has been considered by the

[Med] Having a dedicated section for privacy is a signal that we have those issues on our radar. Our analysis at this stage is that RFC6967 includes a decent discussion that is still valid for this use cases document. If you think that additional concerns are to be discussed, please don't hesitate to share them. We will consider updating the document accordingly. 

>used in many places.

[Med] There is no mention of "HOST_ID" in this draft. Furthermore, the current text says the following:
"   The document does not elaborate whether explicit authentication is
   enabled or not."

Solution-specific discussions are out of scope. The main mission of the document is to help identifying use cases where there are difficulties to enforce per-host policies due to the presence of address sharing or the use of tunnels. 

  Anyone in the spying business would welcome
>consideration or is it out of scope?

[Med] Documenting misuses should be definitely in scope. Contributions are more than welcome.

>
>Regards,
>S. Moonesamy
>
>_______________________________________________
>Int-area mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/int-area

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 6 Jun 2014 08:03:19 +0000

> Sent: Thursday, June 05, 2014 8:50 PM
> It does not look like the privacy impact has been considered by the authors of
> the document.
> 
> HOST_ID is an identifier, which according to the use cases, can be used in many
> places.  Anyone in the spying business would welcome such an identifier.  Will
> the authors be taking that into consideration or is it out of scope ?

The privacy impact of the use cases is within the scope of this document. The use cases are only listing existing problems of host identification with NAT, in future when solutions for each of these use cases are proposed they should also discuss the impact on privacy. For example use cases like http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05#section-7 the host identifier is added by NAT and removed by PCEF in the same network and thus the host identifier is not even visible to attacker sniffing packets and for the Femtocells use case, FAP Gateway needs a mechanism to learn the FAP public IP address and I don't see a privacy problem in this use case. 

Cheers,
-Tiru

---

From: S Moonesamy <[email-masked]>
Date: Fri, 06 Jun 2014 05:55:40 -0700

Hi Med,
>[Med] FWIW, the scenarios draft is not a "HOST_ID specification document".

[snip]

>[Med] Having a dedicated section for privacy is a signal that we 
>have those issues on our radar. Our analysis at this stage is that 
>RFC6967 includes a decent discussion that is still valid for this 
>use cases document. If you think that additional concerns are to be 
>discussed, please don't hesitate to share them. We will consider 
>updating the document accordingly.

[snip]

>Solution-specific discussions are out of scope. The main mission of 
>the document is to help identifying use cases where there are 
>difficulties to enforce per-host policies due to the presence of 
>address sharing or the use of tunnels.

[snip]

>Contributions are more than welcome.

 From the above (quoted text) I understand that there are 
difficulties to enforce policies and those difficulties have not be 
discussed or addressed in IETF RFCs.  The INTAREA working group 
previously worked on a RFC about potential solutions for revealing a 
host identifier.   Are the potential solutions discussed in RFC 6967 
inadequate?  I don't think the question is out of scope given that 
the draft references RFC 6967.

If the mission is to identify use cases, why are discussions about 
the use cases (see Section 2) out of scope?

The lack of host identification does not affect host 
connectivity.  This scenarios draft makes the case for the lack of 
host identification being the cause of problems.  Do the problems 
affect the internet or are they limited cases?

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 14:24:06 +0000

Hi SM, 

Please see inline.

Cheers,
Med

>De : S Moonesamy [mailto:[email-masked]]
>Envoyé : vendredi 6 juin 2014 14:56
>À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
>[email-masked]
>Objet : RE: [Int-area] Call for adoption of draft-boucadair-intarea-host-
>identifier-scenarios-04
>
>Hi Med,
>discussed or addressed in IETF RFCs.

[Med] Yes. 

  The INTAREA working group
>inadequate?

[Med] The effort in RFC6967 does not ambition to pick a solution but to conduct an analysis effort with a focus on the CGN case. That case is only one among others defined in the scenario draft. Identify and document the use cases is a first step to actually understand the problem we are talking about. This is a contribution to clarify the big picture of this problem space. 

  I don't think the question is out of scope given that
>the draft references RFC 6967.

[Med] Privacy is not out of scope as I mentioned in a previous message. Nevertheless, privacy implications may depend on the targeted use case. The considerations in RFC6967 can be completed with new ones if any.

>the use cases (see Section 2) out of scope?

[Med] What we declared out of scope is solution-oriented aspects. We wanted to have a very focused document.

>host identification being the cause of problems.

[Med] The draft focuses only on scenarios where complications arise. The problem may be abstracted from other perspective but the host identification is a valid angle IMHO. 

  Do the problems
>affect the internet or are they limited cases?

[Med] Implication on connectivity depends on the use cases. For example, a service that black list a full IP address  or rate limit based on the source IP address will impact a lot of customers; access to services won't be granted.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Jun 2014 12:10:17 -0700

Hi Med,
At 07:24 11-06-2014, [email-masked] wrote:
>[Med] The effort in RFC6967 does not ambition to pick a solution but 
>to conduct an analysis effort with a focus on the CGN case. That 
>case is only one among others defined in the scenario draft. 
>Identify and document the use cases is a first step to actually 
>understand the problem we are talking about. This is a contribution 
>to clarify the big picture of this problem space.

I left in my previous comment as it may be easier for the reader to 
understand the discussion.

The previous comment mentioned "potential solutions discussed in RFC 
6967".  In my opinion the above response does not provide an answer 
to the question.

You made an interesting point, i.e. clarify the big picture.  I read 
the RFCs coming from INTAREA.  There was one about "Issues with IP 
Address Sharing" in June 2011.  There is another one about "Analysis 
of Potential Solutions for Revealing a Host Identifier (HOST_ID) in 
Shared Address Deployments" in June 2013.  Now there is a draft about 
"Host Identification: Use Cases".  I haven't seen a discussion of 
that big picture on this mailing list.  My understanding of the 
documents is that the working group is make a case (the word is used 
loosely) for host identification.

>[Med] Privacy is not out of scope as I mentioned in a previous 
>message. Nevertheless, privacy implications may depend on the 
>targeted use case. The considerations in RFC6967 can be completed 
>with new ones if any.

Ok.  I assume that the working group has the expertise and energy to 
do that work.

>wanted to have a very focused document.

This is what I read from the draft:

   "It is out of scope of this document to argue in favor or against the
    use cases listed in the following sub-sections."

That is different from the above response.

I'll wait for the Working Group Chairs to take their decision.

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 06:57:12 +0000

Hi SM,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 11 juin 2014 21:10

[Med] The analysis of the solutions discussed in RFC6967 was drawn with a particular focus on "Carrier-Grade NAT (CGN), application proxies, or Address plus Port (A+P)." (Excerpt from RFC6967) + an ** Internet-wide ** scope. Some parts of that analysis is "inappropriate" for some cases that are restricted to ** a single administrative domain **. For example, using an IP option is not a viable solution for the Internet-wide cases, but this option can be investigated further for the single domain case. 

>loosely) for host identification.

[Med] The documents produced so far by intarea focus on address sharing (read CGNs, A+P). The scenarios draft aims to provide the big picture view by gathering a list of cases that suffer from similar problems that we abstracted as "host identification problem". The inventory of these cases is IMHO useful to understand the problem space and avoid restricting it to the single CGN case. It also provides a tool to rationalize the solution design effort: For example, the current situation is that one who reads RFC7239 won't be able to link it effort to RFC6967! 

>    use cases listed in the following sub-sections."

[Med] The current version of the scenarios draft includes some cases that can be considered as deployment-specific (see for instance the case of offering Provider Wi-Fi by re-using CPE resources "Use Case#4"). These case are listed because authors are aware of such plans: a concrete example "Use Case#4" corresponds to what is mentioned in slide 12 of www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip. The sentence you quoted is a warning that the authors are not taking position for these deployments.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Jun 2014 08:31:12 -0700

Hi Med,

Thanks for the response.

At 23:57 12-06-2014, [email-masked] wrote:
>[Med] The documents produced so far by intarea focus on address 
>sharing (read CGNs, A+P). The scenarios draft aims to provide the 
>big picture view by gathering a list of cases that suffer from 
>similar problems that we abstracted as "host identification 
>problem". The inventory of these cases is IMHO useful to understand 
>the problem space and avoid restricting it to the single CGN case. 
>It also provides a tool to rationalize the solution design effort: 
>For example, the current situation is that one who reads RFC7239 
>won't be able to link it effort to RFC6967!

RFC 7239 has some history. :-)  In my opinion the effort for that RFC 
was unrelated to RFC 6967.  I took a quick look at the (public) 
discussion about that document before writing this.  Anyway, there is 
a little omission in that document which could have been a security 
issue if the publication of that document was requested after October 2013.

>[Med] The current version of the scenarios draft includes some cases 
>that can be considered as deployment-specific (see for instance the 
>case of offering Provider Wi-Fi by re-using CPE resources "Use 
>Case#4"). These case are listed because authors are aware of such 
>plans: a concrete example "Use Case#4" corresponds to what is 
>mentioned in slide 12 of 
>www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip. 
>  The sentence you quoted is a warning that the authors are not 
>taking position for these deployments.

I hope that the WG Chairs won't use Section 2 to restrict the 
discussions.  The Call for adoption ( 
http://www.ietf.org/mail-archive/web/int-area/current/msg03879.html ) 
is scanty on the details.

Regards,
S. Moonesamy