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

"Randall R. Stewart (home)" <randall@stewart.chicago.il.us> Mon, 15 September 2003 18:56 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19285 for <ipv6-archive@odin.ietf.org>; Mon, 15 Sep 2003 14:56:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyVm-0006CJ-1B for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 14:55:46 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FItj9A023817 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 14:55:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyVl-0006C0-H8 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 14:55:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19225 for <ipv6-web-archive@ietf.org>; Mon, 15 Sep 2003 14:55:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyVi-0004Pr-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 14:55:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yyVi-0004Po-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 14:55:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyV6-0005uU-Ow; Mon, 15 Sep 2003 14:55:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyUr-0005tw-Om for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 14:54:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19149; Mon, 15 Sep 2003 14:54:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyUo-0004Nw-00; Mon, 15 Sep 2003 14:54:46 -0400
Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19yyUo-0004Ne-00; Mon, 15 Sep 2003 14:54:46 -0400
Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h8FIs63D055919; Mon, 15 Sep 2003 13:54:13 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us)
Message-ID: <3F660ACD.90603@stewart.chicago.il.us>
Date: Mon, 15 Sep 2003 13:54:05 -0500
From: "Randall R. Stewart (home)" <randall@stewart.chicago.il.us>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: ietf@ietf.org, ipv6@ietf.org
Subject: Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...)
References: <3F6239E0.8090001@stewart.chicago.il.us> <01df01c36a7b$840dbb80$63124104@eagleswings> <3F61EAC2.7020304@stewart.chicago.il.us> <20030912165739.50b3866b.moore@cs.utk.edu> <3F6239E0.8090001@stewart.chicago.il.us> <5.2.0.9.2.20030913095009.0301ea40@pop.mcilink.com> <3F6373FD.1020308@stewart.chicago.il.us> <3F65FA9E.2010801@nomadiclab.com>
In-Reply-To: <3F65FA9E.2010801@nomadiclab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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
--------------------------------------------------------------------