Short version: Toni hasn't yet described a secure method by which
one node can tell another it has a new Locator.
I can't imagine how this proposal, or any other CEE
(Loc/ID Separation) architecture, such as ILNP,
could handle mobility with sufficiently short
delays and sufficiently light-weight protocols
to make it practical or attractive for VoIP.
If a scalable routing proposal can't do mobility
with delays short enough to not disrupt conversations
with VoIP, then I think it is a non-starter. So far
I think TTR Mobility is the only approach to mobility
which can do this - and it is only for CES
architectures such as LISP, Ivip and perhaps IRON.
Hi Toni,
Thanks for your reply. You wrote:
>>> A look-up needs to be done once per stateful session.
>>> Thereafter nodes inform each other of any locator changes.
>>
>> But what if both change their locators at the same time?
>
> This would be a breakdown and a session re-establishment process
> would be conducted. At least one of the sides, when realizing what
> would have happened, would make an inicast to restore the session.
This condition could only be detected by upper layers. So the
application, or TCP, would need to time out due to lack of response
from the other node, since the packets the application sends are
going to the old Locator, not the new one. Then you could restart
the "inicast" process, and I guess continue the session based on the
original Identifiers with the new Locators. However, this would be a
serious disruption to service, since it would take 5 or 10 seconds
for the application to time out. If you let it time out any sooner,
then you could be restarting the "inicast" process every time there
is a brief outage or a few dropped packets.
The same thing would happen if B changes its Locator and sends a
message to A about this, but the message is dropped and does not
arrive at A. A's applications would time out due to not getting any
responses from B (A would be sending packets to B's old Locator
address), and then you would restart the "inicast" system. To get
around this, you would need to have A acknowledge B's message, so B
could resend until it got an ack. However, that would make the
process of gaining a new Locator far more expensive.
With mobility, the device might gain a new Locator and lose the old
one very rapidly and arbitrarily - without user action. If B is
communicating with 50 other nodes, then this means 50 outgoing
messages and receiving 50 acks.
Please compare this with the TTR approach to mobility, in which a new
(Locator) IP address just involves the mobile node establishing a new
tunnel with its (typically) one TTR (Translating Tunnel Router):
http://www.firstpr.com.au/ip/ivip/#mobile
All other approaches to mobility I know of have the same problem as
just described - all CEE (Loc/ID Separation) architectures, and LISP
Mobile.
With TTR Mobility, the mobile node can have multiple IP addresses
from various access networks, and create a tunnel from each to the
current TTR. So it can establish a new tunnel from a new access
network before it loses its address in a previous access network.
Since the TTR is typically nearby, this tunnel establishment process
can occur in a few milliseconds, and so, I think, be suitable for VoIP.
Any CEE mobility system will involve delays telling all the
correspondent nodes about the new Locator. Since the correspondent
nodes could be anywhere in the world, and since the mobile node needs
to send out messages, and get acks, for each one, this is never going
to be practical, or be fast enough to support VoIP.
>> How can one node be sure a message supposedly from the other
>> node, regarding the other node's new locator, is authentic?
>
> First, by looking at the other node's identifier.
This doesn't achieve any security.
> Second, by sending a further message and receiving a reply.
Nor does this.
Let's say A and B have established a session. X wants to impersonate
B. X gets A's Identifier and Locator, either directly by setting up
a session with B, or by having another node Y do so.
Then X sends a message to A with B's Identifier and current Locator,
telling A that it has a new Locator.
With what you have proposed so far, there is no security whatsoever,
and A would accept the message and send all the packets it intends
for B to X instead.
> Third, if needed, by doing inicast.
Sure, you could restart the expensive session establishment process
every time either node changes its Locator. However, this is
unacceptable in terms of cost - especially for mobility - and it
presents a completely unacceptable DoS vulnerability.
Let's say X wants to cause havoc for B and all the nodes it is
communicating with. If it somehow knows the Identifiers and Locators
of these nodes, or has an inexpensive way of finding some such nodes,
it sends an unsecured message to each such node, purportedly from B,
that B has a new Locator and that the node should restart the
"inicast" process before sending any further packets.
This would tie up B and its targeted correspondent nodes with
"inicast" operations and the delays would disrupt traffic.
You have not yet proposed a secure method by which one node can tell
another that it has a new locator. I think the best way to do it is
for each session to involve each node sending a nonce to the other,
and using this nonce to secure messages in the future regarding
change of Locator. This adds to the complexity of the "inicast"
protocol and to the state stored by each node. For instance, for B
to send A its nonce, it can do it in two ways:
1 - B send the nonce, perhaps as part of its first reply packet to
A. Then B waits for an acknowledgement that this nonce has
been received - which is probably best done by A sending
another packet with that nonce, or with a hash of it, to B.
This too could be piggybacked onto a traffic packet.
2 - Keep sending the nonce for some number of packets, and assume
that A will get it. If A doesn't, then it won't be able to
continue the session and will have to restart the "inicast"
process.
Note how this makes packets longer than at present - and/or requires
more packets being sent. With the current system (IP address
performing both Identifier and Locator functions) there's no need for
this stuff. The current system works fine for a unidirectional
and/or single packet communication, without any overhead. Yet for
what you are describing, or for any other CEE (Loc/ID Separation)
approach, both hosts need to send and receive packets with the other
host before a single two-way application packet exchange can be
completed.
>>>> Then, for your concrete example, why do you argue that hosts
>>>> should do this extra work, rather than new elements in the
>>>> routing system such as ITRs, as in LISP, Ivip or (by some
>>>> other name) IRON?
>>>
>>> No extra work. Nodes will use locators for packet outreach and
>>> IDs for session maintenance.
>>
>> There certainly is extra work. Initially the sending host A
>> only knows B's Identifier, and it somehow uses this with the
>> number servers to get a packet to B. I am not sure how A finds
>> out B's locator, but it needs to find this out ASAP so it can
>> send subsequent packets directly to B, without relying on any
>> other servers.
>
> When A's inicast packet reaches B, B replies with its locator
> directly to A. Thus, both sides get to know their ID & Loc tuples.
This is assuming the "inicast" system can be trusted to send the
initial packet from A really to B, and to no other node which does
not have B's Identity.
But then, B needs a nonce from A to secure the B->A reply packet,
otherwise X could guess that A was sending packets to B, and send A
packets which appear to A to be replies from B. Assuming X's packet
is accepted by A, then A will send packets to X, whenever it wants to
send packets to B.
>> There are extra delays in using these number servers.
>
> Just like doing any other resolution.
No.
In today's system, if A has B's IP address, the two-way communication
proceeds without any delays, extra packets or extra state at all.
If A has to do a DNS lookup on B, then that is a DNS delay for A.
Then B can reply straight to A, using A's IP address found in the
source field of the initial packet. It doesn't know for sure that
the initial packet came from A, but it does know that the routing
system will send the reply packet to A, or drop it. So there is no
need for B to do any kind of DNS lookup or any other delay-inducing
process to respond to a new session from A. It can send user
information in the reply packet, because it know that the packet will
never be sent to a host other than A, even if the packet which
appeared to be from A was sent by an attacker.
Therefore, in the current system, without any extra overhead or
delays, B can respond to a packet which has A's IP address in the
source field, with information it intends to get to A, without any
possibility that the information would arrive at a host other than A.
To ensure this with CEE involves the "inicast" - or whatever the
system is for secure Identifier to Locator lookups - by both hosts.
Since ILNP is supposed to support existing application protocols, it
needs to do these two lookups, in order that the application (which
may assume current network behaviour) will be assured that a reply to
A (in the above example) really goes to the node whose Identity is A
(unless it is dropped), and cannot go to any other node.
In your proposal, you have new application protocols, so perhaps you
don't always need to do both lookups, since the application won't be
making the same assumption. But then, you need to have the logic of
many applications rewritten, with new protocols - not just keep the
current application protocol with a new interface to the IP stack.
I can't imagine any higher barrier to widespread adoption than the
need to rewrite application programs - especially if it involves
altering the actual protocol used by the application.
> But in the meantime the
> inital packet is on its way. And when the process of resolving
> completes the packet will likely be closer to its destination.
> This moment is when the directly tending ID server gets the
> packet.
I don't clearly understand you "inicast" system, but it will involve
delays and potentially long paths. Your system needs to do this in
both directions A->B and A<-B.
>> When B gets a packet from A, it will have A's Identifier and it
>> may have A's Locator - but there's no way B can trust this
>> Locator. So it needs to do a lookup, or whatever it is you
>> described with number servers, to send a packet to A, rather
>> than to some other host which pretends to be A.
>
> No lookup is required. B would send a further handshake reply to
> A. A's reply would be the proof.
This is no proof at all. X could have sent the packet to B, claiming
to be A (having A's Identifier) but using X's Locator. With your
current proposal, B would reply to X, thinking it was replying to A.
Then when it gets a response from what it thinks is A, it would have
no way of knowing it was really sending packets to X, not A.
B shouldn't send back anything to A unless it has reliably and
independently determined A's Locator, using your "inicast" system -
which is presumably reliable and 100% secure.
So there are delays and extra work for both nodes at the start of a
session.
>>> The routing system will consist of path selection facilities
>>> that make use of locators. The node ID system will consist of
>>> ID distribution/matching servers.
>> I am sure you could write this up in a way others could
>> understand, but it will take a few pages and probably require
>> some diagrams.
>
> That would be nice of me. I hope the interest grows.
>
> To be continued.
I suggest you first write up what your goals are, and why you believe
it is necessary and desirable to burden all nodes with extra work in
order to do what CES systems (LISP, Ivip and IRON) do in the network,
without any extra work by nodes. Depending on how the mapping system
works, there may be some delays, but there is no extra node effort,
longer packets, state in the nodes etc.
Ivip uses Distributed Real Time Mapping, which will generally involve
very short initial packet delays - too short, I believe, to have a
significant impact on any application protocol or any human
perception of responsiveness. The DRTM documentation is:
1 - http://www.firstpr.com.au/ip/ivip/drtm/ (Color diagrams.)
2 - http://tools.ietf.org/html/draft-whittle-ivip-drtm
3 - http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html
(Please read only the section on "DNS-based system so TRs can
find DITR-Site-QSDs.)
I think you need to show how "inicast" is secure and establish a
system to secure Locator change messages.
Then I think you need to show how it is scalable, efficient, secure
and fast to do Locator change messages for mobility. As far as I
know, you can't do this with any CEE (Loc/ID Separation)
architecture, for reasons discussed above and in my previous message.
I think it is pointless developing a scalable routing system which
doesn't provide global mobility. As far as I know, the only approach
to mobility which will work is TTR Mobility. This could be used by
LISP as well as Ivip. I haven't read the latest IRON material so I
am not sure what Fred's Mobility plans are.
TTR Mobility is for CES architectures - not for a CEE proposal such
as yours.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
