Subject: RE: [Mobike] New issue 18: Threat discussion

From: <[email-masked]>
Date: Thu, 2 Sep 2004 14:54:14 -0400

Actually, let me rephrase:

I do not want to imply that "transient pseudo-NAT" attack has no 
relevance for MOBIKE. MOBIKE is all about authenticated management
of (change of) address. And "pseudo-NAT" is about malicious change
of address. 

So there is definite relevance there.

The issue is that problem can be manifested in several scenarios 
other than just IKE. It may make sense to either do a general solution
(else where?) or if we do MOBIKE-specific solution, we should let
other affected working groups be made aware of it.

Atul

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of ext 
> Sent: Thursday, September 02, 2004 2:24 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Mobike] New issue 18: Threat discussion
> 
> 
> 
> Hi Pasi,
> 
> Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack?
> The problem is of general nature, and will impact IP, IPsec traffic
> as much as (MOB)IKE traffic. 
> 
> Any solution to this attack has to be of general nature rather than
> MOBIKE-specific solution just working for MOBIKE.
> 
> Just trying to understand....
> 
> Best,
> Atul
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On
> > Behalf Of ext 
> > Sent: Tuesday, August 24, 2004 11:30 AM
> > To: [email-masked]
> > Subject: [Mobike] New issue 18: Threat discussion
> > 
> > 
> > At the San Diego meeting I promised to create a new issue
> > about the various threats the protocol should consider.
> > 
> > So far, we have at least the following (notation: the IKE
> > peers are A and B; C is an innocent victim).
> > 
> >   1) Unauthenticated attacker directs the traffic stream
> >      from B to a third party C, with the intent flooding C
> >      with unwanted traffic.
> > 
> >   2) Authenticated peer A directs the traffic stream from B
> >      to a third party C, with the intent of flooding C with
> >      unwanted traffic.
> > 
> >   3) Unauthenticated attacker directs the traffic stream
> >      from B to somewhere (perhaps to the attacker or /dev/null), 
> >      with the intent of preventing the legitimate peers from 
> >      communicating.
> > 
> >   4) Unauthenticated attacker causes the IKE_SA to be
> >      closed by modifying just one or two IKE packets (if
> >      attacker can modify all packets, he can of course DoS).
> > 
> > Do we have any other threats, assuming we don't need to 
> > repeat those where MOBIKE doesn't change anything in
> > normal IKEv2? Should we add some discussion about these 
> > to the design document and/or protocol proposals?
> > 
> > (BTW, a comment about terminology: Francis has quite
> > consistently called case 1 "transient pseudo-NAT attack" 
> > and case 2 "third party bombing". I (and several others) 
> > have sometimes called both 1 and 2 third party bombing.)
> > 
> > Cheers,
> > Pasi
> > _______________________________________________
> > Mobike mailing list
> > [email-masked]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 03 Sep 2004 23:36:26 +0200

In your previous mail you wrote:

   
   
   other than just IKE.

=> in my draft I talk about signaling protocols with two concrete
examples, mobile IP (look at RFC 3519 security considerations)
and IKE. IMHO MOBIKE is concerned both for itself and as a source
of clarification for IKE in a mobile/multi-homed environment.

   It may make sense to either do a general solution
   (else where?)

=> there is an easy solution but obviously incompatible with NAT traversal.

   or if we do MOBIKE-specific solution,

=> I don't believe in a MOBIKE-specific solution. In fact, the current
discussion is about the defense against "third party bombing" which
includes "transient pseudo-NAT"/

   we should let other affected working groups be made aware of it.
   
=> this is done for mobile IP and this is a bit late for IKE (in fact
this is covered by the pki4ipsec profile in its default policies).
But IMHO it will be good to include somewhere in a MOBIKE document
a clarification about this attack, just in order to avoid unsafe
misinterpretation of the IKEv2 address agility.

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 3 Sep 2004 18:27:24 -0700

Atul,

mohanp> I don't understand this point. How does solving this in other protocols
mohanp> solve it for MOBIKE ?

-mohan

Atul