[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: On-link Assumption and IPv6 On by default
On Wed, 24 Mar 2004, Pekka Savola wrote:
> This is a WG Last Call for comments on sending two documents to the
> IESG:
>
> 1) draft-ietf-v6ops-onlinkassumption-01.txt,
> "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful",
> target category BCP.
>
> 2) draft-ietf-v6ops-v6onbydefault-01.txt
> "Issues with Dual Stack IPv6 on by Default",
> target category Informational.
My own personal comments are below.
I think both documents are useful and we should progress with them
soon. It would be nice if we would be able to get a revised versions
out so that we could be done with them ;-). Endless revisions tend to
sap the energy of the authors and the WG..
onlink-assumption
=================
Tony already raised good points which call for clarification; fixing
those should be rather straightforward. I try to not repeat them
here. Other than that, this seems pretty good, though it can be tuned
slightly to accommodate for the fact that RFC2461bis (though there
hasn't been IPv6 WG consensus check yet) has removed the assumption..
substantial
-----------
The unreachability determination for a destination as it pertains to
this rule is an implementation detail. One implementable method is
to do a simple forwarding table lookup on the destination, and to
deem the destination as reachable if the lookup succeeds. The
Neighbor Discovery on-link assumption makes this method somewhat
irrelevant, however, as an implementation of the assumption could
simply be to insert an IPv6 default on-link route into the system's
forwarding table when the default router list is empty. The
side-effect is that the rule would always determine that all IPv6
destinations are reachable.
==> Tony already discussed a bit of this, and I think this should
probably be clarified. That is, even if you didn't insert the
default route in the forwarding table, you'd still have to conclude
that the default router list is empty and you have to send the
packet on the link, right? So, the particular implementation detail
doesn't seem to matter here, unless I'm missing something.
So, due to the onlink assumption, I think all the implementations
should treat *all the addresses* as unreachable... unless the
implementation specifically includes the case of "onlink assumption"
as part of its unreachable destination -determination (i.e., every
time if you have to resort to the on-link assumption the destination
should be considered unreachable and would lose the first rule).
We could document this particular implementation detail, but not
count on it.
editorial
---------
Abstract
This document proposes a change to the IPv6 Neighbor Discovery
conceptual host sending algorithm.
==> to make this more current, should this be "describes" or
"describes a proposition for" (a bit milder) instead of
"proposes"?
1. Introduction
==> might it make sense to add an informational reference to NDbis,
and add as a last paragraph, maybe like:
A revision of Neighbor Discovery [NDBIS] has removed the on-link
assumption from the specification, but this memo gives historical
reference and background to why this is has been a good decision.
...
Another security related side-effect of the on-link assumption has to
do with VPN's.
==> spell out VPN.
v6onbydefault
=============
substantial
-----------
==> I think it might be useful to add a "Conclusions" just before Security
Considerations, trying to summarize the recommendations from different
paragraphs (because there were ones which I'm not sure are being
recommended, like adding additional address selection rules), at least:
- Making TCP react to ICMP errors in SYN-SENT and SYN-RECEIVED states
when trying to connect to unreachable destinations.
- Removing the on-link assumption eliminates ND timeouts when trying to
send IPv6 packets on a link which has no IPv6 connectivity.
2.3.1.1 TCP Connection Termination
[...]
Since soft errors conditions are those that would entice an
application to continue iterating to another address, TCP shouldn't
make the distinction between ICMPv6 soft errors and hard errors when
in SYN-SENT or SYN-RECEIVED state. It should abort a connection in
those states when receiving any ICMPv6 Destination Unreachable
message. When in any other state, TCP would behave as described in
[HOSTREQS].
[...]
==> I think it would be appropriate to spell out the obvious reason for
reacting to these only in SYN-SENT or SYN-RECEIVED states. For example, add
at the end of the section:
Note that reacting to soft errors in all the states would have
significant security implications as it would be possible for anyone to
reset established sessions even without IP spoofing. However, as SYN-SENT
and SYN-RECEIVED states are very short-lived, the window of exposure is
very short and the threat is negligible.
....
5. Security Considerations
This document raises security concerns in Section 3.3.
==> I think we should try to summarize these somehow in Sec Cons section.
I can help with that if needed.
semi-editorial
--------------
Fixing the destination address selection mechanism by adding such a
rule is only a mitigating factor if applications use standard name
resolution API's that implement this mechanism, and these
applications try addresses in the order returned. This may not be an
acceptable assumption in some cases, as there are applications that
use hard coded addresses and address search orders (DNS resolver is
one example), and/or literal addresses passed in from the user. [...]
==> I think this, still, needs more explicit text. That is, this paragraph
is describing e.g., DNS resolvers which implement their own version of the
name resolution, and are not fixed by modifying the standard name
resolution. Unless I misunderstand this completely, maybe reword the
beginning to something like:
Fixing the destination address selection mechanism by adding such a
rule is only a mitigating factor if applications use their own versions
of name resolution APIs which do not implement the same functionality
as the standard name resolution APIs.
...
On a network that has no IPv6 routing and no IPv6 neighbors, making
the assumption that every IPv6 destination is on-link will be a
costly and incorrect assumption. If an application has a list of
addresses associated with a destination and the first 15 are IPv6
addresses, then the application won't be able to successfully send a
packet to the destination until the attempts to resolve each IPv6
address have failed. This could take 45 seconds
(MAX_MULTICAST_SOLICIT * RETRANS_TIMER * 15). This could be
compounded by any transport timeouts associated with each connection
attempt.
==> expand this a bit by adding at the end like: , bringing the timeouts to
even dozens of minutes.
2.3.3 SCTP Implications
According to [SCTPIMP], SCTP ignores all ICMPv6 destination
unreachable messages. The existing SCTP specifications do not
suggest any action on the part of the implementation on reception of
such messages. Investigation needs to be done to determine the
implications.
==> we discussed this with Randall Stewart, and the proposed text for
this is (just to re-iterate and to give WG chance to object ;):
2.3.3 SCTP Implications
According to [SCTPIMP], SCTP ignores all ICMPv6 destination
unreachable messages that do not indicate that the SCTP
protocol itself is unreachable. The existing SCTP specifications do
not
suggest any action on the part of the implementation on reception
of
a "soft error".
Unlike TCP, SCTP itself is multihomed and allows
a user to specify a list of addresses to connect to. Upon reception
of a Destination Unreachable Message during connection setup, SCTP
should attempt to retransmit the Initiation message to one of
its alternate addresses and put the address that encounters the "soft
error" into the unreachable state. This will prevent use of the address after
the association is set-up until SCTP's heartbeat mechanism finds
the address to be reachable.
In some cases the application
may not have provided a list of addresses, and then it may
be benefical for SCTP, at a minimum, to mark the address as
unreachable so that the application can acquire a notification
through its application interface. In such a case the application
could then either take action upon the address notification by
aborting the connection attempt or allow SCTP's normal timer
mechanism to continue retransmitting the INIT message to the
peer's address.
There is work in progress to specify adding the support for handling
soft errors to the SCTP specification.
...
A similar problem could exist for VPN software. A VPN could protect
all IPv4 packets but transmit all others onto the local subnet
unprotected. At least one widely used VPN behaves this way. This is
problematic on a dual stack host that has IPv6 enabled on its local
network. It establishes its VPN link and attempts to communicate
with destinations that resolve to both IPv4 and IPv6 addresses.
[...]
The reason that packets meant to be
protected would be sent in the clear on the local network is either
because of the on-link assumption discussed in Section 2.2, or of
malicious hijacking of traffic by a rogue "fake" router advertising a
prefix.
==> I think this is is not spelling out the different cases well enough,
that is:
1) there is a legitimate IPv6 router on the link, and the node is using it
for v6 access, and VPN does not protect that
1.b) the host has activated a transition mechanism (e.g., 6to4 or Teredo),
VPN does not block it, and gets v6 access using that. One could guess that
at least Teredo could punch through such VPN firewalls.
2) there is no legitimate v6 router on the link, but the on-link assumption
throws the packets on the link, not protecting them (communication fails)
3) there is rogue router capturing the packets (similar to 1)
editorial
---------
Abstract
This document discusses problems that can occur when dual stack nodes
that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4
and IPv6 environments. The problems include application connection
delays, poor connectivity, and network security. Its purpose is to
raise awareness of these problems so that they can be fixed or worked
around. The purpose of this document is not to try to specify whether
IPv6 should be enabled by default or not, but to raise awareness of
the potential issues involved.
==> there appears to be significant duplication of text after "Its purpose
..." -- maybe reword like:
Abstract
The purpose of this memo is to
raise awareness of these problems so that they can be fixed or worked
around, not to specify whether IPv6 should be enabled by default or not.
....
2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . . . 6
2.3.1.1 TCP Connection Termination . . . . . . . . . . . . . . . . 6
2.3.1.2 Asynchronous Application Notification . . . . . . . . . . 7
==> one might consider setting tocdepth to 3
It begins in Section 2 by examining problems within IPv6
==> s/It/This memo/
doesn't match the global IPv6 destination, and the site-local IPv4
source doesn't match the global IPv4 destination. The tie-breaking
==> add double quotes around "site-local" here?
On a network that has no IPv6 routing and no IPv6 neighbors, making
the assumption that every IPv6 destination is on-link will be a
costly and incorrect assumption.
==> s/a costly and incorrect assumption/costly and incorrect/ ?
(avoid repeating "assumption")
The IPv6 implementation should
be able to immediately notify applications or the transport layer
that it has no route to such IPv6 destinations, and applications
won't waste time waiting for address resolution to fail.
==> s/and app/so that app/
2.3 Transport Protocol Robustness
Making the same set of assumptions as Section 2.2, regardless of how
long the network layer takes to determine that the IPv6 destination
is unreachable, the delay associated with a connection attempt to an
unreachable destination can be compounded by the transport layer.
==> suggest starting a new paragraph after this.
failing the connection attempt, passing ICMPv6 errors up to the
application, etc...
==> s/..././
2.3.1.1 TCP Connection Termination
One solution is for TCP to abort connections in SYN-SENT or
==> s/is for TCP/for TCP is/
Since soft errors conditions are those that would entice an
application to continue iterating to another address, TCP shouldn't
==> maybe pick a different word than "entice" ?
A similar problem could exist for VPN software. A VPN could protect
==> spell out VPN?
Some more complex mechanism could be implemented to apply the correct
policy to such packets. This could be easy to do if tunnel endpoints
==> s/mechanism/mechanisms/ (or s/Some/A/)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings