Neighbor Discovery Proxies (ND Proxy)
draft-ietf-ipv6-ndproxy-04

[Ballot discuss]
Holding a discuss to make sure  that the issues that Thomas Narten sent to int-area are addressed:

To: int-area@ietf.org
From: Thomas Narten
Cc:
Subject: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt

I'm sending this to the int-area because the concerns I have are
broader than the just the ipv6 WG. This document is really about
bridging/proxy arp in general, and it does not restrict itself to
IPv6; it also covers IPv4.

I've read this document a couple of times (it is on the IESG's plate
to review), but have general concerns. I wonder if others in the
community share my concern.

The bottom line is that I think the IPv6 portion of document/protocol
is both under-specified and too broad in scope and I worry that there
are a lot of potential gotchas lurking. I also worry that it will
break some of our standards track protocols. And if it gets widely
implemented, we'll have to deal with the resultant mess. We have
plenty of experience in IPv4 with proxy arp, and some of it has been
unpleasant.

I have the following meta concerns:

1) I do not believe the material on IPv4 ARP proxy should be
included. It is not in-scope for the IPv6 WG to be developing it, and
any document on proxy ARP in IPv4 really requires review from the
broader community. AFAIK, that review has not taken place.

Recommendation: remove the IPv4 material and place in a separate
document

2) This document breaks SEND (but does not say this clearly). I have
doubts that we should be publishing documents that break our standards
track protocols (especially ones that we believe are important). Or at
the very least, if it is published, very strong wording is needed to
point out that it is incompatable with SEND, e.g., an IESG note.

3) this document may have implications for DHC. In particular,
document says:

One limitation of this rule is that if the authentication
protocol for DHCPv4 described in [DHCPAUTH] is used, only
clients that set the BROADCAST flag themselves will be able to
use DHCPv4 through the proxy.

If this document breaks some forms of DHC, that needs to be noted up
front and more visibly. I also think more discussion would be
appropriat here, to be sure we fully understand the issue here.
Again, I'm also not sure we should be promoting documents that cause
problems for existing standards track protocols.

4) The history of this document is troubling, and I believe it does
not have strong support from the WG. Rather, I'd characterize this as
an effort that has gotten this far mostly because the vast majority of
the WG has tuned out and no longer is following the work.

The history of this effort (though I may be biased) is that the IPv6
WG desired a simple proxy mechanism for the following case. Suppose
one has an access router connecting to an upstream ISP, and that link
is assigned a prefix (say X). It would be nice if the access router
could readvertise that prefix (say for a home network), acting as a
simple bridge. That way the end site wouldn't need a separate prefix
(say if the ISP as stingy and didn't want to give it out). I had
always assumed this configuration was a simple star topology with the
access router at the center.  Indeed, the current IPv6 charter says:

> - Develop Proxy Neighbor Discovery solution for prefix delegation
>  and publish. This enables a simple site border router to
>  re-advertise downstream a prefix it hears on its upstream link.

The WG had such an item in its charter for a long time (years), but
from what I can tell, there was limited interest in terms of actually
doing the work, so it languished. What "the WG" finally produced was
the above document. But it's scope is quite a lot broader than what
the charter called for. And, I think its fair to say that the work
reflects a small number of contributers (with good intentions) but
apathy and almost no help from the rest of the WG (e.g., the last WG
LC received no comments). So, this document is going through the
process by default, rather than being a strongly reviewed piece of
work.

Margaret (as AD) raised a similar point about the scope of this work
in the WG a few months back.  For details, review the discussion
during the WG last call in May: (sorry, I can't find a a good URL to
point to -- sigh). There was hardly strong support for the document,
and in fact, the reviews were negative and the document was taken off
standards track and put on experimental in response to that thread.

In summary, I believe  there are good reasons why the document in its
current form should not be published with an IETF blessing.

Some possible options:

1) Drop the work completely. This may not be as silly as it seems. A
  basic premise of this work is that its somehow not possible (or too
  hard) to get a proper prefix delegated from an ISP. However, there
  is little evidence that this will be a real issue in IPv6. Current
  RIR address allocation polcies and existing ISP practices is to
  give out chunks of address space (rather than /64s), or a single
  address.

2) Move all the IPv4 material to a separate document (this should be
  done in any case if work on this continues). Also, the IPv4
  material would need serious  review from the IPv4 community.
 
3) Pull out all the more general bridging stuff for the IPv6 case and
  just solve the narrow problem described earlier, namely a single
  router acting as a star/hub for proxying.

4) Add an IESG note with a warning that this has potential issues and
  the IETF doesn't recommend widespread adoption/use. (Indeed, the
  current applicability statement is really weak and gives
  insufficient guidance in terms of where this technology can safely
  be used)

And what I'd _really_ like to see, more than anything else, is strong
support from the community both for scope of this document and the
details of what are contained in the document. In the absence of that,
if the document is published, I'd like to see a strong note adequately
characterizing the issues above.
 
Thomas

[Ballot comment]
Here is an external review.  Personally I agree with the comments made
here.  The concern about the security considerations section is a
DISCUSS issue.

Some comments:

> o    Support Neighbor Discovery, Router Discovery, or DHCPv4
>      packets using IPsec.  We also note that the current methods
>      for securing these protocols do not use IPsec so this is
>      considered acceptable.

I would probably not mention this at all, because its confusing.
IPsec in this purpose doesn't really work anyway, so why bother
even mentioning it...

However, the draft should have a note saying that it has
chosen to not support nodes that do SEND.

> 9.  Security Considerations

This section seems a bit unclear imho and would benefit from a
rewrite and direct representation of the issues and the properties
and limitations of the specification at hand. Here's
a suggested rewrite:

Unsecured Neighbor Discovery and ARP have a number of security issues
which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines
security mechanisms that can protect Neighbor Discovery. No such
mechanism has been defined for ARP.

Proxies are susceptible to the same kind of security issues that
plague hosts using unsecured Neighbor Discovery. These issues include
hijacking traffic and denial-of-service within the subnet. Malicious nodes
within the subnet can take advantage of this property, and hijack
traffic. In addition, a Neighbor Discovery proxy is essentially a
legitimate man-in-the-middle, which implies that there is a need
to distinguish proxies from unwanted man-in-the-middle attackers.

This document does not introduce any new mechanisms for the protection
of proxy neighbor discovery. That is, it does not provide a mechanism
from authorizing certain devices to act as proxies, and it does not
provide extensions to SEND to make it possible to use both SEND and
proxies at the same time.

Note also that the use of proxy Neighbor Discovery may render it
impossible to use SEND both on the leaf subnet and on the external
subnet. This because the modifications performed by the proxy will
invalidate the RSA Signature Option in a secured Neighbor Discovery
message, and cause SEND-capable nodes to either discard the messages
or treat them as unsecured. The latter is the desired operation when
SEND is used together with this specification, and ensures that SEND
nodes within this environment can selectively downgrade themselves to
unsecure Neighbor Discovery when proxies are present.

In the following we outline some potential paths to follow
when defining a secure proxy mechanism.

It is reasonable for nodes on the leaf subnet to have a secure
relationship with the proxy, and accept ND packets from either the
owner of a specific address (normal SEND), or which it can verify
are from a trusted proxy (see below).

For nodes on the external subnet, there is a tradeoff between
security (where all nodes have a secure relationship with the
proxy) and privacy (where no nodes are aware that the proxy is a
proxy). In the case of a point-to-point external link (Scenario
2) however, SEND may not be a requirement on that link.

Verifying that ND packets come from a trusted proxy requires an
extension to the SEND protocol and is left for future work, but is
similar to the problem of securing Router Advertisements which is
supported today.

Alternative designs might involve schemes where the right
for representing a particular host is delegated to the proxy,
or where multiple nodes can make statements on behalf of
one address [RINGSIG]

(And add a new reference to RFC 3971 [SEND] and
draft-kempf-mobopts-ringsig-ndproxy [RINGSIG].)

--Jari

[Ballot discuss]
The security considerations section needs to discuss the interactions
with SEND.  I also wonder whether the fact that this protocol doesn't
work with SEND means that it needs an applicability statement or IESG
note.  It seems fine to use if you are the end user.  However I think
it might be problematic if a service provider started using nd proxy.


I have provided a review from Jari Arkko in the comments field; his
approach provides one solution to discussing the SEND interactions.  I
like that approach but the authors need not solve things that way.

[Ballot discuss]
Sam is going to pick up a security related issue (as raised by an
AAA-doctor review (Jari)). Untill I see Sam's DISCUSS, I am keeping
one to make sure it does not get lost. Here is comment from Jari:

>  o draft-ietf-ipv6-ndproxy-03.txt
>    Neighbor Discovery Proxies (ND Proxy) (Experimental) - 3 of 5
>    Token: Margaret Wasserman
> 
>
Some comments:

> o    Support Neighbor Discovery, Router Discovery, or DHCPv4
>      packets using IPsec.  We also note that the current methods
>      for securing these protocols do not use IPsec so this is
>      considered acceptable.

I would probably not mention this at all, because its confusing.
IPsec in this purpose doesn't really work anyway, so why bother
even mentioning it...

However, the draft should have a note saying that it has
chosen to not support nodes that do SEND.

> 9.  Security Considerations

This section seems a bit unclear imho and would benefit from a
rewrite and direct representation of the issues and the properties
and limitations of the specification at hand. Here's
a suggested rewrite:

Unsecured Neighbor Discovery and ARP have a number of security issues
which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines
security mechanisms that can protect Neighbor Discovery. No such
mechanism has been defined for ARP.

Proxies are susceptible to the same kind of security issues that
plague hosts using unsecured Neighbor Discovery. These issues include
hijacking traffic and denial-of-service within the subnet. Malicious nodes
within the subnet can take advantage of this property, and hijack
traffic. In addition, a Neighbor Discovery proxy is essentially a
legitimate man-in-the-middle, which implies that there is a need
to distinguish proxies from unwanted man-in-the-middle attackers.

This document does not introduce any new mechanisms for the protection
of proxy neighbor discovery. That is, it does not provide a mechanism
from authorizing certain devices to act as proxies, and it does not
provide extensions to SEND to make it possible to use both SEND and
proxies at the same time.

Note also that the use of proxy Neighbor Discovery may render it
impossible to use SEND both on the leaf subnet and on the external
subnet. This because the modifications performed by the proxy will
invalidate the RSA Signature Option in a secured Neighbor Discovery
message, and cause SEND-capable nodes to either discard the messages
or treat them as unsecured. The latter is the desired operation when
SEND is used together with this specification, and ensures that SEND
nodes within this environment can selectively downgrade themselves to
unsecure Neighbor Discovery when proxies are present.

In the following we outline some potential paths to follow
when defining a secure proxy mechanism.

It is reasonable for nodes on the leaf subnet to have a secure
relationship with the proxy, and accept ND packets from either the
owner of a specific address (normal SEND), or which it can verify
are from a trusted proxy (see below).

For nodes on the external subnet, there is a tradeoff between
security (where all nodes have a secure relationship with the
proxy) and privacy (where no nodes are aware that the proxy is a
proxy). In the case of a point-to-point external link (Scenario
2) however, SEND may not be a requirement on that link.

Verifying that ND packets come from a trusted proxy requires an
extension to the SEND protocol and is left for future work, but is
similar to the problem of securing Router Advertisements which is
supported today.

Alternative designs might involve schemes where the right
for representing a particular host is delegated to the proxy,
or where multiple nodes can make statements on behalf of
one address [RINGSIG]

(And add a new reference to RFC 3971 [SEND] and
draft-kempf-mobopts-ringsig-ndproxy [RINGSIG].)

[Ballot comment]
Smaller comment from Gen-ART review by Harald Alvestrand:


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

[Ballot discuss]
Gen-ART review comments from Harald Alvestrand, awaiting authors' comments:

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.




This document has no criteria for judging whether or not the experiment succeeded. I'd like some.



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.

[Ballot discuss]
Should the IPv4 part of this draft be reviewed on the int-area mailing list?

>1.2.  SCENARIO 2: PPP upstream
>
>The following figure illustrates another likely example:
>        |        +-------+          +--------+
>  local |Ethernet |      | PPP link  |        |
>        +---------+  A  +-----------+ Router +--> rest of network
>  hosts |        |      |          |        |
>        |        +-------+          +--------+
>
>In this scenario, the router believes that the other end of the
>PPP link (node A) has a single IPv4 address, as negotiated by PPP.
>For IPv6, it has assigned a /64 to the link and advertises it in
>an IPv6 Router Advertisement.
>
>Classic bridging does not support non-802 media, and hence IPv4
>connectivity is solved by making the proxy (node A in the above
>diagram) be a NAT.  This document does not specify any other IPv4
>solution for this scenario.  However, this document does specify a
>solution for IPv6 which does not involve NAT or require any change
>to the router.
> 
>

PPP Supports bridging, as defined in RFC 1638, a simple way of solving this problem in the case of PPP.