Subject: (ngtrans) DSTM ND comments

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Mar 2002 16:00:22 +0200 (EET)

Hi,

A few comments on DSTM ND draft.

==> IANA considerations part is missing though IANA action is required.

          Dual Stack deployment using DSTM and neighbour discovery

==> at least ND should be in capitals.

Abstract

   Today IPv6  nodes are generally  dual stacked.  With  its automatic
   configuration  of  tunnel  end   points,  [DSTM]  is  an  appealing

==> endpoints?

2.1 Communication initiated by a DSTM Node
    |+=+=+=+=+>|          | - DSTM Node queries the DSTM server for an
    |          |          |   IPv4 address using an encapsulated RS
    |          |          |   request.

==> How does the node know the address of the DSTM server?

    |    <=====|          | - The DSTM server sends dynamic  update to
    |          |          |   DNS with the temporary IPv4 address of
    |          |          |   the DSTM Node for further IPv4 initiated
    |          |          |   communications

==> this part (also in 2.2) is IMO unnecessary: it isn't specified in DSTM 
draft, so probably it shouldn't be here either.

2.3 Tunneling of ND messages
 
==> I think the graph on the left can be removed... :-)

    The tunnel between DSTM server and DSTM Node (and reciprocally
    between DSTM Node and DSTM server) is "degenerated" (tunnel
    entrance and exit coincide with the endpoints of the traffic
    beeing tunneled). So it does not have any security problem.

==> Tunnel isn't degenerate unless addresses are equal; and they aren't.  
So I think this is completely false (and in any case, I'm not sure if I'd 
*ever* be confortable with saying "does not have any security problem".

2.4 DSTM requirements related to tunneling for DSTM Nodes and servers
     Case of the DSTM server:
         MUST encapsulate DSTM RA packets (see 3.2) sent to a DSTM
         host.
         MUST decapsulate any 6over6 packet and accept DSTM RS packets
         (see 3.1) sent to it by a DSTM Node.

==> the latter seems especially bad in the VPN case when the IPv6 source 
address is changing.

  3.2 RA for IPv4 address allocation [borrowed from RFC2461]

      M              1-bit "Managed address configuration" flag.  When
                     set,   hosts  use  the   administered  (stateful)
                     protocol   for   address   autoconfiguration   in
                     addition  to any  addresses  autoconfigured using
                     stateless address  autoconfiguration.  The use of
                     this flag is described in [ADDRCONF].
[... and lots of other options ]

==> perhaps it would be best to be quiet if you don't have anything new to 
say or specify in this context: just referring to the draft would probably 
be ok.  The basic parts of RA take 1.5 pages...

4. Security issues

   By  the  virtue  of   authentication  headers  in  RA/RS  messages,
   communication in the IPv6  network are safe. 

==> this is quite problematic in practise, see
draft-kempf-netaccess-threats-00.txt;  are you really sure you want to
make these available to the general public?

   Nevertheless, there is
   a risk of deny of service if a malicious IPv4 node initiates lot of
   connections to IPv6 node. This risk is mitigate by the reuse of the
   same  temporary  IPv4  address  by   the  IPv6  node  for  all  its
   simultaneous   communications  with  several   IPv4  nodes.  To  be
   successful such  an attack  must be conducted by a single IPv4 node
   against several  different IPv6 nodes.  This can be avoided  by the
   DSTM Server that MAY limit  the number of association for a  single
   IPv4 host.
 
==> blind decapsulation in tunnels once more...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords