Threats Relating to IPv6 Multihoming Solutions
RFC 4218

Note: This ballot was opened for revision 03 and is now closed.

(Sam Hartman) Yes

Comment (2004-11-29 for -)
No email
send info
[also emailed to try and get a response before the telechat]

First, this was a well written explanation of the multihoming threats.
I appreciate the thoroughness of this work.

I do have one comment; this is not a discuss but I believe the
document would be improved by fixing a possible error.

On page 8:
     together with channel bindings allow protocols which in themselves
        are vulnerable to MiTM-attacks to operate with a high level of
           confidentiality in the security of the identification of the
     peer.  A
        typical example is the Remote Desktop Protocol (RDP) which when
        with opportunistic IPsec works well if channel bindings are
           available.  Channel bindings provide a link between the
        identification and the application protocol identification.

Is RDP actually the example you intented to use?  If so, are we
talking about Microsoft's RDP?  To the best of my knowledge, RDP
doesn't actually have any way of authenticating the user; the login
sequence is carried out within the RDP connection as a normal
application exchange.  Also, I believe RDP provides its own (weak)
encryption and I don't think is typically used with IPsec.  Perhaps a
better example is RDDP, the Remote Direct Data Placement Protocol.

(David Kessens) Yes

(Harald Alvestrand) No Objection

Comment (2004-12-02 for -)
No email
send info
Lucy Lynch, Gen-ART, reviewed draft-nordmark-multi6-threats-02.txt and found no showstoppers in that version.
Suzanne Woolf, Gen-ART, reviewed this version.
Her review:

Summary: This draft is ready for publication as Informational, perhaps
with minor changes. I think it's an important piece of background for
the work of multi6.

I like this draft, and the concept of it, very much. 

Minor reservations: 

Occasional use of first person is probably not sufficiently strong, or
at least sounds overly informal for the degree of precision and
clarity people need in order to trust what they're being told about
security topics. Also, the question "Does multicast make matters
worse?"  would have more impact as a supposition or surmise. (p.3)

The "DISCUSSION" part reads a little strangely IMHO-- brackets and
indents make it read as if it wasn't intended for the final version,
rather than being additional detail on the analysis.

Except for the stylistic concerns (which may be just a matter of
taste!) I think this is ready.

(Brian Carpenter) No Objection

(Margaret Cullen) (was Discuss, No Objection) No Objection

(Bill Fenner) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-12-01)
No email
send info
  Overall a very nice job.

  In the Abstract:
  s/inherent in the problem itself/inherent in all IPv6 multihoming solutions/

(Allison Mankin) (was Discuss) No Objection

Comment (2005-03-30)
No email
send info
The revision addressed my Discuss.  My Discuss was a bit inaccurate - it stated
a wrong section number - it was about 4.3, not 4.4, and about a DoS proposal.
The author much improved the text on revisiting.

Overall comment remains:  a very thoughtful document

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2004-12-02 for -)
No email
send info
*** matchref -- match citations and references.
    Input file: draft-ietf-multi6-multihoming-threats-02.txt

!! Missing citation for Informative reference:
  P026 L021:      [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6

!! Missing citation for Informative reference:
  P026 L030:      [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 2402,

!! Missing citation for Informative reference:
  P026 L033:      [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",

!! Missing citation for Informative reference:
  P026 L027:      [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet

!! Missing citation for Informative reference:
  P026 L024:      [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version

!! Missing citation for Informative reference:


Comments from AAA_doctor review (Jari):


This an excellent and well written document. I had no major
problems with it. However, a few smaller nits or questions
were found here and there. Nothing worth a DISCUSS, but you
could pass the comments along.


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

Not sure if the multicast angle relates to a specific solution
like the start of the list implies or if its a more general issue
with multihoming. I suspect the latter. Suggestion: if you haven't
dealt with multicast in this document, say so.

>    Hence there is a different way to describe the same thing.  If the
>    peer can somehow prove that it is the owner of the identifier, then
>    the peer can control the locators that are used with the identifier.
>    This way to describe the problem is used in [OWNER].

Hmm... I think there's a step here that seems a bit vague (may become
clear when you read the rest of the document, but not yet here). This
assumes that all communications are bound to the identifier, not the
locator. Perhaps you want to say this explicitly.

>  in the routing system
>    delivering packets to that address.  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.

Nit: TLS most often does not do mutual authentication. Suggestion:
s/use mutually authenticating security mechanisms/use security

>    The third, and final concern, is that if an attacker only need a few
>    packets to convince one host to flood a third party, then it wouldn't
>    be hard for the attacker to convince lots of hosts to flood the same
>    third party.  Thus this could be used for Distributed
>    Denial-of-Service attacks.

Perhaps you want to explicitly say something about the amplification
here. I believe amplification is the key issue here, and contrast
this to the 1:1 amplification in the spoofed TCP SYN attack.

>    For instance, in the case of TCP it
>    would help if TCP slow-start was triggered when the destination
>    locator changes. (Folks might argue that, separately from security,
>    this would be the correct action for congestion control since TCP
>    might not have any congestion-relation information about the new path
>    implied by the new locator).

I'm not completely convinced that it would help. Seems like TCP slow
start still involves a number of messages when the sender retransmits
after not getting a response. Depending on the number of retransmits
vs. the number of packets needed to get the attack going, this might or
might not be useful. The key is again amplification. How many packets
you put in as an attacker, and how many does the victim get? Suggestion:
s/it would help if/a partial defense would be given if/

>       Discussion: Perhaps the key issue is not about the granularity,
>       but about the lifetime of the state that is created?  In a
>       transport-layer approach the multihoming state would presumably be
>       destroyed when the transport state is deleted as part of closing
>       the connection.  But an IP-layer approach would have to rely on
>       some timeout or garbage collection mechanisms perhaps combined
>       with some new explicit signaling to remove the multihoming state.
>       The coupling between the connection state and multihoming state in
>       the transport-layer approach might make it more expensive for the
>       attacker, since it needs to keep the connections open.  Is this
>       the case?

I think there's both a space (granularity) and time (lifetime)
component in the results of either legitimate or fraudulent
multihoming requests. Clearly there needs to be some limits
on the effect of the requests.

>    There is a potential chicken-and-egg problem here, because
>    potentially one would want to avoid doing work or creating state
>    until the peer has been verified, but verification will probably need
>    some state and some work to be done.

Stateless design in verification protocols is well known today,
so I don't think is much of an issue. Suggestion: Add "Avoiding
any work does not seem possible, but good protocol design can often
delay state creation until verification has been completed."


>       of the endpoints) and I think those would allow blocking as well.

Maybe s/I think//

>    Given that there isn't address privacy in site multihoming setups

- English is not my native language but I tend to
   replace "isn't"=>"is not" etc. (Multiple places
   and multiple cases with don't/can't etc.)

>    However, when a *host* is multi-homed to several ISP, e.g. through a

s/*host* is/host (not site) is directly/

>    Such an attack might be against the resources of a particular host
>    i.e., C in the example above, or it might be against the network
>    infrastructure towards a particular IP address prefix, by overloading
>    the routers or links even though there is no host at the address
>    being targeted.

Move this paragraph to the end of Section 4.3, otherwise the "there are
a few aspects" ... "the first is ..." are hard to understand when this
paragraph is in the middle.