RE: [Mipshop] Re: How probable is compromise of an AR? (was: Re: SEND-based protection and related confusions )

"Wassim Haddad \(KI/EAB\)" <wassim.haddad@ericsson.com> Sun, 20 August 2006 17:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqom-0000Tw-No; Sun, 20 Aug 2006 13:10:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqom-0000Tr-6I for mipshop@ietf.org; Sun, 20 Aug 2006 13:10:36 -0400
Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEqok-0002yT-SI for mipshop@ietf.org; Sun, 20 Aug 2006 13:10:36 -0400
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k7KHPkBY018434; Sun, 20 Aug 2006 12:25:46 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 12:10:26 -0500
Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 12:10:26 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mipshop] Re: How probable is compromise of an AR? (was: Re: SEND-based protection and related confusions )
Date: Sun, 20 Aug 2006 13:09:55 -0400
Message-ID: <95D8C1105D54EB41864F8831E6C4EB75AB46DE@ecamlmw720.eamcs.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mipshop] Re: How probable is compromise of an AR? (was: Re: SEND-based protection and related confusions )
Thread-Index: AcbDrB5SowHyOuk7QleSuhk/ldeUQQAz1bI0
References: <C24CB51D5AA800449982D9BCB903251311A7FD@NAEX13.na.qualcomm.com><Pine.LNX.4.58.0608171015560.28321@rhea.tcs.hut.fi><009d01c6c21c$191817c0$5e6015ac@dcml.docomolabsusa.com><7.0.1.0.2.20060817094613.05bbf500@qualcomm.com><015101c6c234$bbbb73b0$5e6015ac@dcml.docomolabsusa.com><7.0.1.0.2.20060818040806.04c8abe8@qualcomm.com><02d001c6c2e7$59dac020$5e6015ac@dcml.docomolabsusa.com> <7.0.1.0.2.20060819033949.078e2330@qualcomm.com>
From: "Wassim Haddad (KI/EAB)" <wassim.haddad@ericsson.com>
To: Lakshminath Dondeti <ldondeti@qualcomm.com>, James Kempf <kempf@docomolabs-usa.com>, Wassim Haddad <whaddad@tcs.hut.fi>, "Narayanan, Vidya" <vidyan@qualcomm.com>
X-OriginalArrivalTime: 20 Aug 2006 17:10:26.0155 (UTC) FILETIME=[879813B0:01C6C47B]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: Jari Arkko <jari.arkko@kolumbus.fi>, mipshop@ietf.org
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Errors-To: mipshop-bounces@ietf.org

Lakshminath,

 
>After having read the latest in this thread, let me summarize my take 
>on this to avoid misunderstandings.
>
>First, if an entity that is party to a protocol is compromised, we 
>have a difficult problem to solve.  (James, you seem to be thinking 
>this is the problem we are talking about, but that's not so; please 
>read on).  

=> This is your own summary of your own comments. RFC 4140 does not 
mention anything in the security considerations about node compromise 
nor if the related problem is easy or difficult nor if it needs to be 
solved or not.

In *summary* to your summary, your comments are misleading.

>We then go on to think about the impact of AR compromise; 
>for instance, would it possible that compromise of an AR might impact 
>MNs that are not using that AR?  If so, we should try and mitigate that, etc.

=> First, you should back your comments with clear ways to mount such 
attack (other than physical compromise). I can also think about many 
ways to compromise the MAP which is much more interesting for an attacker 
(using means equal to physical compromise) than compromosing an AR during 
one particular interval of time in order to attack the draft that you are 
trying to attack. 

FYI, the operators infrastructures are not open for visitors nor tourists.
(I've personally been involved in deployment in a third world country and
saw how much securing the nodes themselves is critical). 


>However, we are not talking about that here.  HMIP BUs go from the MN 
>to the MAP.  An AR is not a party to this communication 
>(sending/receiving BUs/BAcks).  

=> and in the draft he is not involved in sending/receiving the BU/BA other
than routing.

>I'd then apply the "Internet threat" model to the path in between the MN 
>and the MAP.  

=> The threat analyze for HMIPv6 is well described in RFC4140 and it did
not mention an AR compromise. I think you should ask the authors why such
threat has not been mentioned especially that the AR in HMIPv6 intervenes 
in delivering MAP(s) information to the MNs.


>As long as there is a path between the MN and the MAP, HMIP should work.

=> sure. Add to this: "with only one AR working in the whole MAP domain"... 
which of course makes mobility even more attractive! :)
  

Wassim H.

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop