On 2/13/13 11:12 AM, [email protected] 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
