RE: New issue 18: Threat discussion

<[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <DC504E9C3384054C8506D3E6BB012460CD8C0D@bsebe001.americas.nokia.com>
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 protected] 
> [mailto:[email protected]]On
> Behalf Of ext 
> Sent: Thursday, September 02, 2004 2:24 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]
> 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 protected] 
> > [mailto:[email protected]]On
> > Behalf Of ext 
> > Sent: Tuesday, August 24, 2004 11:30 AM
> > To: [email protected]
> > 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 protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.