Document: draft-ietf-ipv6-ndproxy-03
Reviewer: Harald Alvestrand
Date: November 4, 2005
Summary: Happier. Still not happy
Longer summary: I'd like to delete the "at no cost" remark, and call out
more clearly that a bit is being allocated without an allocation procedure.
Explicit suggestions for both cases below.
With those two fixes, I think it's reasonable to ship - although I'd like
to have evaluation criteria on the experiment, I don't think that's a
showstopper.
This review concentrates on whether or not points from the -03 review have
been addressed. That review is therefore copied inline here.
My apologies for not responding to Dave Thaler's message of Oct 20. I lost
track.
Summary: Not ready for publication. Needs better scope description.
I've added both large and small comments in the notes below, in the order
their points occur in the document.
Summary (longer):
I think the technique is worth documenting. But I think that:
a) this specification is not clear enough for a solid implementation
b) there are some puzzling pieces missing (DHCPv6, for instance)
c) the security considerations are inadequate
d) as an experiment, it does not specify its success criteria
This document is an Experimental document - which is a Good Thing in
itself, and should not be held to the requirements for a standards-track
document - but when viewed with the eyes of draft-iesg-info-exp-01, it
lacks something.
From that document:
4. If the IETF may publish something based on this on the standards
track once we know how well this one works, it's Experimental.
This is the typical case of not being able to decide which
protocol is "better" before we have experience of dealing with
them from a stable specification. Case in point: "PGM Reliable
Transport Protocol Specification" (RFC 3208)
5. If the document contains implicit or explicit success/failure
criteria, and it's clear that the outcome can be used as the
basis for a recommendation to the IETF community, it's
Experimental. Case in point: RFC 1797 "Class A Subnet
Experiment" which led to RFC 1879 "Class A Subnet Experiment
Results and Recommendations"
This document has no criteria for judging whether or not the experiment
succeeded. I'd like some.
This comment has not been addressed in the revision.
The author replied (paraphrase) "if people use it and it works, the
experiment is a success".
As I said above, it's not a showstopper for me, but a sentence like:
This experimental document is being published to allow people to test the
technique described.
If you try it, please report back to the IPv6 WG or the authors, so that
your
experience can be used for a later decision about whether or not the
technique
should be standardized.
would make me feel that I know better what the situation is.
Of course, some people will claim that this is the meaning of "Category:
Experimental", but it often doesn't seem that way....
I have a number of other stylistic and scoping comments:
- Section 1 describes the scenarios where this document is applicable:
Single IPv4 address and single /64 prefix delegation. It clearly
identifies that NAT is used in the IPv4 scenario, and identifies cost as
a driver for the /64 scenario: "Secondly, the extent to which Prefix
Delegation is supported, and supported without additional charge, is up
to the service provider." If this solution has costs, I think some people
would rather pay their service provider than use it; I think the the "no
charge" part of the sentence could be dropped. The part about "zero
configuration" in the same paragraph is also possibly untrue; later we
see a requirement to configure the proxy to know which interface is
"upstream".
This comment has not been addressed in the revision.
My suggestion for a change would be to change:
OLD:
Secondly, the extent to which Prefix Delegation is
supported, and supported without additional charge, is up to the
service provider.
NEW:
Secondly, the extent to which Prefix Delegation is
supported for any particular subscriber class is up to the
service provider.
It also does not specify the contexts in which this tool is
INappropriate; in particular, any scenario with multiple connections
between segments, or with multiple off-link routers, will (I think) cause
the solution to have "interesting" effects.
This comment has been addressed; new section 1.3.
- Section 4.1 does not list cover DHCPv6 as a proxied packet type. Why
not?
The response from the authors is that DHCPv6 does not contain link-layer
addresses that the proxy needs to change.
- Section 4.1.2 seems sloppy - it does not specify exactly WHICH
link-layer addresses should be changed for each packet type. This is
likely to be quite obvious to practitioners skilled in the art - some you
change, some you don't - but why not document it?
This comment has not been addressed. However, it is not a show-stopper - I
guess the authors think that the answer is too obvious to be worth writing
down, and they're probably right.
- Section 4.1.3.3 doesn't say why the proxy doesn't simply follow the
rules for proxying DHCP. DHCP proxies occur in many contexts; adding yet
another variant (mucking around with the B flag) needs justification.
This version has removed IPv4 support, so this comment is no longer
relevant.
- Section 4.1.4.3 steals one reserved bit out of router advertisements.
RFC 2461 doesn't specify IANA considerations for this field, and it seems
that 3 bits ("H" and "PRF") have been "stolen" before. But doing FCFS on
an 8-bit field seems excessive.... and doing so with no IANA
considerations seems Just Plain Wrong.
This is now section 4.1.3.3. The comment has not been addressed.
Author claims that this belongs in 2461bis - but 2461bis-05 does not
specify any IANA rules about the RA flags field (and continues to say that
recipients MUST ignore the reserved bits, making implementations of this
spec formally noncompliant). This is still broken, but it's not clear where
to unbreak it..... my suggestion (in order to avoid forward pointers to
some hypothetical 2461ter) would be to add into IANA considerations section:
This document defines a new bit in the RA flags (the P bit). There is
currently
no registration procedure for such bits, so IANA should not take any
action.
Still not happy.
- It is not clear to me what 4.1.4.3 + 6 (RA handling) achieves that
couldn't be achieved by just disabling all interfaces on which an RA
arrives except for the upstream one, and proxying upstream RAs out all
the remaining interfaces without changing the P bit. This would also
allow the technology to function in the case where one wants two of these
devices behind each other (private WLAN links behind a PPP upstream,
anyone?)
The author replied that the group was quite worried about loop prevention,
so it chose this solution. Experience will tell. OK.
- Security considerations fail to lay out a clear picture of who the
trusting parties are, what the trust relationships are, and what the
threat models are. While much can be pushed off onto [PSREQ], some
minimum linkage should be established - for instance naming the trust
models from section 3 of that document that are relevant to this scenario.
The new security section is a bit better, and stands much more on its own.
OK.
- Security considerations fail to paint a clear picture (to me, at least)
of how end nodes that expect SEND to work will behave in this scenario.
Saying that it "requires further work" may be codeword for "SEND will not
work at present". They also seem to fail to address what securing DHCP
will do to the proxy's behaviour.
The new version of the security section is reasonable on this topic. OK.
- The RA behaviour specified seems to open up a very simple DoS attack:
Simply send an RA packet on any segment, and the proxy will stop proxying
to that segment. That should stop packets from reaching it (if the words
"Proxy functionality is disabled" in section 6 mean "the proxy will no
longer forward packets" - I'm not quite sure whether or not it means that
- it could also mean "the proxy will stop applying fixups", but that
doesn't seem right.) That seems worthy of special mention in security
considerations.
New text is reasonable. OK.
These comments may or may not be reasonable to address. It's possible
that this technique is already out in the wild, and we need to document
it ASAP (especially the newly-assigned P bit from the RA header). But I
don't have the information to judge the urgency of that.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
