vinton g. cerf wrote:Pekka:
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
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
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 randall@stewart.chicago.il.us 815-342-5222 (cell phone)