Re: draft-nordmark-multi6-threats-01.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

Thanks for the comments.

> 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

I think such attacks are and end to accomplish threats against the above.
For instance, I might be successful in convincing somebody that I am
Santa Claus, but if they are not going to engage Santa in some way
that has no effect. If they do believe that they are having confidential
communication with Santa Claus but they are instead communicating
(with confidentiality) with me then there was an attack on confidentiality.
But perhaps "authenticity" should be added to the above list?

> 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)

Agreed. But I don't see anything in the quoted text that says something
about there being a new name space for identifiers.
So how would you propose to make that text more clear that a new
name space isn't assumed?

How about I make it say:
This document has been developed while considering multihoming solutions
architected around a separation of network identity and network location,
whether or not this separation implies the introduction of a new and
separate identifier name space.

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

Yes, it reads better with that added. I hope we don't have to
argue whether it should be "transport name" or "transport identifier".
I'll put a "name" in there.

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

Yes, but I think this assumption is more fundamental than being just about
trust. Do you think I should add something about it?

> 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?

Yes, you're right. Thanks for making that clear to me.

> 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?

Agree that the above sentence is out of place. What does fit for that
paragraph, which has "in the presence of ingress filtering" earlier,
is something like:
And in the absence of ingress filtering
an attacker would either need to be present on the path initially and then
move away, or the attacker would need to be able to perform the setup
of the communication "blind" i.e., without seeing the return traffic
(which in the case of TCP implies guessing the initial sequence number).

> 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

Good point. I'll reword it.

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

The key sentence is:  "In the current Internet, an attacker can't inject
packets  with arbitrary  source addresses into a session if there is ingress
filtering present," The threat in general is accepting packets (such as TCP
RST packets) which can cause DoS and/or corruption of the application data
stream. When there is no ingress filtering in the network, this is something
that the endpoints need to sort out themselves. However, deploying
ingress filtering (or source address filtering in general)
helps in today's Internet.
This section tries to state the concerns that perhaps we want ingress filtering
to help even when a multihoming solution is deployed.

Do you have suggestions on how to make this more clear?


> 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

Yes, but this section, which is subject to discussion and by no means is
finished, tries to point out that by making the scope smaller by applying
the redirection to only one connection, we would be making more work
for the legitimate applications (such as short-lived http connections)
as well as attackers, and the ratio by which we make things harder seems to
be the same for the legitimate guys and the attackers.
That doesn't seem like a good approach to improving security. For security
you want things (like keys on the front door of a house) that are
a little bit inconvinient for the legimate parties, but make it significantly
harder for an attacker.

The "time" aspect of the scope seems to be closer to this; leaving 
any multihoming state around after it is no longer used by the ULP
might not provide much benefits for the legimate users but leaves
a door open that makes it easier for attackers to do premediated attacks.

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

You're right. It is the re-use of the existing name space *and* presumed 
security mechanisms associated with the looking up of objects in that
name space that is important.

> 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

And it can do this, in the case of NOID, by attacking the DNS.


> 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)

Yes, for the responding end.
The interesting thing I tried to bring out is that for the
end that has the ephemeral ID, you can skirt around the premediated
attacks (assuming the solution has a robust way to pick a new ID when
one is in use/stolen).

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

Agreed. And we also have the option to think about ephemeral IDs where they 
make sense.

> 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

I think proving locator ownership (e.g. by verifying using DNSsec through
ip6.arpa that the locator has indeed been assigned to the node in
question) is one way to prevent 3rd party DoS. But it might be stronger than
we need. Another approach is just to have the peer identity show that it
is present at the claimed locator, which is weaker (and how weak
depends on how the details of the mechanism by which it would show this).
My point is that the latter approach doesn't talk about locator ownership
at all.

> 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

I think you are overextending the "ownership" term when you apply
it to return routability; I think this is more about "presence"
at the locator. And there can be very different strength proofs of
presence, from just responding "yes, it's me" to having CGA/CBID
based proofs that the entity at that locator holds the private key.

But it is very good that we are starting to discuss the initial attempt
to capture these aspects in the appendix; understanding this helps
comparing different possible approaches.

   Erik