Subject: transmech substantial comments

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Nov 2003 17:04:41 +0200 (EET)

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Nov 2003 16:50:22 +0100 (CET)

> there.  Can anyone think of such a document?  

I don't know of such a document.

> Alternatively, service names instead of node names can be used.

I can add this.

> the previous paragraph, as "A possible..." as it seems like a more logic

Don't understand where you think it belongs; the several preceeding paragraphs 
follow on eachother. Which paragraph do you think it should preceed?

> it has been used in three different meanings in the document:

This is one issue I want explicit WG feedback on tomorrow.
I don't have a problem removing them - it would simplify the text.

>     automatic tunneling, and can be removed.

That is definitely part of the reason for the explicit mention, but
I don't know if it the only reason.

>     better, and we may have to beef up the source address selection part of

Yes, if we remove the unidirectional tunneling text then the IPv4 source
address at the encapsulator can be described as something which is configured
since both ends of the tunnel need to have matching IPv4 addresses for the
tunnel.

>    is using dynamic MTU detection.

I could add this.

> ourselves, or at least give more guidance on that.

I don't see why we'd need to do that. Tunnels, using the same versions or
different versions, can cross a region where the DSCP is interpreted
differently thus the issues whether to copy the DSCP when encapsulating is
identical AFAIK.

For the congestion bits the same considerations apply whether the IP versions
are the same or different.

So do you have a concrete argument that we need explicit text on this?
(If we want this to move to DS sooner rather than later I think we should
avoid this.)

> think we will need stronger text than what's in 3.5:

Yes, if we remove the unidirectional tunnels it makes sense making this
more explicit.

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

Done.

> against the pseudo-interface.

ok; I'll rephrase.

> tunneling are not considered to be OK, in:

Instead of claiming that GRE with keys (which are in RFC 1701 but not part of
RFC 2784) is much secure, how about instead saying that AH/ESP can be applied
to the tunnel?

   Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 12 Nov 2003 01:02:54 +0900 (JST)

> (If we want this to move to DS sooner rather than later I think we should

	draft-ietf-ipsec-ecn-02.txt (expired) talks about the very issue.
	it is titled as IPsec-related document, but the consideration applies
	to any kind of tunnel.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Nov 2003 18:07:58 +0100

The guidelines for DSCP and tunnels are in RFC 2983, called, strangely
enough, "Differentiated Services and Tunnels." It's Informational.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Nov 2003 18:50:55 +0200 (EET)

> I don't know of such a document.

Now that I think about it, draft-ietf-dnsop-ipv6-dns-issues-02.txt at 
least could b expanded to include more guidelines rather than issues.  
I'll consider this..
 
> Don't understand where you think it belongs; the several preceeding
> paragraphs follow on eachother. Which paragraph do you think it should
> preceed?

It seems to me that the paragraph starting with "Since the.." starts to 
describe a separate problem.  There are two issues here AFAICS:

 1) an ipv6 node is placed on a link "prematurely", and advertises its 
address in the DNS.

 2)  an ipv6 node without connectivity tries to reach a node by getting a 
AAAA record from DNS, and

The general tone of a "A possible implication" -section seems to address 
1) only, while the preceding paragraph discusses 2).  So, saying 
"implication of these recommendations" seems to either belong after 1) 
(because it only covers 1), or reworded to be a bit more general.

Right?

> address at the encapsulator can be described as something which is
> configured since both ends of the tunnel need to have matching IPv4
> addresses for the tunnel.

Right. (There is an obvious failure mode with multiple interfaces and a 
change in where the route towards the tunnel endpoint points to, of 
course -- which why it probably needs to be spelled out better as 
spelled out later.)
 
> For the congestion bits the same considerations apply whether the IP
> versions are the same or different.
> 

No, I don't have a specific arguments.  It just looked like a potential 
hole in the spec.  But I'm OK with leaving it vague.
 
> Instead of claiming that GRE with keys (which are in RFC 1701 but not
> part of RFC 2784) is much secure, how about instead saying that AH/ESP
> can be applied to the tunnel?

One could say one or the other, or both (if they are actually more secure, 
which I'm not 100% sure about).

My concern is just that setting up a GRE tunnel instead of IP-IP tunnel is 
typically fully equivalent (subject to a trivial modification to the MTU 
usage parts), and configured similarly.

IPsec is of course a proper way to do it, but AFAIK it hasn't been
implemented (v4-in-v6 IPsec, that is) -- that's at least what Francis
Dupont has been saying (unless I misremember the context)...

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Nov 2003 09:04:10 -0800

> least could b expanded to include more guidelines rather than issues.

You're more than welcome to contribute text!

	- Alain.