transmech substantial comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I believe there are some aspects of the spec to clarify & iron out yet. 
I've only written up the substantial part of my review comments.

Most importantly, I think we'll have to consider whether we want to make
ingress filtering and tunnel source address selection/verification more
explicit (this may be a problem with a few special cases of current
implementations, not sure) becuase the current model is rather vague and
too insecure (issues 2, 5, 6).

1) section 2.3 on advertising addresses in the DNS is a bit out of place in
this document.  If there was some other doc describing how to provision
services with addresses in the DNS, the discussion would be best placed
there.  Can anyone think of such a document?  

In any case, I believe we need an additional recommendation, that a node
should not be added in the DNS before all the externally visible services
are supported (e.g., there should not be an AAAA record for foo.example.com,
until foo (an IMAP/SMTP server) supports both IMAP and SMTP over v6). 
Alternatively, service names instead of node names can be used.

so, I'd suggest rewording the list and the paragraph to something like:

   The recommendation is that AAAA records for a node should not be
   added to the DNS until all of these are true:

     1) The address is assigned to the interface on the node.

     2) The address is configured on the interface.

     3) The interface is on a link which is connected to the IPv6
        infrastructure.

     4) All the services, which are looked up from the DNS, provided 
        by that node have been IPv6-enabled.

[add:]
   The last one practically implies that unless all the services of a node
   are transitioned simultaneously, one should configure service names
   instead of host names in the DNS -- for example, use "smtp.example.com"
   for SMTP only, and "imap.example.com" for IMAP only, even though they
   might point to the same node.  Using service naming allows one to
   decouple the services from the nodes providing services, also implying
   more fine-grained control in the process of enabling IPv6-enabled 
   services.

also move the paragraph starting with "A possible implication" up before
the previous paragraph, as "A possible..." as it seems like a more logic
place for it.

2) I believe unidirectional tunneling should be removed.  Note that it seems
it has been used in three different meanings in the document:
  - "point-to-point link", can run neighbor discovery over the tunnel
    (this obviously doesn't work with NBMA-type tunneling which has been
     removed from the spec.)
  - the v4 source address of the other tunnel end-point may be on the same
    node than the v4 tunnel end-point that was configured on this node, so
    unidirectional tunnels can be used to avoid this "tunnel source address
    selection" -problem.
  - "ingress filtering and routing is bidirectional", that when you send
    an IPv6 packet to global address X, the reply will come back using the 
    same interface.

So, because the first definition is obviously closer to the mark:
  - unidirectional tunnels with the first definition are a remnant of
    automatic tunneling, and can be removed.
  - the bidirectionality rules need to be reworded and described
    better, and we may have to beef up the source address selection part of
    a tunnel a bit.

3) do we need to add the following kind of clarification to section 3.2.1 as
a caveat on fixed MTU use?  

   One should note that even though MTU of a tunnel on a node is limited to
   e.g. 1280 bytes, the nodes still must be able to process larger received
   packets, in case that the peer has configured a higher MTU or if the peer
   is using dynamic MTU detection.

.. just to clarify that people don't too eagerly jump to conclude that
MTU=MRU here (or maybe that needs to spelled out in the decapsulation
section)..

 4) We specify the that the ToS byte for the v4 header is 0 unless otherwise
specified, and refer to a couple of documents for that.  A problem with this
is that I'm not sure if those documents actually tackle the problem of
*different* protocol-version tunnels -- rather, they (AFAIR) discuss the
issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS
byte from the inner IP header is a trivial excercise.

I fear that we may have to specify the rules for setting the ToS byte
ourselves, or at least give more guidance on that.

 5) As a consequence from the move to bidirectional tunnels (I hope..), I
think we will need stronger text than what's in 3.5:

        Source Address:
              IPv4 address of outgoing interface of the encapsulator.
                The source address MAY alternatively be administratively
                specified to be a specific IPv4 address assigned to the
                encapsulator.  This is often necessary on encapsulators
                with multiple IPv4 addresses to ensure that the IPv4
                source address is acceptable to the decapsulator.

Reword this to e.g.:

        Source Address:
              IPv4 address of outgoing interface of the encapsulator or
              an administraively specified address as described below.

And at to the end, after the header field listings:

  When encapsulating the packets, the nodes must ensure that they will use
  the source address that the tunnel peer has configured, so that the 
  source addresses are acceptable to the decapsulator.  This
  may be a problem with multi-addressed, and in particular, multi-interface
  nodes, especially when the routing is changed from a stable condition, as
  the source address selection may be adversely affected.  Therefore, it 
  SHOULD be possible to administratively  specify the source address of a 
  tunnel.


 6) the ingress filtering sections in 3.6 need beefing up a bit, reword:

                                 [...] Packets for which the IPv4 source
   address does not match SHOULD be silently dropped.

   A side effect of this source address verification is that the node
   will silently discard packets with an invalid IPv4 source address
   such as a multicast address, a broadcast address (255.255.255.255 and
   the broadcast addresses configured on the node), 0.0.0.0/8, and
   127.0.0.1/8.  In general, it SHOULD apply the rules for martian
   filtering in [RFC1812] and ingress filtering [RFC2827] on the IPv4
   source address.  Packets caught by these checks SHOULD be silently
   dropped.

with (remove the last sentence from the previous paragraph due to
duplication and):

   A side effect of this address verification is that the node
   will silently discard packets with a wrong source address,
   and packets which were received by the node but not directly addressed to
   it (e.g., broadcast addresses).  Packets caught by these checks
   MUST be silently discarded.

   In addition, the node MAY perform ingress filtering [RFC2827] on the IPv4
   source address, i.e., check that the packet is arriving from the
   interface in the direction of the route towards the tunnel end-point.
   If done, it is RECOMMENDED that this check is disabled by default.
   The packets caught by this check SHOULD be silently discarded.

(Note there that I elevated a "SHOULD check the source address" to a MUST,
because, well, the other scenario is just plain too insecure.)

And later, at the end of the section:

   After the decapsulation the node SHOULD silently discard a packet
   with an invalid IPv6 source address.  This includes IPv6 multicast
   addresses, the IPv6 unspecified address, and the loopback address but
   also IPv4-compatible IPv6 source addresses where the IPv4 part of the
   address is an IPv4 multicast address, broadcast address
   (255.255.255.255 and the broadcast addresses configured on the node),
   0.0.0.0/8, or 127.0.0.1/8.  In general it SHOULD apply the rules for
   martian filtering in [RFC1812] and ingress filtering [RFC2827] on the
   IPv4 address embedded in IPv4-compatible source addresses.

.. this also needs to change, at least to a list of checks, e.g., like:

   After the decapsulation the node MUST silently discard a packet
   with an invalid IPv6 source address.  The list of invalid source 
   addresses SHOULD include at least:

     o all multicast addresses (FF00::/8)
     o the unspecified address (::)
     o the loopback address (::1)
     o all the IPv4-compatible IPv6 addresses (::/96)
     o all the IPv4-mapped IPv6 addresses (::ffff:0:0/96)

   In addition, the node should perform ingress filtering [RFC2827] on the 
   IPv6 source address, as on any of its interfaces, e.g.:

     o if the tunnel is towards the Internet, check that the site's IPv6
       prefixes are not used as the source addresses, or

     o if the tunnel is towards an edge network, check that the source
       address belongs to that edge network.

(Section 4 on source address spoofing threats needs a bit beefing up as
well, but nothing major..)

7) Security considerations should be better in two aspects:
  * the first sentence states:

   Tunneling is not known to introduce any security holes except for the
   possibility to circumvent ingress filtering [RFC2827].

.. this is not correct, as noted later in this section on the attacks
against the pseudo-interface.

 * there should be text what to do if the current tradeoffs of configured
tunneling are not considered to be OK, in:

   An implementation of tunneling needs to be aware that while a tunnel
   is a link (as defined in [RFC2460]), the threat model for a tunnel
   might be rather different than for other links, since the tunnel
   potentially includes all of the Internet.  The recommendations to
   verify that the IPv4 addresses in the encapsulated packet matches
   what has been configured for the tunnel, coupled with use of ingress
   filtering in IPv4, ameliorate some of this.

.. e.g., add something like this:

   If the remainder threats of tunnel source verification are considered to
   be significant, a tunneling scheme with authentication should be used
   instead, for example Generic Routing Encapsulation (GRE) [GRE] with a
   pre-configured secret key.



     

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings