Threats relating to IPv6 multihoming solutions

Summary: Needs a YES.

(Ted Hardie) Discuss

Discuss (2004-10-27)
None of these issues are reasons to block this document, but the combination
was enough to put this into DISCUSS rather than Comment.  After we've had
a chance to discuss them, I anticipate shifting to no-ob or yes.

In section 2., the draft says:

address     - an IP layer name that contains both topological
                    significance and acts as a unique identifier for an

Is it important that it be a unique identifier?  I know of cases
where the same IP address is bound both to an ethernet
interface and a tunnel interface.  Those interfaces are
unique at some layer, just not at the IP layer.  I'm not sure the
distinction is worth raising here, in the terminology section,
but I also wasn't sure how important "unique" was to the authors.

In section 3.1, the draft says:

 Applications that use security
   mechanisms, such as IPsec or TLS, with mutual authentication have the
   ability to "bind" the FQDN to the cryptographic keying material, thus
   compromising the DNS and/or the routing system can at worst cause the
   packets to be dropped or delivered to an entity which does not posses
   the keying material.

The binding isn't always to the FQDN; it can be to an address.  Could this
be rephrased as:

 Applications that use mutually authenticating security mechanisms, such
  as IPSEC or TLS, have the ability to bind an address or FQDN to cryptographic
  keying material.  Compromising the DNS and/or routing system can result
  in packets being dropped or delivered to an attacker in such cases, but
  since the attacker does not possess the keying material the application
  will not trust the attacker.

This section also uses "class of applications", where I believe they are talking
about "class of security configurations for applications".   The same
application (or class of applications) could employ each of these.

Do the authors consider "leap of faith" trust arrangements to fall into their
5th category?  They certainly lack strong identity, but they seem to
provide assurance that a particular peer is the same peer over a number
of interactions; there may be no assurance as to who that peer is with
reference to an external system, but that may not be required.  4.1.2 touches
on this, but it wasn't clear to me whether these trust arrangements fell
under 5 or were some other category.

In Section 7, the draft says:

   A possible approach that solutions might investigate is to defer
   verification until there appears to be two different hosts (or two
   different locators for the same host) that want to use the same

Does this mean simultaneous hosts/locators?  I'm concerned that a
combination here of a DoS and impersonation could make
simultaneous appearance rare:  A is talking to B;  X DoS'es A
while impersonating A to B;  B sees a "new A", but no longer
has the ability to verifiy the first A.

(Scott Hollenbeck) Discuss

Discuss (2004-10-25)
Section 3.1 asks this unresolved question:

[TBD: Does one-way authentication, without mutual authentication, add a different class of applications?]

This should be cleaned up before IESG review.
Comment (2004-10-25)
No email
send info
Missing IANA Considerations.

(Russ Housley) Discuss

Discuss (2004-10-27)
  In addition to the TBD already identified by Scott, I have a few
  other concerns.

  This document is, perhaps necessarily, somewhat incomplete.  It is
  difficult to do a real analysis without pinning down specific protocol
  details, which this draft cannot do given the topic it is trying to
  cover.  It includes a general analysis of redirection attacks based
  on multihoming solutions that allow locator changes.  As such, it
  should point out that additional work is needed, especially in
  the following areas:

  1) If we were to make the split between locators and identifiers, then
     we probably want to tie most application security mechanisms to the
     identifier, not to the locator.  Therefore, work is needed to 
     understand how attacks on the identifier mechanism affect security,
     especially, in my mind, attacks on any mechanism(s) that bind 
     locators to identifiers.

  2) Does multicast make matters worse?  It usually does.

  3) Connectionless transport protocols need more attention.  They
     are already difficult to secure, even without a locator/identifier
Comment (2004-10-27)
No email
send info
  Comments include ones from SecDir review by Rob Austein.

  The title and abstract are a bit confusing unless one already
  understands the subject of the document.  The document is really
  pretty specific to issues surrounding locator/identifier split
  and redirection attacks.

  The document says:
  : identifier  - an IP layer identifier for an IP layer endpoint
  :               (stack name in [NSRG]).  The transport endpoint is a
  :               function of the transport protocol and would
  :               typically include the IP identifier plus a port
  :               number.  There might be use for having multiple
  :               interfaces per stack/per host.
  s/interfaces/identifiers/ ?  Probably not, but the text is a bit
  confusing, since the very next sentence says that identifiers
  aren't associated with an interface.  Please clarify.

  In section 4.1, please be blunt in pointing out the man-in-the-
  middle potential in all of the redirection attacks.

(David Kessens) Yes

Comment (2004-10-21)
No email
send info
The draft doesn't have an IANA Considerations
section, which should be a null one if present. Also Appendix
A will need to be removed.

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Barry Leiba No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record