On 3 Aug 2009, at 05:59, Xu Xiaohu wrote:
Hi Ran,
At the suggestion of one of the RRG Chairs, kindly let me
reiterate the explanations on this topic, with specific
reference to the slides presented at RRG in Stockholm today.
Looking specifically at Slide 22:
1) Off-path Attacks
Ordinary IPv6 without IPsec has broad vulnerability to
on-path attacks,
as noted in Slide 22, round bullet 2, triangle sub-bullet 2, first
dash sub-sub-bullet.
This means that to provide equivalent security ILNP without IPsec
only needs to protect against off-path attacks.
ILNP includes a Nonce to protect traffic from off-path attacks,
as described in Slide 22, 2nd round bullet (and its
subsidiary items).
This means that ILNP without IPsec has the same security
properties
as IPv6 without IPsec. This is also described in draft-rja-ilnp-
nonce-*
and in the other draft-rja-ilnp-* drafts -- in more
detail than fits
on 1 slide in a ~30 minute overview talk. This is also described
in the 2nd circular bullet on Slide 22.
Sorry, I just read your ilnp-nonce draft. I felt that without the
HIP/CGA
tricks, this nonce mechanism itself only solves the session hijacking
problem, and it doesn't prevent stealing and spoofing of the
identifiers.
For example, an attacker could use somebody else's identifier to
initiate
communication with a given correspondent node.
It is not possible for an off-path attacker to do what you suggest
when ILNP is in use. There is enough information available on both
ends of an ILNP session to distinguish between two different nodes
that have accidentally used the same Node Identifier.
Without repeating another paper at great length in this email,
here is a starting point to understanding:
1) Recall that all ILNP sessions will include a
Nonce Destination Option sent from the initiator node
to the responder node (and subsequently a Nonce
sent from the responder to the initiator).
2) Nonces are unidirectional, so different nonce values
will be used (X->Y) and (Y->X).
Let:
A, B are different initiator nodes using the same
Node ID value.
C is a responder node communicating with A, B
Observe:
1) A and B will each select large (e.g. 96-bit) Nonce
values independently. If the operational risk is
lower, a smaller Nonce value could be selected instead.
2) The probability of selecting the same Nonce value is now
1 out of 2^^96 -- this is a lower probability than selecting
the same inputs for generating a common CGA value. However,
unlike the CGA, neither initiator nor responder need to
perform any significant computation -- so no new DOS attack
window is created by using the Nonce mechanism.
3) Since A and B are using different Nonce values, C is
perfectly capable of distinguishing between A and B.
4) As is already the case today with IPv6, it is not valid
to have 2 unrelated nodes on the same subnet use the
same Identifier (IID in the case of IPv6) value at the
same time. (I say "unrelated nodes" here to distinguish
crisply from some kind of "distributed system" where 2
or more boxes form a single logical computing system.)
Note 1: The same kind of analysis can be done to show that this
works generally, even if A, B are responders and C is
an initiator. The details are omitted here because this
is already a long email.
Note 2: None of the above mechanisms or analysis involve either
cryptography or any other expensive mathematical operation.
(If it is still confusing, I'd urge re-reading the published
ILNP papers and also the ILNP Internet-Drafts to gain more
clarity on this.)
Finally, if some folks want to use CGAs, that is fine. ILNP permits
the existing CGA specifications to be used without any modification.
Again, we've shown that ILNP has security properties no worse than IPv6.
1) Based on the assumption that the identifier is not globally
unique, if
two hosts using the same identifier initiate communication with a
third
host, how could this third host distinguish the different sessions
from
these two hosts?
Please see above. There is sufficient other information to distinguish
the sessions from each other. This is discussed in more depth in
other published drafts/documents.
2) Based on the assumption that the idenfiters are only needed to be
unique
within the context of a given Locator, if a mobile node moved to a new
subnet, and unfortunately there is a host within this subnet which
uses the
same identifier as the mobile node, should be mobile node renumber its
identifier?
If the node wanted to change its Identifier, it could do so without
losing
any existing sessions.
However, kindly recall IPv6. The IPv6 rules say that a given IID
must be unique within the context of a specific /64 routing prefix.
The ILNP rule is not more strict than the IPv6 rule. So again,
ILNP does not fail to support any case that works today with IPv6.
In normal operation, the ILNP Identifier would probably be an EUI-64
with the scope bit set to "global" and would be formed by using some
EUI-48 or EUI-64 already associated with the node. Recall this also
is entirely consistent with IPv6 practices on forming an IID. In
this case, the IEEE allocation rules combined with the EUI-64
formation rules ensure that the scenario you describe will not occur.
In some different case where an ILNP Identifier is being formed in
some other way (e.g. some pseudo-anonymous ID algorithm), then as
with IPv6 some form of DAD would be required because the scope bit
is set to "local". ILNP never requires that a node use this form
of Identifier, although a node might choose to do so if it wishes.
So one can again see that ILNP is imposing no new constraints beyond
those imposed by IPv6 at present, and that deployments that work
today with IPv6 would also seamlessly work with ILNP.
Of course, ILNP provides various benefits (described throughout
the talk and the various drafts/documents) that IPv6 does not provide.
So there is a net benefit to migrating to ILNP from ordinary IPv6.
3) If I understand your ILNP correctly, the DNS server will be used
as the
rendezvous to deal with the simultaneous mobility issue. In pratice,
multiple hosts could share a FQDN for load-balancing purpose, that's
to say,
the mapping between FQDN and I/L is 1:N, not 1:1, how could the
mobile node
know which I/L is corresponding to the communicating node? Or do you
believe
the DNS should be changed so that each host will have a globally
unique FQDN
in your ILNP architecture?
In the scenario you describe, existing deployments of that kind
share session state among the N physical boxes that are clustered
to emulate a single node.
That is, the case you describe is not really a case of N separate nodes,
but instead it is the case of a single distributed system that happens
to be built out of a number of boxes. This sort of clustering has been
commonplace for decades. (I think I first encountered it with a DEC
VAX/VMS cluster. One imagines modern systems are most commonly built
out of some flavour(s) of UNIX.)
Moreover, in such cases in the real-world today, multiple "back end"
servers are fronted by some commercial load-balancing appliance. Those
appliances ensure that requests are handled consistently by the server
cluster. Various session management mechanisms have been built by
various commercial vendors, but they all have the same apparent
external behaviour (i.e. from the perspective of the client system).
No DNS changes are needed for ILNP, other than adding the I and L
records.
Optionally, also adding the LP record optimises DNS performance and
scalability for mobile network cases or for site multi-homing cases.
Yours,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
