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 --------------------------------------------------------------------
- Re: Solving the right problems ... Keith Moore
- Spoofing and SCTP ADD-IP (was Re: Solving the rig… Pekka Nikander
- Re: Spoofing and SCTP ADD-IP (was Re: Solving the… Randall R. Stewart (home)
- Re: Spoofing and SCTP ADD-IP (was Re: Solving the… Jari Arkko