[Mobike] New issue 18: Threat discussion

[Mohan Parthasarathy]

Atul,


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.

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

-mohan

Atul

> -----Original Message-----
> From: mobike-bounces at machshav.com 
> [mailto:mobike-bounces at machshav.com]On
> Behalf Of ext 
> Sent: Thursday, September 02, 2004 2:24 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); mobike at machshav.com
> 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: mobike-bounces at machshav.com 
> > [mailto:mobike-bounces at machshav.com]On
> > Behalf Of ext 
> > Sent: Tuesday, August 24, 2004 11:30 AM
> > To: mobike at machshav.com
> > 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
> > Mobike at machshav.com
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
> _______________________________________________
> Mobike mailing list
> Mobike at machshav.com
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
Mobike at machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike