Last Updated: March 7, 2005
Here is a pointer to the latest specification:
draft-ietf-ipv6-ndproxy-01.txt
Previous versions:
draft-ietf-ipv6-ndproxy-00.txt
draft-thaler-ipv6-ndproxy-03.txt
draft-thaler-ipv6-ndproxy-02.txt
draft-thaler-ipv6-ndproxy-01.txt
draft-thaler-ipv6-ndproxy-00.txt
| Issue Number | Status | Description | Submitter |
| Issue 16 | Text Proposed | Loop prevention, revisited | Erik Nordmark |
| Issue 17 | Done in -01 | SEND | Erik Nordmark |
| Issue 18 | Done in -01 | Dynamic removal of proxy | Erik Nordmark |
| Issue 19 | Accepted | Make Experimental not Informational | Brian Carpenter |
| Issue 20 | Done in -01 | DHCPv4 | Ralph Droms |
| Issue 21 | Done in -01 | Editorial nits in ipv6-00 | Ralph Droms |
| Issue 22 | Done in -01 | Unclear text about ICMP errors | Dave Thaler |
When submitting an issue, please fill in the following template:
Description of issue: (short single line description of issue)
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Lengthy description of problem
Requested change:
Proposal
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
Deferred - The decision reached depends on the outcome of another issue.
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
Issues can also be given the Reject status, or the version of the document when the accepted fix has appeared.
Issue 16:
Loop prevention, revisited
Submitter: Erik Nordmark
Submitter email address: erik.nordmark@sun.com
Date first submitted: January 18, 2005
Reference:
Document: ipv6-00
Comment type: Technical
Priority: 1
Section: 6
Rationale/Explanation of issue:
(See also Issue 2: make STP optional for previous discussion on this topic)
The protocol, if deployed, can cause harm to the Internet. The primary source of
harm is the optional loop prevention. This will cause networks to melt when
proxies are configured in a loop, since proxies are constrained to not decrement
the IP ttl. Note that these loops would be particularely severe for IP
multicast, since such packets are duplicated and sent out each proxy interface.
[Brian Haberman]: I think that saying it harms the Internet is a little broad. The use cases for proxynd is more at the edge. Loops will be localized and shouldn't bring the whole Internet down.
[Erik Nordmark]: I suspect the users that will have their "measly" edge networks
melt down would disagree with this; the harm doesn't have to make everything
melt at once for it to be a harmful thing AFAIK.
[Brian Haberman]: First, lets keep in mind that this is an Informational document. I don't see it as the eventual solution for the problem space. Secondly, I see proxy ND being used in very small, cost-constrained networks. Something where a router is over-kill.
[Erik Nordmark]: But I still think the document should say "MUST prevent loops; SHOULD run IEEE 802.1D to prevent loops" and then talk about cases when the protocol is not needed. The one example we have is the case of PPP (e.g. to a GGSN) where the probability of a loop would be very small, so in that particular case there is no need for 802.1D (and there might be other examples, but the 802.11 scenario in the document isn't one of them).
[Dave Thaler]: I agree.
[Ralph Droms]: As another example of deployment where a loop might be possible but unexpected, there is a specification under development for cable-broadband deployments in which the in-home coax cable may be used as a link, using different frequencies than the frequencies used between the cable modem and the CMTS. The in-home coax link is logically separate from the CM-CMTS link. It is possible that a device that can communicate on both links would employ NDproxy between the two links. If there is more than one such device, a loop is possible.
[Dave Thaler]:
OLD:
Loop prevention can be done done by
having the proxy implement the
Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
proxy interfaces. Loop prevention is OPTIONAL, and is useful only
if the proxy can be deployed in an environment where physical loops
are possible. For example, in a cell phone which proxies between a
PPP dialup link and a local Ethernet interface, it is typically safe
to assume that physical loops are not possible and hence there is
no need to support the Spanning Tree Protocol (STP).
If loop prevention is implemented, it is done as follows.
NEW:
An implementation MUST have some
means of preventing loops.
Loop prevention SHOULD be done by having the proxy implement the
Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
proxy interfaces, as described below. This mechanism is required
only if the proxy can be deployed in an environment where physical loops
are possible. For example, in a cell phone which proxies between a
PPP dialup link and a local Ethernet interface, it is typically safe
to assume that physical loops are not possible and hence there is
no need to support the Spanning Tree Protocol (STP).
Loop prevention using STP is done as follows.
[Pekka Savola]: Is this strong enough
for interoperability across ND-proxies from different vendors? Loop prevention
won't do much good unless every vendor implements an interoperable mechanism..
The text is also a bit contradictory: "An implementation MUST have some means.."
and "The mechanism is required only if...". Granted, there are some cases where
it may be physically impossible (or extremely difficult) to use the
implementation to form a loop, but in the general case, the implementor really
cannot know how the devices will end up being used. Maybe the first sentence
needs to be reworded slightly to include an escape clause there as well.
[Dave Thaler]: Point taken. How
about:
A proxy MUST ensure that loops are prevented, either by running the Spanning
Tree Algorithm and Protocol defined in [BRIDGE] on all proxy interfaces as
described below, or by being deployable only in an environment where physical
loops cannot occur. For example, in a cell phone which proxies between a PPP
dialup link and a local Ethernet interface, it is typically safe to assume that
physical loops are not possible and hence there is no need to support the
Spanning Tree Protocol (STP).
[Pekka Savola]: This text looks fine by me. Thanks!
[Bill Sommerfeld]: all well and good
until someone strings together four such phones and two ethernet hubs just to
prove a point.
[Margaret Wasserman]: This suggestion
appears to be operational advice (about what features be enabled in given
situations, not what should be supported by implementations), and
implementations can't really know that that they will always be deployed in
situations where loops are impossible... So, you would do better to say
something like "all implementations MUST support loop prevention. A
configuration option to disable loop prevention MAY be supported, but all
implementations MUST have loop prevention enabled by default".
You could certainly avoid loops in ND Proxy by using STP, although I think you
would have to say a lot more about how it would be applied... A reference to the
rbridges work might be premature.
Ultimately, though, I am not sure why we would want to add this complexity to ND
Proxy as I don't view it as a sound, scalable mechanism for link aggregation. It
is quite similar to the Proxy ARP mechanisms supported in some IPv4
implementations, and it seems likely to have the same problems.
My understanding of the current ND Proxy work (and why I grudgingly agreed to
leave it on the most recent IPv6 charter despite the fact that we had not
managed to reach consensus on this proposal for several years) was that we were
planning to trim down the original ND Proxy proposal to a one-hop prefix
delegation mechanism (perhaps with a flag to indicate whether the prefix has
already been delegated, in which case it mustn't be delegated again) to provide
a non-DHCP alternative for one-hop prefix delegation. I've never been quite sure
why a non-DHCP mechanism is needed, but I'm also not religiously against the
idea of standardizing an alternative.
From my perspective, though, the ND Proxy spec doesn't seem to have been trimmed
down into a simple prefix delegation mechanism at all. And, now we
are talking about complicating it even further with a complex loop prevention
scheme (or two).
[Dave Thaler]: will change "A proxy MUST" to "An implementation MUST" if that
would be clearer that this is indeed an implementor's decision.
> and implementations can't really
know that that they will always be
> deployed in situations where loops are impossible...
Several folks have argued that this is not true, which is why it's worded the
way it is.
> So, you would do better to say something like "all implementations
> MUST support loop prevention. A configuration option to disable loop
> prevention MAY be supported, but all implementations MUST have loop
> prevention enabled by default".
That is what the draft used to say prior to the Vienna IETF, but was changed due
to feedback from the WG.
This was Issue #2
http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%202
(which is what we're revisiting now in #16).
> You could certainly avoid loops in ND Proxy by using STP, although I
> think you would have to say a lot more about how it would be
> applied...
I don't understand your point. It's applied just like in a layer 2 bridge.
The behavior is fully specified in the reference, and the application is exactly
the same as on a layer 2.5 (arp/nd proxy) bridge, since the forwarding part is
orthogonal.
> A reference to the rbridges work might be premature.
>
> Ultimately, though, I am not sure why we would want to add this
> complexity to ND Proxy as I don't view it as a sound, scalable
> mechanism for link aggregation. It is quite similar to the Proxy ARP
> mechanisms supported in some IPv4 implementations, and it seems likely
> to have the same problems.
>
> My understanding of the current ND Proxy work (and why I grudgingly
> agreed to leave it on the most recent IPv6 charter despite the fact
> that we had not managed to reach consensus on this proposal for
> several years) was that we were planning to trim down the original ND
> Proxy proposal to a one-hop prefix delegation mechanism (perhaps with
> a flag to indicate whether the prefix has already been delegated, in
> which case it mustn't be delegated again) to provide a non-DHCP
> alternative for one-hop prefix delegation. I've never been quite sure
> why a non-DHCP mechanism is needed, but I'm also not religiously
> against the idea of standardizing an alternative.
For prefix delegation I agree the DHCP mechanism is sufficient, and it was never
my understanding that the ND Proxy draft would ever try to become prefix
delegation (see Appendix A for some discussion on a related point which WAS
suggested by a number of folks at one point).
> From my perspective, though, the ND Proxy spec doesn't seem to have
> been trimmed down into a simple prefix delegation mechanism at all.
> And, now we are talking about complicating it even further with a
> complex loop prevention scheme (or two).
Again, this draft is not complicating prefix delegation. This is about scenarios
were people use IPv4 ARP Proxies today, and prefix delegation is inappropriate
in some of these scenarios, as discussed in the doc right above the Scenario 2
picture.
[Erik Nordmark]: It might not be that
hard to come up with something which is is limited to a single hop.
Here is a straw-man:
- add something to the RA which indicates that the sender is a proxy.
Could be just a single 'P' bit I think.
- a proxy can take an RA which arrives without the P bit, and send it out as a
RA with the P-bit.
- a proxy must not redistribute an RA with the P-bit set; if it receives any (or
only?) RAs with the P-bit set, that interface can not be an upstream interface
from a proxy perspective.
I haven't worked through the cases to see if this will avoid all loops; perhaps
there can be (at least multicast) packet duplication if two such proxies are
connected in parallel.
ND-proxies adding and checking for "P-bit" in RAs does not require changes to
the router because routers send the RAs without P-bit? It only requires
modifications in ND-proxies but that's OK.
With this, the ISP could prevent the user from running ND proxy, so
implementations will likely have a knob which would ignore this bit, but still..
What I sketched would be completely transparent to the router.
It is merely a mechanism to prevent a large class of loops by ensuring that a
proxy can not be a child of another proxy.
Thus this can NOT happen:
Router
|
------------------------
|
|
Proxy1
Proxy2
|
|
---- Proxy3 --------
Proxy3 will not enable its proxy capability because it receives RAs with the P
bit set.
While this CAN happen:
Router
|
------------------------
|
|
Proxy1
Proxy2
|
|
-------------------
|
Host
But perhaps this can be prevented as well, by having the proxy disable itself it
it receives a RA (P bit or not?) on its downstream interface (Could still have a
temporary loop, unless we require that the proxy send its P-bit RA on the
downstream interface for a while before enabling the proxying/flooding.
[Erik Nordmark]:
> With this, the ISP could prevent the user from running ND proxy, so
> implementations will likely have a knob which would ignore this bit,
> but still..
Since such an ISP would violate the "assign a /48 by default" recommendation, it
might as well go all the way and only assign a /128 to the subscriber. So
why would the ISP use the more cumbersome approach of 1) assiging a /64, and 2)
lying by setting the P-bit in its RA?
We can't solve the tussle that some ISPs might want to charge per host, while
users might want to pay per "wire" and have lots of hosts. Given that the /128
is an option for the ISP, we can avoid entangling the protocol standards with
this tussle, which is the best we can do IMHO.
[Pekka Savola]: Because if such an ISP used RAs for address assignment, it couldn't restrict to /128. (Well, maybe such ISP's would require stateful DHCPv6 assignment..)
[Bob Hinden]: I like Erik's
suggestion as a simple default mechanism to deal with the looping case. It's not
perfect, but would provide a default mechanism that would prevent people from
hurting themselves. It does support the scenario I am interested in (/64
advertised from upstream, router/proxy, single subnet downstream with a few
devices). It's easy to turn off for people who know more about their topology or
perhaps the case Pekka describes.
I think people are going to build things like this independent of what the IETF
does and publishing this (with the changes being discussed) seems like a
reasonable thing thing for the community. It will help people avoid many of the
mistakes that have been discussed.
[Erik Nordmark]: FWIW it also support a single proxy having multiple downstream interfaces. I don't know if that is an interesting case when multiple L2 technologies are being used.
[Bob Hinden]: Good point. I can think of a device with more than two interfaces (for example, GPRS, WLAN, BT, and USB).
[Dave Thaler comment]: Included Erik's suggestion in draft-ietf-01 by combining with previous proposed text as follows:
In Section 4.1.4.3 on ICMPv6 Router Advertisements:
A new "Proxy" bit is defined in the existing Router Advertisement
flags field as follows:
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|Rsv|
+-+-+-+-+-+-+-+-+
where "P" indicates the location of the Proxy bit, and "Rsv
indicates the remaining reserved bits.
The proxy determines an "upstream" proxy interface, typically
through a physical choice dictated by the scenario (see Scenarios
1 and 2 above), or through manual configuration.
When an RA with the P bit clear arrives on the upstream interface,
the P bit is set when the RA is proxied out all other
("downstream") proxy interfaces (see secion 6).
If an RA with the P bit set has arrived on a given interface
(including the upstream interface) within the last 60 minutes,
that interface MUST NOT be used as a proxy interface; i.e., proxy
functionality is disabled on that interface.
Furthermore, if any RA (regardless of the value of the P bit) has
arrived on a "downstream" proxy interface within the last 60
minutes, that interface MUST NOT be used as a proxy interface.
In Section 6 on Loop prevention:
An implementation MUST ensure that loops are prevented, via
either:
a) by using the P bit in RA's as described below, or
b) by running the Spanning Tree Algorithm and Protocol defined
in [BRIDGE] on all proxy interfaces as described below, or
c) by being physically deployable only in an environment where
physical loops cannot occur. For example, in a cell phone
which proxies between a PPP dialup link and a local Ethernet
interface, it is typically safe to assume that physical loops
are not possible and hence there is no need to support the
Spanning Tree Protocol (STP).
Loop prevention using STP would typically be done by devices that
already implement this protocol as a result of supporting normal
briding functionality, and is done here as follows. IEEE 802
[... existing text skipped ...]
Loop avoidance using the P bit in RAs is done as follows. The
proxy determines an "upstream" proxy interface, typically through
a physical choice dictated by the scenario (see Scenarios 1 and 2
above), or through manual configuration. As described in Section
4.1.3.3, only the upstream interface is allowed to receive RAs,
and never from other proxies. Proxy functionality is disabled on
an interface otherwise. Finally, a proxy MUST wait until it has
sent two P bit RAs on a given "downstream" interface before it
enables forwarding on that interface.
[Bob Hinden]: Would it be better if c) was removed from Section 6 "Loop Prevention". Seems to me that this would resolve the issue. I think the "P bit" algorithm is so trivial to implement that I don't see any reason not to require it (assuming STP isn't being used) as the default.
[Dave Thaler]: Proposed text:
OLD:
b) by running the Spanning Tree Algorithm and Protocol defined
in [BRIDGE] on all proxy interfaces as described below, or
c) by being physically deployable only in an environment where
physical loops cannot occur. For example, in a cell phone
which proxies between a PPP dialup link and a local Ethernet
interface, it is typically safe to assume that physical loops
are not possible and hence there is no need to support the
Spanning Tree Protocol (STP).
NEW:
b) by running the Spanning Tree Algorithm and Protocol defined
in [BRIDGE] on all proxy interfaces as described below.
Proposed resolution: Accept
Issue 17:
SEND
Submitter: Erik Nordmark
Submitter email address: erik.nordmark@sun.com
Date first submitted: January 18, 2005
Reference:
Document: ipv6-00
Comment type: Editorial
Priority: 1
Section: 3
Rationale/Explanation of issue:
Another form of potential harm is creating obstacles for deployment of Secure Neighbor Discovery. The protocol does not work in conjunction with SeND, which is particularely odd since section 3 explicitly lists this as a requirement. (The line of reasons seems to be that it is a fault of SeND that proxynd doesn't work when SeND is used, which is a bit odd.)
Note that if there is sufficient
interest in the WG, it isn't hard to solve the two technical issues listed
above. (But the SeND interaction would require the proxies to be able to be
promiscious receivers, which might be problematic in the wireless upstream
scenario).
[Brian Haberman]: The security section points out, correctly, that 2461 supports proxying and that SeND doesn't support it. In addition, the scenarios supported by proxynd don't seem to be the same as those where SeND would be used.
(regarding promiscuous point): Agree that may be an issue. The question is whether SeND would be used in that scenario.
[Erik Nordmark]: Yes, but as I stated above, section 3 explicitly says that working with SeND is a requirement for proxynd. And then the protocol doesn't satisfy that. Given that the protocol doesn't satisfy what the document itself says are the requirements, the document (and perhaps the protocol as well) has a quality problem by being self-inconsistent.
(regarding promiscuous point): The counterexample is that there are ISPs that have their home users with 802.11 run public hotspots and get some compensation from the ISP. In this case, since it is a public access 802.11, SeND would be a good thing to use. And 802.11 is also a key scenario for proxynd.
[Brian Haberman]: I will admit to missing the stated requirement in to support SeND. The Security Considerations section spells out how SeND does not work with the existing proxy text in 2461. That, to me, made interoperating with SeND a non-requirement.
(regarding promiscuous point): This is the first I have ever heard of that particular scenario.
[Brian Carpenter]: Since the
deployment future of SEND is unknown, I don't think it's appropriate to block
this work because of SEND.
[Erik Nordmark]: Yes, but at least
the document should be internally inconsistent and not claim in section 3 that
working with SeND is a requirement, even though it doesn't work with SeND.
I think INFO documents produced by IETF WGs should have "truth in advertising",
so I don't buy the claim that the document can be silent on the dangers of
loops, and misleading (internally inconsistent) on whether it works in the
presence of SeND.
I suspect that the requirement should effect how a protocol is designed, as
opposed to creating requirements which are the things that the artifact is
capable of supporting. But as I said to Brian, in this case the issue is to make
the document clear what it supports and doesn't support, with some explicit
warnings that it can't be deployed in conjunction with SeND.
(regarding promiscuous point): And Jim Kempf said, it's being deployed that way.
[James Kempf]: specifically, speakeasy has a program listed on their web site where you get credits for routing your neighbor's traffic through your .11 ap. perhaps other isps too?
[Bill Sommerfeld]: http://www.speakeasy.net/netshare/
[Erik Nordmark]: sonic.net is another case.
[Alain Durand]: I have a problem with
publishing a document related to ND that specify something that will not work
with the IETF standardized approach to secure ND.
Either, the deployment of ndproxy will be marginal and there will be no
problems, but in that case, why even bother publishing it?
Or NDproxy picks up and it may become an obstacle to get SEND deployed.
The argument that NDproxy will only be used in a certain environments where SEND
is not needed is clearly bogus, The IETF is not about defining standards for
special cases but for the whole Internet.
Erik seems to hint that there are ways to get NDproxy to work with SEND, IMHO,
those should be explored and the current document should be put on hold until
this is resolved.
[Brian Carpenter]: I disagree as a
matter of principle. It is perfectly OK to have specs that are incompatible with
each other as long as they are never implemented on the same network. It isn't
OK to do that without documenting the incompatibility.
It's clear that this argument doesn't apply to end to end protocols, but
strictly to things that have topologically limited scope.
Actually we have plenty of examples of this; they are called routing protocols.
That doesn't settle the issue of whether SEND and NDproxy are or are not
incompatible, but I have no problem with the concept that a given (bridged) LAN
can only run one of them.
[Alain Durand]: I'm not sure the
parallel is relevant. Routing protocols are self-contained elements that do not
need each other... Here, at least in the example Jim Kempf & Erik gave,
the two elements could very well be used together...
As a matter of principle, I think it is better to standardize things so they
work together all the time rather than balkanizing the domain of application by
defining mutually exclusive standards.
[Hesham Soliman]: I don't think this
is the right comparison though. Routing protocols are performing similar
functions and are alternatives to each other. What's being discussed here is two
unrelated functions: Security and "bridging" that are not compatible. This
is quite different.
FWIW I don't have a problem with ndproxy being published while incompatible with
SeND. There are other examples of completely insecure experimental RFCs, e.g.
Fast handoffs. It's essential to make the document consistent though.
[Vijay Devarapalli]: what is being discussed is incompatibility between two protocols. not insecure experimental protocols. FWIW, draft-kempf-mobopts-handover-key-00.txt is tring to define how SEND can be used to create keys for fast handoffs.
[Dave Thaler]: As Brian pointed out,
proxy ND is already part of RFC 2461, and it's already PS. It's also still in
draft-ietf-ipv6-2461bis-01.txt which is targeted for DS.
The fact that SEND doesn't yet support proxy ND is not specific to this
specification, it's something for SEND to solve.
[Erik Nordmark]: The general case of
proxy ND, which this specification uses, can not provide any security against
MiTM because by definition the proxy is a MiTM. Thus it is completely
unreasonably to assume that SeND will solve this.
There are specific cases of proxy for SeND can be extended, that have the
property that there exists a security relationship between the host and the
proxy. An example of this is a MIP home agent. In such a case one can extend
SeND to allow for the mobile node to delegate its key
(somehow) to the home agent.
But with ndproxy you both want things to be transparent to the hosts, and you
want the ndproxy proxies to rewrite the ND packets. You can't do that and
prevent other nodes (aka attackers) from forging ND packets.
Thus any secure solution in this space requires at least one of:
1. that the host be modified to have a secure relationship with the
proxy
2. that the proxies do not modify the ND packets
Note that #2 can be done, but it requires that the proxies be able to receive
packets addressed to any MAC address (just like bridges do).
This is very much analogous to Ralph's comments about DHCP.
So expecting SeND to provide security when by design you need MiTMs in the
proxies isn't truth in advertising about this protocol.
[Christian Huitema]: What do you mean, unreasonable? It is certainly possible to write and sign something like "I am a secure host, I am behind an proxy, and the proxy address ix X:Y:Z". Obviously, that places requirement on SEND or ND-Proxy. SEND would have to allow a new format, or ND-Proxy would have to allow some explicit proxy discovery. But it is certainly neither unreasonable nor impossible.
So, thinking some more about it, I
have this nasty feeling about the usefulness of SEND. Compare the two
topologies:
Host-A <---> learning bridge <---> Host-B
Host-A <---> ND-Proxy <---> Host-B
SEND will work just fine with the learning bridge topology, but will not work
with the ND-Proxy topology. Yet, do you really believe that one is inherently
more secure than the other? Learning bridges can do all kinds of interesting
tricks, in fact more so than proxies.
SEND secures the mapping between an IPv6 address and a MAC address, but it does
nothing to guarantee that the L2 topology actually delivers the packets to the
intended destination. When we expand all that energy signing neighbor discovery
packets, have we really improved security?
[James Kempf]: Here's a concrete
example of how the address mapping part of SEND would improve security*
In 2002, I was sitting in the conference room at Mobicom browsing one of the
papers when my 802.11/IPv4 network connection started to act up. It would go
away, then come back, then hang for a long period of time. When I looked into
the matter more deeply, I discovered that the DHCP lease on my address had been
revoked, and my machine was attempting, unsuccessfully, to get another one. I
spoke to the NOC about it, and found out that they had only allocated enough
address space for 256 hosts, and there were well over 300 people in the room,
many of whom were knowledgable networking researchers.
Somebody was ARP spoofing, stealing addresses because not enough had been
allocated. ARP spoofing is one of the threats SEND is designed to counter, so if
IPv6/SEND had been deployed, this attack would not have been possible.
Now, you can argue that SEND doesn't protect the MAC address itself (and in
fact, specifically doesn't claim to), it just protects the mapping, so someone
could still just send out frames with your MAC address. So it is still possible
for an attacker to spoof a MAC address, for those shared media where a host
specific MAC address appears on the air, like 802.11, and the address is not
protected (and this is a particular problem for 802.11 because the management
frames are completely unprotected). The spoofer cannot, however, claim frames
holding packets having your IP address if SEND is used, because the mapping is
protected. In the end, there is really only so much IETF can do, and now it is
up to IEEE to fix their MAC protocol so that people can't steal addresses or
spoof management frames (I'm told they are working on it).
In this particular case, the service was free so the fact that I was
inconvenienced by not being able to use the connection was of little economic
consequence. But if I had been using a connection to a wireless service provider
who charges for the service, the consequence may not have been as minor. In my
view (speaking from a wireless service provider perspective), SEND is an
excellent reason why a wireless service provider whose media has characteristics
similar to 802.11 might want to deploy IPv6, provided of course that host
support is available.
The full list of threats SEND is designed to counter is outlined in the Security
Considerations section of the SEND RFC and detailed in RFC 3756; note that these
are the only threats SEND is designed to counter. In particular, as discussed in
somewhat excruciating detail on this thread and explcitly mentioned in the SEND
RFC, the address mapping part of SEND does not claim to protect proxy ND of any
sort. I spoke to Dave Thaler about this a few IETFs ago, and I believed we
agreed that it was OK for this draft, but I've not looked at the draft since.
However, it seems pretty clear to me that there is considerable interest in
security for proxy ND. The Mobopts IRTF research group is interested for
securing fast handover, and it would also be useful for MIP6 though the MIP6
group is busy with other tasks at the moment so it has not hit their radar
screen yet. We had a BAR BOF for Mobopts on proxy SEND in San Diego, but there
hasn't really been much discussion about it on the Mobopts list.
Considering the more leisurely pace work takes in IRTF, something might not pop
out of Mobopts on proxy SEND for some time. So my suggestion is, if people think
proxy SEND is a burning issue, instead of continuing to argue about this
particular draft, maybe it would be more productive to have a BOF (if the WG
chairs of the IPv6 group would rather not sponsor proxy ND security work in the
IPv6 WG) or schedule a session at the IPv6 WG meeting (if the chairs would want
to sponsor the work). I'd be happy to help organize the BOF if one is necessary.
*Note that there is another part of SEND which people seem to forget, involving
router security. That should work with NDProxy, learning bridges, and any other
local subnet topology where a first hop router is involved and the host routes
all off subnet traffic through the router.
[Bob Hinden, re the Mobicom attack above]: For what it is worth, I would note that if you were using IPv6, this wouldn't have occurred (at least for the reasons of people trying to get around address scarcity by ARP spoofing...), because IPv6 doesn't impose any practical limit on the the number of hosts per link (due to 64 bit interface identifiers).
[Jari Arkko]: SEND is just one part
of the overall puzzle, not the sole answer to all problems. And solutions
usually are unable to prevent all problems. In particular, whatever you do, its
hard for endpoints to ensure that their packets are not stopped, redirected,
modified, or looked at en route. One thing you can do is to ensure that the
packets are protected so that these attacks, if performed, would not have an
impact beyond denial-of-service. That's why we have protocols such as TLS or
IPsec*.
Another thing you can do is to ensure that such attacks are harder to launch or
at least that they can not be launched from anywhere. This is where SEND helps.
Basically, SEND prevents the use of L3 control protocols to hijack sessions.
Of course, a router or learning bridge that legitimately gets the traffic could
still send it to someone else or to the trashcan. But it would be great if we
could at least prevent outsiders, such as people that plug into an Ethernet port
at an office, from doing this.
But an attack below layer 3 will still get you into trouble.
This includes things like wireless attacks, e.g., an open wireless LAN or
spoofing your L2 address to a switch that looks at source MACs. Various methods
exist to deal with these issues, starting from a switch locking into to a MAC
address upon first usage on a port ("Learn and Lock" on some equipment).
See also Section 9.1 in the SEND protocol document.
*) Earlier, we even considered doing per-packet cryptographic protection based
on SEND. This would be your zero-config .1X variant.
I'm sensing that part of this
discussion is whether an interaction between features 1 and 2 should be solved
in feature 1 or 2 spec. Of course, feature 1 folks will believe that spec 2 (and
people behind spec 2) should solve it, and vice versa :-) But most of the time
we seem to deal with this type of a problem in the in the IETF by adding stuff
to the document that came later.
Finally, generally speaking Christian is right about his solution. This could
indeed be done. But there is also a question mark in the solution and I'm not
sure exactly what assumptions it needs to have about the network topology and
technology. The question is how a host knows that it should indeed be behind a
proxy and that its not simply being attacked? Perhaps we could develop an answer
to this question -- maybe we know it for sure in some network types and in
others we could learn it in the SEND transition style. But its still different
from Erik's home agent example, because in that example we know for sure that we
have a home agent, and we even have a security association with it so we could
use that when building some kind of a delegation scheme.
[Dave Thaler]:
The problematic text that makes the document inconsistent is, from the Requirements section:
> o Support secure IPv6 neighbor discovery. This is discussed in the Security Considerations section.
This was an original goal, which as pointed out was not achieved, but is not really a strict requirement just a goal. For example, IPv4 ARP Proxies are deployed today without meeting this requirement. Hence propose to delete this sentence.
Regarding Erik's summary of:
> Thus any secure solution in this
space requires at least one of:
> 1. that the host be modified to have a secure relationship with the proxy
> 2. that the proxies do not modify the ND packets
> Note that #2 can be done, but it requires that the proxies be able to receive
packets addressed to any MAC address (just like bridges do).
I accept this conclusion, and point out that #2 cannot be used in either the 802.11 scenario (since the proxy cannot be promiscuous) or the PPP scenario (since the link-layer address format is different). Hence #1 is all that's left. Here, there's two classes of nodes: the local nodes on the leaf network, and the nodes (including the router) on the external link between the proxy and the router.
For local devices on the leaf network needing to verify NA's from external devices, having a secure relationship is not unreasonable, and this was the (admittedly somewhat obscured) intent of the text:
> The requirements for securing
proxied
> messages are similar to those for securing Router Advertisements,
> since the receiver must verify that the advertisement came from a
> valid router/proxy, rather than from the owner of a specific address.
although this requires additional work to specify how to use RA-like auth in NA messages,
but I still argue that this particular work belongs in the SEND WG since it is not unique to
this draft as discussed earlier. It would be part of a new "Proxy SEND" document as James
Kempf suggested.
For devices on the external link between the proxy and the router needing to verify NA's from internal devices, the constraint of avoiding any incentive to do an IPv6 NAT means it is not reasonable that they have a secure relationship with the proxy (or rather that they have any secure relationship they wouldn't have with any other non-proxy host). However, in the PPP scenario this shouldn't be an issue in practice since the link is point-to-point. For 802.11 networks on the other hand, bridging and SEND do appear to be inherently incompatible in the case where you don't want the router to know that the proxy is a proxy (for fear, real or imagined, of being charged extra). Hence there's a tradeoff between security and "privacy" here, with a sort of middle ground being Christian's "I am behind an proxy, and the proxy address is X:Y:Z".
Propose replacing:
> From an IPv6 perspective, RFC 2461
[ND] already defines the
> ability to proxy Neighbor Advertisements. The requirements for
> securing proxied messages are similar to those for securing Router
> Advertisements, since the receiver must verify that the
> advertisement came from a valid router/proxy, rather than from the
> owner of a specific address.
with
> From an IPv6 perspective, RFC 2461
[ND] already defines the
> ability to proxy Neighbor Advertisements. Since the ND packets must
> be modified whenever the link-layer address formats are different (as
> with PPP) or promiscuous reception is not possible (as with 802.11),
> securing any solution in this space requires that hosts have a secure
> relationship with the proxy.
>
> 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.
Proposed resolution: Accept
Issue 18:
Dynamic removal of proxy
Submitter: Erik Nordmark
Submitter email address: erik.nordmark@sun.com
Date first submitted: January 18, 2005
Reference:
Document: ipv6-00
Comment type: Editorial
Priority: 1
Section: 3
Rationale/Explanation of issue:
There is at least one other listed
requirement which the protocol doesn't seem to satisfy:
- Allow dynamic removal of a proxy without adversly disrupting the network
Since there will be host which have the, now dead, proxy's link layer address in
their ARP/ND cache, communication will fail until this stale information is
flushed, which might take a minute or so. That seems like an adverse impact on
the network too me.
[Brian Haberman]: Agree that removal of a proxy, or the loss of a proxy, could adversely affect the network. However, this seems equivalent to a network failure or re-design and not an everyday activity.
[Erik Nordmark]: Again, the issue is the self-inconsistency in the document/protocol. Section 3 says that dynamic removal of a proxy should adversely disrupt the network. Yet the protocol doesn't satisfy this requirement as far as I can see.
[Dave Thaler]: Agree with Brian that this is equivalent to a network failure or re-design, which I agree with Erik does adversely affect the network.
I think the requirement was bad in this regard. Propose removing the self inconsistency as follows.
OLD: Allow dynamic addition/removal
of a proxy without adversely disrupting the network.
NEW: Allow dynamic addition of a proxy without adversely disrupting the network.
Proposed resolution: Accept
Issue 19:
Make Experimental not Informational
Submitter: Brian Carpenter
Submitter email address: brc@zurich.ibm.com
Date first submitted: January 24, 2005
Reference:
Document: ipv6-00
Comment type: Editorial
Priority: 1
Section:
Rationale/Explanation of issue:
(See also Issue 8: Make Informational)
I wonder whether Experimental
wouldn't send a clearer signal that there is some doubt about the viability of
the solution.
I can see how this could be very useful in certain types of network environment,
and publishing as Experimental will allow people to share experience and try to
fix the open questions.
[John Loughney]: I agree with Brian C.; I think epxerimental might be appropriate for this.
[Erik Nordmark]: That would be better than informational.
[Jari Arkko]: I agree. But I also think that if the document has inconsistencies those should be corrected even before publishing it as experimental.
[Brian Haberman]: I have no issues with making it Experimental
[Ralph Droms]: I apologize if I've missed this particular point earlier in the discussion - Experimental seems appropriate to me unless there is widespread deployment of some version of the protocol that this document is specifying. And I agree about correcting any inconsistencies prior to publication...
I think this document would be more appropriately published as an Experimental RFC rather than Informational. The inconsistencies between the requirements for securing IPv6 neighbor discovery and allowing dynamic addition/removal of a proxy and the text itself should be fixed.
[Dave Thaler]: I have no objection.
[Bob Hinden & Brian Haberman]: We also agree that it would be better to publish it as an Experimental RFC, than at Informational.
Proposed resolution: Accept
Issue 20:
DHCPv4
Submitter: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted: January 30, 2005
Reference:
Document: ipv6-00
Comment type: Technical
Priority: 1
Section: 4.1.3.3
Rationale/Explanation of issue:
There are two small issues with the mechanism for accommodating DHCPv4. First,
the mechanism is incompatible with the authentication protocol for DHCPv4
described in RFC 3118. In fact, the mechanism will be incompatible with any
authentication that verifies the integrity of the data in the DHCPv4 message
header, as changing the broadcast bit from 0 to 1 should be detected as a change
in the contents of the message. Second, there should be a warning that a DHCPv4
client might detect, with subsequently undefined behavior, that the broadcast
bit has been changed from the setting in the message originally set by the
client.
[Dave Thaler]: Agreed. The point of inclusion of DHCPv4 is to document existing practice in a number of ARP Proxies today. I will add these points.
Current text in 4.1.3.3:
> If the received packet is a DHCPv4 DISCOVER or REQUEST message,
> then instead of changing the client's hardware address in the
> payload, the BROADCAST (B) flag is set in the proxied packet.
> This ensures that the proxy will be able to receive and proxy the
> response since the response will be broadcast rather than unicast
> to that hardware address. The hardware address is thus used only
> as a unique identifier and hence need not be a link-layer address
> on the same segment.
Proposed text, to be added after the current text:
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 [DHCPAUTH] is not used, a DHCPv4 client might still
detect, with previously undefined behavior, that the broadcast bit has been
changed from the setting in the message originally set by the client. However,
the point of this rule is not to solve this problem, but rather to document
existing practice.
[Ralph Droms]: I don't know of better behavior and, in fact, I wasn't aware of this behavior in ARP proxies...
That text is fine with me.
Proposed resolution: Accept
Issue 21:
Editorial nits in ipv6-00
Submitter: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted: January 30, 2005
Reference:
Document: ipv6-00
Comment type: Editorial
Priority: 1
Section: Abstract, 4.1, 4.2
Rationale/Explanation of issue:
Editorial suggestion:
My understanding is that NDproxy is intended for use between media that cannot
be bridged at the link-layer, and which, presumably, have different link-layer
header formats. While it would, I guess be obvious to an implementor, It would
clarify the text to add a sentence or two in the last paragraph of section 4.1
explaining that the entire layer two header in the outgoing packet must be
modified to the format of the layer 2 media over which the packet will be
forwarded.
Unimportant editorial nits:
Although the title is "Bridge-like Neighbor Discovery Proxies (ND Proxy)", the
Abstract does not restrict the protocols in the specification to IPv6. In fact,
there is support for IPv4 bridging, including ARP and DHCPv4. I think it would
clarify the intent of the draft to change the title (or, at least, the abstract)
to reflect that bridging of some IPv4 protocols is included in this
specification.
Sections 4.1 and 4.2 might be more accurately titled "Forwarding Packets" and
"Originating packets".
[Dave Thaler] Scenario 2 has different link-layer header formats, but Scenario 1 does not (the inability to bridge is due to the inability to be promiscuous, rather than any link-layer header difference), so it needs to be worded more generically.
OLD: When any other IP broadcast or
multicast packet (other than to the
IPv6 Link-scoped STP Multicast Group) is received on a proxy
interface, in addition to any normal IP behavior such as being delivered
locally, it is forwarded unchanged out all other proxy interfaces on
the same link.
NEW: When any other IP broadcast or
multicast packet (other than to the
IPv6 Link-scoped STP Multicast Group) is received on a proxy
interface, in addition to any normal IP behavior such as being delivered
locally, it is forwarded unchanged (other than using a new link-layer header)
out all other proxy interfaces on the same link.
and
OLD: When any other IP unicast packet
is received on a proxy interface, if
it is not locally destined then it is forwarded unchanged to the proxy
interface for which the next hop address appears in the neighbor
cache.
NEW: When any other IP unicast packet
is received on a proxy interface, if
it is not locally destined then it is forwarded unchanged (other than
using a new link-layer header) to the proxy
interface for which the next hop address appears in the neighbor
cache.
[Dave Thaler]: Proposed text to add to Abstract to address point 2:
The behavior of
one common type of IPv4 ARP Proxy deployed today is
documented herein for informational purposes, but this
document
concentrates on describing similar behavior for IPv6.
[Dave Thaler]: Accepted proposed renaming of 4.1 and 4.2.
[Ralph Droms]: OK with me.
I'll have to reread the draft, but it
seems to me the description of IPv4 ARP Proxy and DHCPv4 is more than simply
informational.
Proposed resolution: Accept
Issue 22:Unclear
text about ICMP errors
Submitter: Dave Thaler
Submitter email address: dthaler@microsoft.com
Date first submitted: February 15, 2005
Reference:
Document: ipv6-00
Comment type: Editorial
Priority: 1
Section: 4.1, 4.1.1
Rationale/Explanation of issue:
Section 4.1 stated no ICMP errors are sent:
OLD: Again the IPv4 TTL or IPv6 Hop
Limit is not
updated, and no ICMP errors are sent as a result of attempting
this forwarding.
and
OLD: Again the IPv4 TTL or IPv6 Hop
Limit is not
updated, and no ICMP errors are sent as a result of attempting
this forwarding.
While Section 4.1.1 stated (and only stated it for IPv6):
Whenever any packet is to be
forwarded out an interface whose MTU
is smaller than the size of the packet, the ND proxy drops the
packet and sends a Packet Too Big message back to the source, as
described in [ICMPv6].
Proposed text, to clarify intent:
In particular, the IPv4 TTL or IPv6
Hop Limit is not updated, and no ICMP
errors (except as noted in Section 4.1.1 below) are sent as a result of
attempting this forwarding.
and in 4.1.1:
Whenever any IPv4 packet is to be
forwarded out an interface
whose MTU is smaller than the size of the packet, and the Dont Fragment
bit is set, the ARP proxy drops the packet and sends a Fragmentation
Needed message back to the source.
Similarly, whenever any IPv6 packet is to be forwarded out an interface
whose MTU is smaller than the size of the packet, the ND proxy drops
the packet and sends a Packet Too Big message back to the source,
as described in [ICMPv6].
[Erik Nordmark]: Given that the proxy
is invisible at L3, I think it would make sense to add explicit statements about
any constraints on the IP source address to use when the proxy generates ICMP
errors.
I believe the ICMPv* specifications say to use an IP address assigned to either
the interface where the packet in error arrived, or assigned to the interface on
which the error is sent, but in the case of a proxy there might be a single IP
address assigned to all the proxy interfaces for all I know.
[Dave Thaler]: RFC 792 doesn't say how to select the source address, but RFC 2463 does. From section 2.2 (a-c only apply to responses, not PacketTooBig errors):
(d) Otherwise, the node's routing table must be examined to
determine which interface will be used to transmit the message
to its destination, and a unicast address belonging to that
interface must be used as the Source Address of the message.
Beyond the rule above, RFC3484 (address selection) would apply when choosing from among addresses on the same interface.
However, none of this is specific to ICMP error generation, it's the same as for locally originated packets (section 4.2). Hence, I'm not convinced that the rules need to be repeated here.
If you still disagree, please suggest text :)
Proposed resolution: Accept