Subject: Re: WG Last Call: On-link Assumption and IPv6 On by default

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 00:05:40 +0300 (EEST)

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

---

From: Alain Durand <[email-masked]>
Date: Thu, 08 Apr 2004 16:03:00 -0700

> v6onbydefault

The quoted text probably needs clarification. The example about the DNS 
resolver
is in fact very simple, in /etc/resolv.conf (or equivalent), one 
usually uses literal addresses.
With literal assresses, address selection rules that are plugged into 
the resolver library
are bypassed... so if in your /etc/resolv.conf you have an ordered list:
3ffe::1
129.129.129.1
and the v6 network in not reachable, that will still cause unacceptable 
delays.

This example can be extended to any apps that accept literal addresses 
in its configuration.

	- Alain.