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

[Brian Haberman <[e-mail]>]

On 2/13/13 11:12 AM, [e-mail] wrote:

>> I would suggest re-ordering the table so that deployed approaches are
>> collected together (and labeling them as deployed).  If the HTTP
>> Forwarded header is the only deployed approach, I would simply add a
>> note for the others stating whether they are a documented
>> proposal or a
>> theoretical construct.
>
> Med: I added these two notes:
>
>   (7)  The solution is a theoretical construct.
>   (8)  The solution is a documented proposal.
>
> And updated the table accordingly.

That should work.


>>> It should also note that there may be
>>>> issues with the fact that some IP addresses will be shared and
>>>> others may not.  How does that impact the performance of these
>>>> mechanisms?
>>>
>>> Med: The document assumes the address sharing function injects the
>>> host identifier. BTW, there is already a performance criterion listed
>>> in Figure 3.
>>>
>>
>> I was thinking more generically than the performance
>> criterion.  Suppose
>> a server employs the IP-ID approach.  If several packets
>> arrive with the
>> same source IP address and the same value in the IP-ID field, there is
>> no way to know if the IP-ID value was injected by a NAT/CGN
>> box.  Or is
>> your response saying that scenario is covered by the metrics used in
>> Figure 3?  If so, which metric?  None of the descriptive text
>> in Section
>> 5 talks about this type of issue.
>
> Med: For the particular case of IP-ID, we assume the address sharing function does not assign the same ID under the same IP address during a given interval time. The following note:
>
>       (1)  Requires mechanism to advertise NAT is participating in this
>            scheme (e.g., DNS PTR record).
>
> Is here to precise another mechanism is needed to inform the server IP-ID is carrying a host identifier.
>

Ok.

>>>> 6. Section 3.1 should be removed.  This is simply an analysis of
>>>> the mechanisms, so there is no new work which needs requirements
>>>> defined at this point.
>>>
>>> Med: Section 3.1 was added as a result of a review from privacy
>>> people. I do think it is useful to maintain it. Perhaps, move the
>>> text to the security considerations?
>>>
>>
>> If anything, these are privacy considerations that may be impacted by
>> these types of functions.  They can't be requirements at this point.
>> Keeping the text is a good idea in that light, but don't call them
>> Requirements.  Moving them to the Security Considerations
>> section would
>> work.
>
> Med: Section 3.1 is now entitled "Privacy-related Considerations". The text is cleared to not use "requirement" term.
>

Ok.

>>
>>>>
>>>> 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.
>>>
>>> Med: We thought having a reference to
>>> draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The
>>> impact of Middleboxes is already discussed in that document (see
>>> section 5.3).
>>>
>>
>> So maybe the way to clarify this is to re-word the text in 4.1.2.  How
>> about:
>>
>> OLD:
>> This usage is not compliant with what is recommended in
>>     [I-D.ietf-intarea-ipv4-id-update].
>>
>> NEW:
>> This usage is not consistent with the fragment reassembly use of the
>> Identification field [RFC791] or the updated handling rules for the
>> Identification field [I-D.ietf-intarea-ipv4-id-update].
>
> Med: Works for me. I updated the text. Thanks.
>

Ok.

>>>> 9. In Section 4.3.2...
>>>>
>>>> * I would like to see some description of what risk(s) may arise
>>>> with a TCP option, even though they are apparently low
>>>> probability.
>>>
>>> Med: The main risk we had in mind is session failure due to handling
>>> an unknown TCP option. Are you suggesting this text should be
>>> expanded?
>>>
>>> The risk related to handling a new TCP Option is low as measured in
>>> [Options].
>>>
>>
>> It would be good to mention at least one risk, like session
>> failure, in
>> the text to give the readers some clue as to the type of risks being
>> considered.
>
> Med: The text reads now:
>
> "The risk to experience session failures due to handling a new TCP Option is low as measured...".

Ok.

>>>> 12. Section 4.7.2 should clearly state that HIP is an ideal
>>>> solution for this identification problem, even though the document
>>>> states there is a high cost for deployment. I would also like to
>>>> see some description of why HIP does not work if "the address
>>>> sharing function is required to act as a UDP/TCP-HIP relay".
>>>
>>> Med: The current text says:
>>>
>>> "If the address sharing function is required to act as a UDP/TCP-HIP
>>> relay, this is not a viable option."
>>>
>>> This require ALL servers in the Internet are HIP-enabled. It is
>>> obvious this is not a viable option for a deployable solution.
>>>
>>
>> That is understood.  It is not clear why the "UDP/TCP-HIP
>> relay" aspect
>> is mentioned.  Is there something special about that deployment model
>> that has additional issues (other than needing all servers to
>> understand
>> HIP)?
>
> Med: That model is mentioned because it does not require the host to be HIP-enabled. I updated the text to make it more explicit:
>
> "An alternative deployment model, which does not require the client to be HIP-enabled, is the address sharing function behave as a UDP/TCP-HIP relay. This model is also not viable as it assumes all servers are ported to be HIP-enabled."
>

Ok.

>>>> * I would also like to see some text describing why the approach is
>>>> not compatible with cascading NATs.
>>>
>>> Med: The main reason is that each NAT in the path will generate an
>>> ICMP message. These messages will be translated by the downstream
>>> NATs. The remote server will receive multiple ICMP messages and will
>>> need to decide which host identifier to use.
>>>
>>
>> The above text, or something similar, should be added to that bullet.
>
> Med: Done.
>

Ok.

>>>>
>>>> * 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?
>>>
>>> Med: the IP-ID tweaking is implemented in the address sharing
>>> function not the host/OS. In theory, if the address sharing functions
>>> follows the rule for IP-ID field, failure is unlikely.
>>>
>>
>> Even in the case where packets are fragmented after the middlebox sets
>> the IP-ID?
>
> Med: if the middlbox follows the rules in rfc6864 and the same ID is not re-assigned to another host sharing the same ip address during a given time interval, why downstream fragmentation will be an issue?

That is the piece that is missing.  The text in Section 4.1 (or its 
child sections) does not mention the dependency on RFC 6864.

>
>   It seems that the success ratio ignores those types of
>> errors.  Are those errors counted in the "Possible Perf Impact" metric?
>
> Med: No.
>
>>
>>>>
>>>> * Given the goal of this document to describe these identification
>>>> mechanisms, I don't see the need for the last bulleted list.
>>>
>>> Med: The intent of that text is to provide a kind of conclusion. No
>>> problem to remove it if you think so.
>>
>> I would prefer that type of discussion be done as prose, rather than a
>> list.  I will not object if the authors want to leave it as a list.
>
> Med: I removed the list to avoid mis-interpreting that text is promoting a particular solution.
>

Ok.

>>
>> I do have one other issue...
>>
>> The discussion in 4.4.1 inter-mixes two different HTTP
>> headers.  The XFF
>> header is now obsolete (RFC 6648).  It has been replaced by the
>> Forwarded: header defined in the referenced draft.  Figure 1 uses the
>> correct header name, but the supporting text references XFF in several
>> places.  All uses of XFF should be replaced by Forwarded: to be
>> consistent with the current specs.
>
> Med: I cleared the text when it makes sense.
>

Ok.

Regards,
Brian