[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pls review documents on IESG agenda

Wijnen, Bert (Bert) wrote:

Documents that may need specific attention from AA docutors:

draft-arkko-pppext-eap-aka-13.txt (Informational) 

This document looked very good to me ;-)

But in the interest of reviewing someone else's document
too, I looked at

o draft-ietf-multi6-multihoming-threats-02.txt
Threats relating to IPv6 multihoming solutions (Informational) - 2 of 3 Token: David Kessens 

There aren't any AAA issues around this document. Other
comments:

Overall:

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.

Substantial:

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
mechanisms/

   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."

Editorial:

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.

--Jari