Last Call Review of draft-ietf-v6ops-happy-eyeballs-
review-ietf-v6ops-happy-eyeballs-secdir-lc-murphy-2011-12-21-00

I have reviewed this document draft-ietf-v6ops-happy-eyeballs-06 as part of 
the security directorate's ongoing effort to review all IETF documents being 
processed by the IESG. These comments were written primarily for the 
benefit of the security area directors. Document editors and WG chairs 
should treat these comments just like any other last call comments.

This document sets requirements for any algorithm that produces "happy 
eyeballs" in a dual stack host – that is, an algorithm that reduces the delay 
due to making connection attempts with IPv6 addresses first and trying IPv4 
only when the IPv6 attempt fails.

The document attempts to be agnostic as to whether the preferred algorithm
is IPv6 or IPv4, but many of the statements only make sense if you presume 
that the preferred algorithm is IPv6.

The security considerations section points to the discussions in the text of 
"same origin" policies in web browsers, and problems that might occur if 
different addresses were used on different connection attempts to the 
same origin.  I can see that difficulties might occur if different addresses 
were used on different connection attempts to the same URI, so URIs of 
the same origin could also be a problem.  But I do not understand the 
security interaction with the same origin policies, since draft-ietf-websec-origin
defines "same origin" only in terms of the host name part of the URI:

   o  If the two origins are scheme/host/port triples, the two origins
      are the same if, and only if, they have identical schemes, hosts,
      and ports.

I am wondering about IPSec complications with this new procedure.  I 
suppose that there is ample opportunity to have inconsistent IPSec 
policies between ipv6 and ipv4 addresses for the same parts of the 
Internet.  I don't think that there is a way for IPSec to express a 
preference for the address family, but the system address family 
preference might include IPSec as choosing the preference (what border 
point it would be going through, maybe?).  Does a use of the 
winning address family over the preferred address family present 
an opportunity to get an unintended security result (like maybe 
downgrade almost)?

The following are comments about the writing, not security.

There are many places in the document where I was confused by the text.

Page 4
   As discussed in more detail in Section 3.2, IPv6 connectivity is
   broken to specific prefixes or specific hosts, or slower than native
   IPv4 connectivity.

Huh?  Not always.  I suspect this means "we focus on situations
where" or "can be broken . . . or slower".

Page 9
(This is an example of text that makes more sense if you presume 
that the preferred address family is v6)

   Such an implementation MAY make subsequent connection attempts (to
   the same host or to other hosts) on the successful address family
   (e.g., IPv4).  So long as new connections are being attempted by the
   host, such an implementation MUST occasionally make connection
   attempts using the host's preferred address family, as it may have
   become functional again, and it SHOULD do so every 10 minutes.  The
   10 minute delay before re-trying a failed address family avoids the
   simple doubling of connection attempts on both IPv6 and IPv4.
   Implementation note:  this can be achieved by flushing Happy Eyeballs
   state every every 10 minutes, which does not significantly harm the
   application's subsequent connection setup time.  If connections using
   the preferred address family are again successful, the preferred
   address family SHOULD be used for subsequent connections.  Because
   this implementation is stateful, it MAY track connection success (or
   failure) based on IPv6 or IPv4 prefix (e.g., connections to the same
   prefix assigned to the interface are successful whereas connections
   to other prefixes are failing).

I was confused that the first winning address family was allowed to be 
used:

   Such an implementation MAY make subsequent connection attempts (to
   the same host or to other hosts) on the successful address family

in subsequent connections but the winning address family in retries was 
encouraged to be used in subsequent connections:

                                                   If connections using
   the preferred address family are again successful, the preferred
   address family SHOULD be used for subsequent connections.

This makes more sense if you presume they are talking about a situation 
where ipv6 is preferred, the ipv6 address was tried and failed.  The first 
successful address family was ipv4 and the later retry succeeded with ipv6.  

So it is OK to keep using the ipv4 address, but once ipv6 has succeeded 
the recommendation is much stronger to continue to use the ipv6 address.

I believe that the sentence that says 
                                    it MAY track connection success (or
   failure) based on IPv6 or IPv4 prefix (e.g., connections to the same
   prefix assigned to the interface are successful whereas connections
   to other prefixes are failing).

means that is implementations MAY track success by address family 
only, rather than per-prefix.  (But I am not at all sure what the 
"assigned to the interface" means.)

page 10

                 While IPv6/IPv4 translation makes that difficult, IPv6/
   IPv4 translators do not need to be deployed on networks with dual
   stack clients, because dual stack clients can use their native IP
   address family.

Is it expected that networks will migrate from ipv4-only to dual stack 
as a whole – there will not be a mix of ipv4-only and dual stack hosts 
on the same network?  If there is a mix, will the presence of translators 
for the ipv4-only hosts present the mentioned difficulties to the dual 
stack hosts?

Page 11

Section 5.4 says:
   It is possible that an DNS query for an A or AAAA resource record
   will return more than one A or AAAA address.  When this occurs, it is
   RECOMMENDED that a Happy Eyeballs implementation order the responses
   following the host's address preference policy and then try the first
   address.  If that fails after a certain time (see Section 5.5), the
   next address SHOULD be the IPv4 address.

Section 6 puts it differently:

   3.  If that connection does not complete within a short period of
       time (e.g., 200-300ms), initiate a connection attempt with the
       first address belonging to the other address family (e.g., IPv4)

What if the preferred address family is ipv4?

Section 5.5 says:

                                        Stateful algorithms are expected
   to be more aggressive (that is, make connection attempts closer
   together), as stateful algorithms maintain an estimate of the
   expected connection completion time.

Do you mean the stateful algorithms are capable of maintaining an estimate?  
Or do you mean that they always maintain an estimate (a SHOULD or MUST)?

Section 5.6 says:
   Web browsers implement a Same Origin Policy [I-D.ietf-websec-origin]
   which causes subsequent connections to the same hostname to go to the
   same IPv4 (or IPv6) address as the previous successful connection.

Do you mean "*requires* subsequent connections?  I don't see how the 
policy causes an address choice.

--Sandy Murphy