[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems...)



Pekka Nikander wrote:

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



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------