[Gen-art] Review of draft-ietf-ipv6-ndproxy-03

Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are included.

Review criteria for WG submissions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
----------------------------------------------------------------------
Document: draft-ietf-ipv6-ndproxy-03
Reviewer: Harald Alvestrand

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.

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

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.

- Section 4.1 does not list cover DHCPv6 as a proxied packet type. Why not?

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

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

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

- 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?)

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

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

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.

                 Harald