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

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 8 Jun 2004 21:35:21 +0200

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2004 05:53:27 -0700 (PDT)

Thanks for the comments.

> be one party of the communication, since they are also considered in 

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?

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

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

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

> already considered in the analysis. am i missing something?

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

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

> identifiers and introduce similar threats, i guess

Good point. I'll reword it.

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

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

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

> noid state inside a host B , so that a given IP address IPA has an 

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

> this by using a trusted third party to create the initial state (the 

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

> identity ownership as a subproduct.

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

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

> ownership, but t prove locator ownership, i can only see two:

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 13 Jun 2004 18:17:47 +0200

Hi Erik,

sorry for the delay

El 10/06/2004, a las 14:53, Erik Nordmark escribió:

> that has no effect.

Well, if i think i am communicating with Santa and he makes some 
promises to me, i will believe them and expect some presents later

>  If they do believe that they are having confidential

But even if it is a non confidential communication, if i think that i 
am communicating with santa, but i am communicating with someone else, 
this is a problem

> But perhaps "authenticity" should be added to the above list?

I think so.

> about there being a new name space for identifiers.

I agree, and i know what you meant, only that sometimes i have the 
feeling that some folks don't consider mip or noid as a loc/od split 
type of solution while the threats apply to these type of solution too.

> separate identifier name space.

imho this would be better

> I'll put a "name" in there.

imho "name" is fine

> trust. Do you think I should add something about it?

No, no, this was just a comment about the issue being discussed

[...]
> Do you have suggestions on how to make this more clear?

Ok, it is clear to me now. The RST example was helpful for me, perhaps 
adding it may help others.

> the redirection to only one connection,

Well, imho, this section discusses more issues than this one.

In the first paragraph this point is discussed.
In the second and third paragraphs, another issue is discussed, related 
to the direction of the communication.

imho these are different issues.
For instance, you can think a solution where each connection is handled 
independently, and has its own security, So attackers have to redirect 
each connection independently, no matter the direction the connection 
is established. Examples of this are solutions that make TCP to support 
multiple addresses per connection.
Next, you have solutions that explicitly handle different directions of 
communication separately. This means that all incoming communications 
from a given endpoint share the same set of locators, and an attack 
will affect established and future incoming communication evenly. the 
same for outgoing communications. I guess that an example of this would 
be wimp. This makes sense, imho because as you mention in the draft, 
the initiator role and the responder role are different in terms of 
identity requirement. In many cases the identity of the initiator is 
not very important, the only relevant issue is that it remains the same 
that had initiated the communication. OTOH, the receiver identity is 
always important since the initiator wants to communicate with a 
certain host.

Finally, some solutions handle all the communications together, 
incoming and outgoing. Such solutions (like noid, sim) require heavier 
security features in all communications, since no matter whether the 
communication requires identity validation or not, this feature is 
provided

That is why i see that the issue to be about the scope of the binding 
information.
We need some security mechanisms to negotiate the binding between a set 
of locators and the identifier used by ULP
The point is the scope of this binding.
This binding can affect only a a given communication
this binding can affect all the incoming (or outgoing) communications
this binding can affect all the communications with a given endpoint.

As the binding affects more communications, the security required for 
the mechanism to set up the binding would be stronger, imho

> we would be making more work

Well, i guess you can see it this way.

The other way of seeing it is that as the the risk is higher, you need 
more security.
so, when only a single connection is at stake, you require less 
security than when all the communications, present and future, incoming 
and outgoing communications are at stake

> a door open that makes it easier for attackers to do premediated 

i think this is a good point.
When considering per connection solutions, the time is naturally 
limited to the lifetime of the connection. The problem is when you 
attempt to use the binding information for more than a single 
connection (or when the mechanism resides in a layer that has no 
knowledge of the connections) In this case, you need a garbage 
collection mechanisms, to delete the bindings that are no longer being 
used. As you mention, the presence of this information when it is no 
longer needed for the communication is a liability, and would make 
sense to delete asap
However, i am not sure this is strictly related to the point discussed 
above. Perhaps this is a general issue?

> attacks (assuming the solution has a robust way to pick a new ID when

Yes and the cool thing is that the node that has an ephemeral id does 
no need a stable one when he is acting as an initiator, so providing it 
to him would require additional security without any benefits (which 
doesn't seems a reasonable tradeoff :-)

> Agreed. And we also have the option to think about ephemeral IDs where 

But imho in the case of ephemeral ids, you are not really proving id 
ownership, because the identity is meaningless!
So you don't really have to prove id ownership because it is irrelevant
The important point in this scenario is that the the communication is 
always with the same endpoint.
In other words, the responding endpoint doesn't care who he is 
communicating with, as long as it remains being the same.
So, i am not sure that we can talk about identity ownership poof in 
this case...

> based proofs that the entity at that locator holds the private key.

Ok, i agree that i should be more precise about this point.
Perhaps the important issue in this case is that a given endpoint is 
authorized to use a given locator (i think G. Montenegro used this 
expression about locators a while ago)

So we need to provide identity ownership proofs and locator usage 
authorization proofs in order to make this work

So, assuming the above taxonomy of means to provide identity ownership 
proof, the mechanisms to provide locator usage authorization proof 
would be:

- return routability: i.e. if an endpoint is capable of receiving 
packets at a given locator, it is because he is authorized to do so
- third trusted party: a third party establishes that a given identity 
is authorized to use a given set of locators (for instance the DNS)

> comparing different possible approaches.

agree.

regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 13 Jun 2004 15:57:23 +0200

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

But doesn't one-way authentication without mutual authentication imply 
a different trust model? I.e one end chooses to not to authenticate 
while the other end does authenticate.

- - kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jun 2004 12:46:58 -0700 (PDT)

> while the other end does authenticate.

Yes, but the point was that the document already talks about this
by explicitly separating the client side from the server side considerations.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jun 2004 12:46:58 -0700 (PDT)

Erik

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 21 Jun 2004 09:42:55 +0200

> by explicitly separating the client side from the server side 

Yes. But I meant that there is a different trust model if one of the 
sides (where both have the ability to authenticate) decides not to 
authenticate.

- - kurtis -