Draft:  draft-ietf-ipv6-ndproxy-04
Reviewer: Harald Tveit Alvestrand [harald@alvestrand.no]
Review Date:Friday 11/4/2005 8:00 AM CST
Telechat date: TBD

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.
>