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