Subject: Re: Solving the right problems ...

From: Keith Moore <[email-masked]>
Date: Fri, 12 Sep 2003 16:57:39 -0400

> Tony Hain wrote:
> 
> >In the ongoing saga about topology reality vs. application perception of
> >stability, it occurs to me we are not working on the right problem. In
> >short we have established a sacred invariant in the application / transport
> >interface, and the demands on either side of that interface are the root of
> >conflict.
> >
> >Mobile IP, and the multi6 DHT work are attempts to mitigate it through
> >slight of hand at the IP layer, while SCTP attempts to mask the topology
> >reality in the transport layer. (These are probably not the only examples,
> >but they are the ones that come to mind this morning.) Yet none of these
> >really do the job in all cases.
> >
> 
> SCTP seems to me to do most of what you propose in this "layer"... assuming
> an SCTP that includes the ADD-IP extension I can (and I have done this
> with the KAME stack)

[...]

Yes, SCTP does *most* of this.  It can handle the case where one party of a
connection moves, and it is able to tell its peer that it has moved.  IIRC, it
doesn't handle concurrent moving of both connection endpoints (even if both
endpoints are in the same network), nor does it handle cases where timely
notice cannot be provided.  Nor does it handle rendezvous or referral because
in those cases there's not a constantly-open connection over which to signal
locator changes.  So I don't view the SCTP approach as a complete solution,
but it might be useful as part of a solution.

Also, I'm not insisting on a separate layer.  As far as I can tell, some of
the changes needed could take the form of backward-compatible modifications to
TCP and UDP and perhaps SCTP also, and I certainly think it's worth
considering those techniques.  Whether this is best handled by changes to
layer 4 (and perhaps layer 3 also if we need support from the routers), or a
new layer between 3 and 4, is not something I claim to have analyzed in
detail.

(OTOH, I am insisting that it's not reasonable to try to solve the entire
problem above layer 4.  For different reasons - mostly economic - I suspect
it's not reasonable to try to solve the entire problem below layer 4 either,
but I'm less sure of this.)

> We could do has Keith has proposed.. put it at a layer BELOW the 
> transport. Now, what do we end up with?
> 
> 1) A NAT like thing that is playing games with the IP addresses and 
> checksums (aka the psuedo-header)
> <or>
> 2) Putting a psuedo IP address (the identifier) on the machine for the 
> app to use apart and
>     seperate from the real physical IP address in use.

I don't think the two are inherently that different.  Say you define a new
identifier that can be associated with a connection endpoint, and you build a
mechanism that allows a host to map that identifier to one or more locators. 
Now you can tweak TCP to allow it to define either or both of its connection
endpoints (what is now the pseudo-header) in terms of those identifiers rather
than in terms of the locators currently in use, and you tweak the demux layer
on hosts that support this extension so that it can accept multiple
source,destination locator pairs and map each of them into the same TCP
channel that is defined in terms of endpoint identifiers.  Then you define
ways of doing signalling via TCP options so that the hosts can learn about new
locators and deprecated locators for their peers.  I see this as a
variant of your #2, but it also has a vague resemblance to NAT.  

However, I don't think this has any of the problems of NAT.  Essentially what
it would accomplish is to cleanly separate connection endpoint identifiers
from locators, which people have been saying was a good idea for a long time. 
And I think it could be done in such a way that it is fairly compatible with
existing apps that use TCP. 

Keith

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Sep 2003 20:45:02 +0300

vinton g. cerf wrote:
>> We would also want to look very carefully at the potential spoofing 
>> opportunity that rebinding would likely introduce.

Randall R. Stewart (home) wrote:
> This is one of the reasons the authors of ADD-IP have NOT pushed to get 
> it done.. some more
> work needs to be done on this area...

http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt
is a background document, produced by the MIPv6 route optimization
security design team, that tries to explain the security desing
in MIPv6 RO.  I think that most of the threats and much of the solution
model would most probably apply also to SCTP ADD-IP and, of course,
also other multi-address multi-homing solutions.

--Pekka Nikander

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Mon, 15 Sep 2003 13:54:05 -0500

Pekka Nikander wrote:

>> This is one of the reasons the authors of ADD-IP have NOT pushed to 
>> get it done.. some more
Pekka:

Interesting reading.. I had heard of the RR check from someone but had
not researched it in detail.. nice document :>

Now as to the applicability in SCTP and ADD-IP...

There is a difference with mobile-ip in that an SCTP association is already
established. Each node CN and MN have "connection" state. There has
been a 64bit random value exchanged and the "ADD-IP" which is equivialant
of the "BU" can be verified with this random state that the ends are
maintaining. The real issue shows up in that if you are worried about
an ease-dropper that can "see" the initial INIT/INIT-ACK exchange
between the two peers. In that case it would then have the 64bits of 
randomness
and could "inject" the false ADD/DEL that would hi-jack the association. Of
course it could do other things too like knock down your assocation as well
by sending a false ABORT chunk....

It is good to see that the routing infrastructure is believed to be 
non-compromised
in MIP case. If we can make the same assumption then with one minor
tweak we can add a mechanism to SCTP to authenticate the ADD-IP with
private-public key pairs shared in the INIT/INIT-ACK. The obvious
problem with this would be if the infrastructure was compromised and you
had a true man in the middle who could intercept the INIT/INIT-ACK 
packets and
change the keys... but that goes away if we make the same assumption MIP 
did :>

Michael Tuexen and I were working on a seperate draft for this.. and 
were also
somewhat concerned about the compromised routing structure too. If we don't
have to worry about that our job just got easier :>

Thanks

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Sep 2003 22:18:23 +0300

> by sending a false ABORT chunk....

Yes. Unless you are encrypting the whole session, on-path attackers can
already do almost anything. They can start a session for you. They can
abort a session for you. They can hijack a session from you. They can
modify a session.

> change the keys... but that goes away if we make the same assumption MIP 

The question you have to ask is: What is the difference between the
"Internet as is" and "Internet with ADD-IP (or MIP)". You can do the
analysis case by case, such as for plaintext communications and
for cryptographically protected communications and with or without
the compromised infrastructure. For instance, assuming plaintext
SCTP packets, presumably in the current Internet all on-path attackers
will be able launch the attacks I listed above. But I hope that
not everyone in the whole Internet will be able to e.g. disconnect SCTP
sessions from a given host. The same properties should stay if you
add a feature such as ADD-IP. On the other hand, if we assume that
the routing infrastructure is compromised, then even in the current
Internet I can go and intercept your plain sessions and cause all kinds
of interesting problems. I would allow this to happen even with ADD-IP,
as long as it does not make the problem worse.

With cryptographic protection (e.g. IPsec) on the SCTP packets,
you should be safe even from on-path attackers. Again, if you add
ADD-IP feature the same property should stay. Note that there are
some DoS attacks that remain regardless of cryptographic protection.
For instance, by interfering with ARP/ND you could block the flow
of packets.

--Jari