Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jul 2012 13:36:47 -0700

I support draft-ietf-intarea-nat-reveal-analysis going forward.

I would like the draft to include a citation of MAP
(draft-ietf-softwire-map), and mention MAP in its abstract.  This is because
many technologists assume address sharing only occurs with NAT, even though
it occurs with a bunch of other technologies.  On this point, I noticed
"application proxies" is mentioned in the abstract (which is good), but
application proxies are not mentioned again in the introduction to
draft-ietf-intarea-nat-reveal-analysis nor mentioned in RFC6269 ("Issues
with IP Address Sharing").

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Suresh Krishnan
> Sent: Wednesday, June 27, 2012 8:57 AM
> To: Internet Area
> Subject: [Int-area] ACTION REQUIRED: Extending working group last call
> for draft-ietf-intarea-nat-reveal-analysis-02
> 
> Hi all,
>   The WGLC on this draft ended with no comments at all. In this
> context,
> we cannot assume that silence equates to consent. In order for this
> draft to progress, we need people to read the draft and provide their
> opinions on whether the draft is ready. To enable people to comment,
> the
> last call period is extended until Friday July 6, 2012.
> 
> Thanks
> Suresh and Julien
> 
> On 06/08/2012 10:06 AM, Suresh Krishnan wrote:
> > Hi all,
> >   This message starts a two week intarea working group last call on
> > advancing the draft about Analysis of Solution Candidates to Reveal a
> > Host Identifier (HOST_ID) in Shared Address Deployments as an
> > Informational RFC. The draft is available at
> >
> > http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt
> > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02
> >
> > Substantive comments and statements of support/opposition for
> advancing
> > this document should be directed to the mailing list. Editorial
> > suggestions can be sent directly to the authors. This last call will
> > conclude on June 22, 2012.
> >
> > Regards,
> > Suresh & Julien
> > _______________________________________________
> > Int-area mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Jul 2012 16:48:44 -0400

With the changes to this draft in the -02 version, I'm having a little trouble seeing its purpose. It basically now seems like a shell for the recommendation in 3.3, with the analysis stuffed into appendices. But given that there is no stable proposal for the actual TCP option to be implemented, what is the purpose for advancing this document right now? I think I've heard that folks "needed to know what to implement," but does this document really resolve that problem given that even within the space of TCP-option-based solutions for this, there are multiple different proposals, none of which has been standardized? This document made more sense when it was just a comparison of the different potential solutions spaces.

Some other comments:

Section 2 claims that for all solutions analyzed, the draft explains what the HOST_ID is. I don't think this is true for the TCP option solution for the application header solution. Even the specific solution proposals for both of those (draft-wing-nat-reveal-option or draft-ietf-appsawg-http-forwarded) are not specific about the limits to which IDs can be inserted.

Section 3.1: Is this really specifying requirements for all solutions? Is that sort of a self-fulfilling prophecy for a document that already has a solution chosen?

Given that the Forwarded header is being standardized, it seems like references to XFF should be reduced to places where existing deployments are being discussed (as opposed to encouraging the use of XFF, e.g., in A.8.1, "service providers...can enable the feature of injecting the XFF header"). 

As a general matter I think it would be helpful for this document to be reviewed by some appsarea folks and/or the authors of draft-ietf-appsawg-http-forwarded. It seems like A.8.1 and A.8.2 contradict each other about whether header information is preserved through multiple address sharing functions. Also, if XFF is in such widespread use, the question of what to do when the TCP option and the XFF header conflict seems like something that needs to be resolved.

It seems odd to reference "earlier versions" of draft-wing-nat-reveal-option in A.5.2 rather than just explaining why this option is limited to SYN. This seems like an artifact of the oddness of having a whole document just to recommend an as-yet-unspecified solution.

Cheers,
Alissa

On Jun 27, 2012, at 11:57 AM, Suresh Krishnan wrote:

> Hi all,
>  The WGLC on this draft ended with no comments at all. In this context,
> opinions on whether the draft is ready. To enable people to comment, the
>> Substantive comments and statements of support/opposition for advancing

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Jul 2012 16:54:41 -0700

BTW, the MAP doc cites RFC 6145, which has errors as follows:

1. it sets IPv4 ID=0 when IPv6 lacks a frag header
     that will hopefully be possible after ipv4-id-update is final,
     but wasn't valid a the time the doc was published

2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is 
invalid
     that field might not follow the ID uniqueness criteria of IPv4

3. the system assumes IPv4 can reassemble 1280 byte packets
     but only 576 can be assumed

I've brought these to the attention of the authors...

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Jul 2012 17:17:27 -0700

As a co-author, I didn't want to remain silent per se, so I'll at least 
be public in my view.

I think the doc is good, but I do take Alissa's concerns to point - it 
might be preferable to remove section 3.3 and leave this doc as a 
comparison of solutions, and avoid any recommendation of a way forward 
at this point.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 6 Jul 2012 07:39:41 +0000

> With the changes to this draft in the -02 version, I'm having a little trouble seeing its purpose. It basically now seems like a shell for the recommendation in 3.3, with the analysis stuffed into…

Fully agree with Alissa. An comparison of options would be fine. But 3.3 and other text go beyond a comparison.

I also don't understand why INTAREA is entertaining work that is clearly intending to define new TCP options. None of the -abdo- drafts have been presented in TCPM or even discussed on the mailing list. (My guess is that the authors know that this would never get traction in TCPM and are venue shopping.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Jul 2012 15:29:45 -0700

On 7/6/2012 12:39 AM, Eggert, Lars wrote:
> I also don't understand why INTAREA is entertaining work that is
> clearly intending to define new TCP options. None of the -abdo- drafts
> have been presented in TCPM or even discussed on the mailing list. (My
> guess is that the authors know that this would never get traction in
> TCPM and are venue shopping.)

FWIW, this doc discusses existing alternatives, including proposed ones 
that have been documented, based on pros/cons. It doesn't make an 
assessment of the viability of approaches as ways forward in the IETF.

(and I agree it should probably not make any single positive 
recommendation; it might be OK to indicate which solutions aren't 
viable, though)

Joe

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Jul 2012 14:55:31 -0400

Hi all,
  After going through the responses to the WGLC, it is clear that the
draft is not ready to go forward in the publication process. We will
discuss further steps for this draft at the Vancouver meeting.

Thanks
Suresh & Julien

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 09:03:24 +0200

Dear Joe, all,

Apologies for the delay to answer (I was out of office).

I have no problem to remove Section 3.3 if this is what the WG wants. As a reminder, I added that section after the Paris meeting in accordance with what I heard in the meeting: more voices in favour of adding a recommendation. I sent a notification to the mailing list mid-april to acknowledge this change. 

Now, I'm waiting for a feedback from the WG to maintain or to remove Section 3.3.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Joe Touch
>Envoyé : vendredi 6 juillet 2012 02:17
>À : Suresh Krishnan
>Cc : Internet Area
>Objet : Re: [Int-area] ACTION REQUIRED: Extending working 
>group last call for draft-ietf-intarea-nat-reveal-analysis-02
>

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 09:10:38 +0200

Dear Lars,

Please see inline.

Cheers,
Med 

>[mailto:[email-masked]] De la part de Eggert, Lars
>Envoyé : vendredi 6 juillet 2012 09:40
>À : Alissa Cooper
>Cc : Internet Area
>> With the changes to this draft in the -02 version, I'm 
>having a little trouble seeing its purpose. It basically now 
>seems like a shell for the recommendation in 3.3, with the 
>analysis stuffed into appendices. But given that there is no 
>stable proposal for the actual TCP option to be implemented, 
>what is the purpose for advancing this document right now? I 
>think I've heard that folks "needed to know what to 
>implement," but does this document really resolve that problem 
>given that even within the space of TCP-option-based solutions 
>for this, there are multiple different proposals, none of 
>which has been standardized? This document made more sense 
>when it was just a comparison of the different potential 
>solutions spaces.
>
>Fully agree with Alissa. An comparison of options would be 
>fine. But 3.3 and other text go beyond a comparison.

Med: FYI I added Section 3.3 after the Paris meeting where I asked the question whether we need to add a recommendation or not. It seems to me I heard more voices for having a recommendation in the document. A notification has been sent to this mailing list in mid-april. Anyway, I'm open to record the consensus of the WG: maintain or remove that section. 

>
>I also don't understand why INTAREA is entertaining work that 
>is clearly intending to define new TCP options.

Med: This draft is not about the TCP option but to analyze a set of solutions to solve a problem already documented in RFC6069. 

 None of the 
>-abdo- drafts have been presented in TCPM or even discussed on 
>the mailing list. (My guess is that the authors know that this 
>would never get traction in TCPM and are venue shopping.)

Med: I checked tcpm agenda, draft-abdo will be presented in tcpm in Vancouver.

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 10:25:44 +0200

Dear Suresh, all,

After reading received comments, the major point we need to discuss is whether the WG wants to remove Section 3.3 or maintain it. I'm waiting for a feedback from the WG for the direction to take. I will implement any change requested by the WG.

Cheers,
Med

>[mailto:[email-masked]] De la part de Suresh Krishnan
>Envoyé : vendredi 20 juillet 2012 20:56
>À : Internet Area
>Objet : [Int-area] Completion of working group last call for 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>Hi all,

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Jul 2012 11:22:21 -0500

Hi Med,

> Med: This draft is not about the TCP option but to analyze a set of solutions to solve a problem already documented in RFC6069.

RFC 6069 is about TCP-LCD?

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Jul 2012 12:08:49 -0500

> After reading received comments, the major point we need to discuss is whether the WG wants to remove Section 3.3 or maintain it. I'm waiting for a feedback from the WG for the direction to take. I…

Section 3.3 seems to give preference to one specific solution, as such
it is against the whole spirit of this document.

I suggest removing it.

Behcet

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 26 Jul 2012 14:33:39 -0400

> it is against the whole spirit of this document.

+1

In fact, I suggest that the draft should clearly say that it's
doubtful whether a solution actually *needs* to be identified and
recommended, especially ones that are implemented awkwardly in other
layers.

-- 
Wes Eddy
MTI Systems

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 08:59:43 +0200

Hi Behcet,

Ooops, I wanted to quote RFC6269. Thanks. 

Cheers,
Med

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : jeudi 26 juillet 2012 18:22
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Eggert, Lars; Alissa Cooper; Internet Area

>> Med: This draft is not about the TCP option but to analyze a 
>set of solutions to solve a problem already documented in RFC6069.
>>
>

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 09:09:22 +0200

Hi Behcet,

The argument I heard in Paris meeting for including a recommendation is to help vendors to select the solution to implement in their devices. They can not provide the same feature using 8 implementation options. That argument makes sense to me. 

Now, as I said earlier, I will remove or maintain that section according to the guidance from the WG. 

Cheers,
Med 

>Envoyé : jeudi 26 juillet 2012 19:09
>Cc : Suresh Krishnan; Internet Area
>Objet : Re: [Int-area] Completion of working group last call 
>> After reading received comments, the major point we need to 
>discuss is whether the WG wants to remove Section 3.3 or 
>maintain it. I'm waiting for a feedback from the WG for the 
>direction to take. I will implement any change requested by the WG.
>>
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 27 Jul 2012 16:28:31 +0000

> The argument I heard in Paris meeting for including a recommendation is to help vendors to select the solution to implement in their devices. They can not provide the same feature using 8 implement…

We're not at the stage yet where we can recommend anything to vendors. We first need to determine if there even is a solution where the benefits outweigh the drawbacks.

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jul 2012 09:46:16 -0700

> Behalf Of Eggert, Lars
> Sent: Friday, July 27, 2012 9:29 AM
> To: [email-masked]
> Cc: Internet Area
> Subject: Re: [Int-area] Completion of working group last call for
> > The argument I heard in Paris meeting for including a recommendation
> > is to help vendors to select the solution to implement in their
> > devices. They can not provide the same feature using 8 implementation
> > options. That argument makes sense to me.
> 
> We're not at the stage yet where we can recommend anything to vendors.
> We first need to determine if there even is a solution where the
> benefits outweigh the drawbacks.

What analysis is missing from draft-ietf-intarea-nat-reveal-analysis
to weigh the drawbacks of the 8 solutions.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jul 2012 11:03:46 -0700

> Behalf Of Wesley Eddy
> Sent: Thursday, July 26, 2012 11:34 AM
> To: [email-masked]
> Cc: Internet Area; Behcet Sarikaya
> >> After reading received comments, the major point we need to discuss
> is whether the WG wants to remove Section 3.3 or maintain it. I'm
> waiting for a feedback from the WG for the direction to take. I will
> implement any change requested by the WG.
> >>
> >

I can't make technical sense of which of the 8 approaches are "awkward," in
your analysis.  I have my own analysis, but the document does not do an
evaluation on "awkwardness".  

The underlying problem was identified in Section 13.1 "Abuse Logging and
Penalty Boxes" of RFC6269, "Issues with IP Address Sharing",
http://tools.ietf.org/html/rfc6269#section-13.1.  That was an INTAREA
document.  

Hence, that is why the analysis document is also an INTAREA document.

My view is the penalty box problem described in Section 13.1 of RFC6269 is
real.  My view is the penalty box problem will continue to grow so long as
there are IPv4-accessible servers and so long as there are IPv6 clients
(NAT64) or IPv4 clients accessing those IPv4 servers.  There appear to be
different views on the size and trajectory of the problem (getting worse
versus getting better).  Perhaps discussing those views would be beneficial.

-d

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 28 Jul 2012 03:27:46 -0400

> versus getting better).  Perhaps discussing those views would be beneficial.

Hi Dan - The problem is real because there are bits of
deployed code built on an assumption that was good maybe
12 years ago, that IP addresses could be tied to users or
machines.  Since this is totally broken now, the solution
is to get rid of them and use the proper identifiers for
whatever it is that these system are trying to do.  Building
kludges in other layers to supplement the IP address is
not the answer.

Since the analysis in the document already indicates that
each of the 8 solutions has non-starter properties to them,
I consider that to make them pretty "awkward".  Recommending
any of them is like saying "this is the best tasting crap
we could find."

-- 
Wes Eddy
MTI Systems

---

From: Francis Dupont <[email-masked]>
Date: Sun, 29 Jul 2012 19:29:43 +0200

>  to weigh the drawbacks of the 8 solutions.

=> there are two kinds of drawbacks: the technical drawbacks and the not
technical drawbacks, e.g., the impact on privacy... Note because if the
second kind I am strongly against the 3.3 (if not changed into a SHOULD
NOT :-) and I suggested to "NOT RECOMMEND" all proposals perhaps at
the exception of one (i.e., leave one proposal without any recommendation).

Regards

[email-masked]

PS: IMHO only the not advertised port set makes sense, any other proposal
deployed in countries where privacy is protected (any place in European
Union for instance) should make the ISP to be sued...
PPS: we can postpone the discussion to Berlin meeting (privacy concerns
are pushed in Germany clearly behind the sillyness point :-).

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Jul 2012 23:17:26 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, July 29, 2012 10:30 AM
> To: Dan Wing
> Cc: 'Eggert, Lars'; [email-masked]; 'Internet Area'

You keep saying "privacy", but without explaining the problem or
how IPv4 address sharing makes privacy better or worse than IPv6.
Without that, 

-d

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 08:41:29 +0200

Dear Lars,

Could be more explict and explain what is missing in draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage?

Thanks.

Cheers,
Med

>De : Eggert, Lars [mailto:[email-masked]] 
>Envoyé : vendredi 27 juillet 2012 18:29
>Cc : [email-masked]; Internet Area
>> The argument I heard in Paris meeting for including a 
>recommendation is to help vendors to select the solution to 
>implement in their devices. They can not provide the same 
>feature using 8 implementation options. That argument makes 
>sense to me. 
>
>We're not at the stage yet where we can recommend anything to 
>vendors. We first need to determine if there even is a 
>solution where the benefits outweigh the drawbacks.
>
>Lars

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Jul 2012 10:48:38 -0400

Med,
      My opinion, not as AD, is that this document should not make a 
recommendation.   This document should be strictly an analysis so that 
we have a baseline understanding of all the existing solutions.

Brian

On 7/30/12 2:41 AM, [email-masked] wrote:
> Dear Lars,
>
> Could be more explict and explain what is missing in
> draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage?
>
> Thanks.
>
> Cheers, Med
>
>
>> -----Message d'origine----- De : Eggert, Lars
>> [mailto:[email-masked]] Envoyé : vendredi 27 juillet 2012 18:29 À
>> : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : [email-masked]; Internet
>> Area Objet : Re: [Int-area] Completion of working group last call
>> implement in their devices. They can not provide the same feature
>> using 8 implementation options. That argument makes sense to me.
>>
>> vendors. We first need to determine if there even is a solution
>> where the benefits outweigh the drawbacks.
>>
>> Lars
> _______________________________________________ Int-area mailing
> list [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jul 2012 18:09:16 +0200

>  how IPv4 address sharing makes privacy better or worse than IPv6.

=> there are two levels about the privacy problem: the technical one
which is explained/addressed in the draft (section 4) and worse the
way it can be perceived which is less (or not at all) rational as
the long and silly history of the "privacy extensions for stateless
address autoconfiguration in IPv6" (RFC 3041 and 4941) has shown.

So there is a technical and a "political" argument against the whole
HOST_ID idea. Unfortunately the IETF (and this mailing list) can only
deal with the first one.

Regards

PS: to discuss about the technical point IMHO no HOST_ID proposal brings
a clear advantage. The real issue (address sharing breaks the address ==
identity assumption) has to be solved by the impacted part (i.e., people
should accept this assumption doesn't apply)...

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 30 Jul 2012 16:40:35 +0000

Hi,

> Could be more explict and explain what is missing in draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage?

the goal of this draft was to survey the options. I don't think it should make any recommendation at all.

If there was a solution for which the benefits outweigh the drawbacks (which I don't think there is), the adoption of a document that specifies it by the IETF and the eventual publication of that document would constitute an IETF recommendation.

Lars