Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

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: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] 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.
> 

Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

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

Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

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

On 7/2/2012 1:36 PM, Dan Wing wrote:
> 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

Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

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

On 6/27/2012 8:57 AM, Suresh Krishnan wrote:
> 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

Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

On Jul 5, 2012, at 22:48, Alissa Cooper wrote:
> 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.

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

_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

On 7/6/2012 12:39 AM, Eggert, Lars wrote:
> On Jul 5, 2012, at 22:48, Alissa Cooper wrote:
>> 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.
>
> 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

Comments on draft-ietf-intarea-nat-reveal-analysis-02

Hello,

I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02.

In Section 1.1:

   "Examples of such issues are listed below:"

     "Redirect users with infected machines to a dedicated portal"

Why is this an issue?

   "The risk of not mitigating these issues are: OPEX increase for IP"

I suggest expanding "OPEX" on first use.

In Section 2:

   "Tomorrow, due to the introduction of CGNs (e.g., NAT44
    [RFC3022], NAT64 [RFC6146]), that address will be shared."

Isn't IPv4 shared addresses already in use in the wild?

In Section 2.1:

   "A solution to reveal HOST_ID is also needed in IPv6 deployment."

I suggest soliciting feedback from V6OPS about this.

The draft already mentions that the issue is caused by IPv4 address 

Re: Comments on draft-ietf-intarea-nat-reveal-analysis-02

_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Working group summaries

All,
      With the Internet Area being large (25 Working Groups) and 
diverse, it can be time consuming for participants to track the 
activities that may affect them.  To help keep people up to date, we 
have asked the chairs of each WG within the area to generate a brief 
update on their WG's progress.  These updates will be done at the end of 
each IETF meeting and posted to the INT Area wiki 
(http://trac.tools.ietf.org/area/int/trac/wiki).

      The goal of these summaries is not to give an in-depth assessment 
of all the happenings within a WG.  Rather, it should be a set of 
highlights that may be of interest to people not actively involved in 
the WG.  We hope that these reports will be useful to the INT Area 
community.

Regards,
Brian & Ralph

Re: Comments on draft-ietf-intarea-nat-reveal-analysis-02

I read the document and came to rather different conclusions (see
below):

On 7/9/2012 4:41 PM, Tina TSOU wrote:
> I reviewed this draft and I found it very detailed about the various
> ways of including a HOST ID. Considering the number of users that share
> the same IPv4 address, there is an increasing importance of the HOST ID.
> Though it is discussed in the introduction about the various
> implications of not having HOST IDs, in my opinion, there should be a
> little more explanation of the problems faced if there is no HOST ID
> included. Moreover, the main concern is security issue. It is very
> difficult to identify a particular user, when there are a number of
> users with different private IP addresses sharing the same public address.

I agree with you that if the document is pursued, it should include
more discussion of what the problems are with not having a host ID;
the current text seems like handwaving to me.  I don't personally
think it is very well motivated, and from my standpoint there is
absolutely no reason to pursue a solution.  It would be enough to
simply have the analysis documented as to why all of the considered
approaches COMPLETELY STINK.

But aside from that, I disagree with you on purpose of whatever is
being attempted here.  The document is about identifying hosts, and
you mention "users".  These are not the same thing.  Which do you want
to identify?  In my opinion, anything related to users (and not hosts)
should be completely out of scope.

Further, I think the problem has to perhaps be refined to
disambiguating between different hosts using the same IP address
versus trying to semi-uniquely identify the hosts.  The problems
described are due to aliasing, and unique identification is a
rather strong means of de-aliasing.

> The TCP option is another good way to include the HOST ID in case of TCP
> and UDP communications. 

Surely there's a typo there, since it does not work at all in the
case of UDP.

I disagree with the overall recommendation of the document, since
it presumes that a solution is required, among other flaws with it.

Additionally, it is not particularly clear how this can work for
multiple layers of sharing (e.g. CGN), though draft-abdo seems to
think that CGN is a single layer of sharing.

--

-- 
Wes Eddy
MTI Systems