Subject: [Int-area] Nat Reveal Analysis

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Aug 2012 16:52:14 -0400

My thanks to the authors for submitting a revised version of 
draft-ietf-intarea-nat-reveal-analysis-03.

I have looked at this document, and have a few comments.
First, thank you for removing the explicit recommendation.

I find section 2.1 on IPv6 applicability somewhat confusing.  The most 
common technique I know of for topology hiding, NPT66, does so in a 
fashion that does not conflate identities.  As such, it is not obvious 
that there is an IPv6 problem.  It seems that this short section should 
either be removed or elaborated.

Minor:
     Is there a reason that the analysis in section 5 is in a different 
order than the columns of the table in section 4?  It would help the 
reader if they proceeded in the same order.
     Also, did the authors consider reversing the order of sections 4 
and 5?  In trying to read the very useful summary at the end of section 
4, I found that I kept needing to read ahead to section 5, and then go 
back to the summary.

     In the description in 5.1 of the IP-ID function, it seemed to me 
that the server would need to know in all cases whether or not this is 
being used.  I can imagine mechanisms to provide that information.  But 
the text implies that only some variants of IP-ID need such additional 
information.  Am I missing some obvious reason why it is not always 
necessary?

Nit: Is section 4.1 (requirements on the solution) really privacy 
related recommendations?  Would it make sense to call it that, and maybe 
move it into section 3 (privacy)?

I believe the concerns raised above can be easily addressed, and once 
done this document seems to be ready for advancement.

Yours,
Joel M. Halpern

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 07:35:13 +0200

Dear Joel,

Thank you for the review. 

Please see inline. 
Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : lundi 20 août 2012 22:52
>À : Internet Area
>Objet : [Int-area] Nat Reveal Analysis
>

Med: I updated the text as follows:

OLD:

   Some of the issues mentioned in Section 2 are independent of IPv4 vs.
   IPv6.  Even in IPv6, address sharing can be used for a variety of
   reasons (e.g., to hide network topology, to defeat hosts from
   offering network services directly, etc.).

NEW:

   Some of the issues mentioned in Section 2 are independent of IPv4 vs.
   IPv6.  Even in IPv6, address sharing can be used for a variety of
   reasons (e.g., to hide network topology, to defeat hosts from
   offering network services directly, etc.).

   An example is an NPTv6 translator [RFC6296] using a prefix longer
   than /56 for its algorithmic address mapping.  In such context, if a
   remote server enforces policies (e.g., blacklist a misbehaving user)
   based on the first 48 or 56 bits, several IPv6 hosts will be
   impacted.

Is the new text better?

>reader if they proceeded in the same order.

Med: The table is updated to follow the same order as in Section 5. The order is Section 5 follows the protocol layering. 

>4, I found that I kept needing to read ahead to section 5, and then go 

Med: I reversed the order of these 2 sections in my local copy. The new ToC is:

   4.  Detailed Solutions Analysis  . . . . . . . . . . . . . . . . .  7
   5.  Solutions Analysis: Synthesis  . . . . . . . . . . . . . . . . 15

>information.  Am I missing some obvious reason why it is not always 

Med: The advert mechanism is needed for all schemes. I updated the text to avoid that confusion.

OLD:

   A variant of this approach relies upon the format of certain packets,
   such as TCP SYN, where the IP-ID can be modified to contain a 16 bit
   HOST_ID.  Address sharing devices performing this function would
   require to indicate they are performing this function out of band,
   possibly using a special DNS record.

NEW:

   A variant of this approach relies upon the format of certain packets,
   such as TCP SYN, where the IP-ID can be modified to contain a 16 bit
   HOST_ID.

   Address sharing devices performing this function would require to
   indicate they are performing this function out of band, possibly
   using a special DNS record.

>move it into section 3 (privacy)?

Med: Done. The updated ToC is now:

   3.  HOST_ID and Privacy  . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Privacy-related Requirements . . . . . . . . . . . . . . .  7

>done this document seems to be ready for advancement.

Med: Thanks.

>
>Yours,
>Joel M. Halpern
>_______________________________________________
>Int-area mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Aug 2012 09:49:02 -0400

Thank you for your prompt attention.
I have removed the agreed items.
I am still confused by the proposed new IPv6 text.
The text says that if a server uses short prefixes it will apply the 
policy too coarsely.
On the one hand, that is true even if NPT66 is not used.
On the other, the solution is already present.  Use the full 128 bits. 
This does not require any new mechanisms.

Yours,
Joel

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 16:54:41 +0200

Re-,

If /128 is used to enforce the policies then there is no issue at all.
 
The point is that using /128 to black list a spammer for instance is not efficient; that's why it is likely servers will use the first 64 bits (or even /56) to install a filter....the damage can be restricted to a home premises or a large number of customers when NPTv6 is used or any other deployment context requiring the share the first 64 bits.

Does this makes sense to you?

Cheers,
Med

>De : Joel M. Halpern [mailto:[email-masked]] 
>Envoyé : mardi 21 août 2012 15:49
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Internet Area
>Objet : Re: [Int-area] Nat Reveal Analysis
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Aug 2012 11:10:40 -0400

I am sorry, but I am not following.

Yes, 128 bits is long, and a large set.
But if the spammers are using lots of different identities, then the 
server has to find some way to keep track of them.  If the set is too 
small, then different users will collide.
There are well-known techniques for looking up an ID in a large set of 
IDs.  We are not talking about black-lists, since the IDs used by a 
translator are not stable and distributable.

In fact, given the privacy issues and non-permanent ID behavior that is 
recommended by the draft, non of the IDs can be used as any form of 
black-list that is shareable and has significant lifespan.

Solving the persistent IP v6 spammer identification problem seems to be 
a VERY different problem from solving the transient subscriber 
identification to deal with short-term misbehavior and / or collision.

Yours,
Joel

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 17:13:15 +0200

Re-,

I think this needs to be discussed in a dedicated paper. I will remove that text so that the nat reveal draft be IPv4-specific. 

Cheers,
Med 

>Envoyé : mardi 21 août 2012 17:11
>> The point is that using /128 to black list a spammer for 
>instance is not efficient; that's why it is likely servers 
>will use the first 64 bits (or even /56) to install a 
>filter....the damage can be restricted to a home premises or a 
>large number of customers when NPTv6 is used or any other 
>deployment context requiring the share the first 64 bits.
>>