draft-nordmark-multi6-threats-01.txt

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Some minor comments about the draft and an attempt to comment on some 
of the questions posed in the draft


Section 1 - Introduction

    "These attacks pose threats against confidentiality,
    integrity, and availability."

I guess that i could make sense to also include impersonation attacks 
(or the way you prefer to call them) in which the attacker pretneds to 
be one party of the communication, since they are also considered in 
the doc

later on it states that:

   "This document has been developed while considering multihoming
   solutions architected around a separation of network identity and
   network location."

I think that the threats are actually related to the fact that the the 
128 by string used by the routing system to forward the packet differs 
from the 128 bit string that the ULP sees as identifying the other end 
of the communication. It doesn't really have to be a split in the most 
strict sense (where an identifier cannot be a locator) and the threats 
are then also valid by solutions that use regular addresses both as 
locators and identifiers (as you mention later)

Section 2

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

Is there a "name" or an "identifier" missing after transport endpoint?, 
i mean would be that the transport endpoint name is a function....

Section 3.1. application assumptions.

I guess that another assumption made by the receiving end of a 
communication is that the initiator can be reached at the source 
address included in the initiating packet, since the responder will 
send reply packets to it. So i guess that some amount of trust is 
putted in the source address.

later on you ask:
  "[TBD: Does one-way authentication, without mutual authentication, 
add a
   different class of applications?]"

As i understand this section, the analysis is divided in two: first the 
initiator end and then the responding end.
The initiator, always care about the identity of the target, since it 
wants to communicate with a given node. So. in this part you discuss 
the possibility of using TLS to provide strong authentication of the 
target
Next you discuss the responder p.o.v. and you discuss different 
mechanisms that the responder can use to verify the initiator.

So my reading is that responder verification and initiator verification 
are independent from one another and that the one way authentication is 
already considered in the analysis. am i missing something?

Section 3.4 Flooding attacks today

   "And in the absence of ingress filtering an attacker can
   launch simpler DoS attacks by spoofing its source IP address."

I don't understand what do you mean here. If there is no ingress 
filtering this attack may allow an attacker to make a innocent server 
to attack a victim (and the attacker hasn't to generate the traffic 
required to do the flooding, so he can attack through a slow link, for 
instance). So i would say that if no ingress filtering this attack 
seems a good choice for an attacker which simpler attack am i missing?

Section 4. Potential new redirection attacks

   "This discussion is again
   framed in the context of independent host identifiers and topological
   locators."

Again, i think that the context for these attacks are that the 128 bit 
string used to route the packets _may_ differ from the one used by the 
ULP to identify the endpoints of the communication. It doesn't require 
that the namespaces are independent imho. NOID and MIP use locators as 
identifiers and introduce similar threats, i guess

Section 4.4.  Accepting Packets from Unknown Locators

I fail to see the threat presented in this section. I think it is a 
relevant issue to discuss whether a solution should or not accept 
packets from unverified source locators, but i don't see the threat of 
doing it. I do understand that threats apprear when sending traffic to 
an unverified locator, and i also see the threats that appear if when 
accepting an unverified locator, some action is taken, like changing 
the locator used to reach the other end, but if none of this happens, i 
don't see any threat here.

Section 5.  GRANULARITY OF REDIRECTION

      "Discussion: Perhaps the key issue is not about the granularity,
      but about the lifetime of the state that is created?"

imho is about the different scopes of the binding between the multiple 
locators and the identifier used
when a per connection solution is used, the scope of the binding 
information is limited to that particular connection, both in time and 
communication sense. This means that if the attacker manages to corrupt 
that binding information, the attack will only affect the scope of the 
binding. It will not affect future communication, but it won't neither 
affect simultaneous communication with the same peer (like for instance 
in the other direction)

So imho time frames is just one aspect of the problem, and granularity 
seems more general or scopes if you prefer


Appendix B

   "However, the mechanisms for addressing the latter issue can be quite
   different.  One way to prevent premeditated redirection is to simply
   not introduce a new identifier name space but instead rely on
   existing name space(s) as in [NOID]; in this case premeditated
   redirection is as easy or as hard as redirecting an IP address 
today."

I am not sure that i agree with this. imho NOID prevents identity 
hijacking because there is a trusted third party that informs about the 
acceptable locator set, and not because there is not a new id space.
For instance suppose that an attacker have managed to induce some fake 
noid state inside a host B , so that a given IP address IPA has an 
alternative locator IPX
Now suppose that the owner of IPA is host A who only has a single 
address IPA
The attacker periodically sends packets to Host B so that Host B 
preserves this fake state and also to maintain IPX as the preffered 
address to reach IPA

Now when Host B want to initiate a genuine communication with IPA, the 
noid mechanism within host B will redirect packets to IPX

(i don't know if the details of the attack are correct, and i am not 
trying to present an attack to noid)
I am just trying to present that in noid, the identity is represented 
by the IP addresses, and this identity can be hijacked as well. You 
don't need a separate id name space to hijcack an identity. (another 
example could be mip, where the identity is the HoA, and it can be 
hijacked as well)

So, summarizing, i agree with the conclusion, but not with the argument 
presented, imho NOID avoid the attacks because i relies on a trusted 
third party (i.e. the DNS) (which makes the situation similar to the 
current one)

later on, it is mentioned that:

   "In some cases it
   is also possible to avoid the problem by having (one end of the
   communication) use ephemeral identifiers as in [WIMP]."

Well, in wimp the responding end does have an identity (the hash of the 
FQDN) which can be hijacked, if the attacker manages to introduce some 
fake state binding this identity to a fake locator. IMHO wimp avoids 
this by using a trusted third party to create the initial state (the 
DNS as in noid)

I see three ways to prove the identity ownership:

- a trusted third party, which states that a given identity is 
reachable at a given set of locators, so the endpoint reached at one of 
this locators is the owner of the identity

- CBIDs as disused in the draft

- and a static binding, as currently defined in IP, where you trust 
that the routing system will deliver the packets to the owner of the 
locator, and since the locator and the identity are one, you prove 
identity ownership as a subproduct.

Later on, the analysis finishes with

   "Finally, preventing third party DoS attacks is conceptually simpler;
   it would suffice to somehow verify that the peer is indeed reachable
   at the new locator before sending a large number of packets to that
   locator."

I think that there are some attacks directed to the identity role and 
others directed to the locator role.
I see communication hijacking, like the threats presented in section 
4.1 as threats related to the identity role, where the attacker 
pretends to be victim and take his place. In this case, i think that 
basically the identity is stolen
OTOH, i see flooding attacks as attacks addressed to the locator role. 
The attacker pretends to own the victims locator (not the victims 
identity)

So in order to avoid the full set of threats, you need mechanisms to 
prove the identity ownership, and also the locator ownership, so you 
can avoid that an attacker steals any of them

As i mentioned above, i see these three ways of proving the identity 
ownership, but t prove locator ownership, i can only see two:

- trusted third party
- return routability

Regards, marcelo