Document: draft-ietf-ipv6-ndproxy-03 Reviewer: Harald Tveit Alvestrand [harald@alvestrand.no] Review Date: Wednesday 8/31/2005 8:56 AM CST Telechat Date: 01 Sept 2005 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.