Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

[Brian Haberman <[e-mail]>]

Hi Suresh,

On 2/11/13 7:08 PM, Suresh Krishnan wrote:
> Hi Brian,
>    Thanks for the review. I wanted to clarify three points that you
> raised and I will ask the authors take care of the rest.
>
> On 02/11/2013 04:11 PM, Brian Haberman wrote:
>> 7. In Section 4.1.2, it would be good to describe any issues that the
>> approach has with the original use of the Identification field for
>> fragmentation reassembly.  If a middlebox changes the ID field, weird
>> things can/will happen if those packets are fragmented somewhere.
>
> Agree. I think this is precisely the reason that the mechanism for
> putting the HOST_ID in the IP-ID is a non-starter.

I agree.  But that rationale should be in the draft.

>
>> 11. Is Section 4.6 theoretical or is there a specific reference that can
>> be added for this technique?
>
> There are several mechanisms that use port sets for IPv4 address
> sharing. A+P (RFC6346) is one such mechanism.

Then I would ask that a reference be put in to give readers an example.

>
>> 15. Section 5
>>
>> * Shouldn't there be an additional metric that covers the impact/cost of
>> needing client or middlebox code changes?
>>
>> * Where did the 100% success ratio for IP-ID come from?  There have been
>> documented cases of OSes setting the Identification field to zero.  If
>> that is true, the success ratio can't be 100% can it?
>
> This technique involves the translator (and not the sender) setting the
> IP-ID field. That is why it can still work with OSes on senders setting
> the IP-ID to zero.

You still have the issue of the middlebox setting that ID to something 
that potentially impacts fragmentation reassembly.  So, I would still 
like to know how that 100% success ratio was collected.

Regards,
Brian