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

From: <[email-masked]>
Date: Tue, 7 Sep 2004 09:29:57 -0400

Mohan,

The way I understand the pseudo-NAT problem, the attacker does
modification of addresses in the IP header. The authenticated/encrypted
IKE datagram does not get affected. Since the attack is on the general 
IP header, the problem is general in nature than specific to MOBIKE.
Though I agree it has relevance for MOBIKE.

If a general solution is offered, it would work as much for IP traffic
as for the MOBIKE traffic. The converse may not be true, i.e. a MOBIKE-only
solution may not work for the general IP case. I think Francis expressed his
non-preference for a MOBIKE-only solution, in an earlier message. 

Atul

> -----Original Message-----
> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: Friday, September 03, 2004 9:27 PM
> To: Sharma Atul (Nokia-ES/Boston); Eronen Pasi (Nokia-NRC/Helsinki);
> [email-masked]
> Subject: Re: [Mobike] New issue 18: Threat discussion
> 
> 
> 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: [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
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Sep 2004 15:48:41 +0200

In your previous mail you wrote:

   If a general solution is offered,

=> the general solution is easy: protect the addresses in the IP header.
Of course it has an immediate drawback: NAT traversal is no more possible.

   it would work as much for IP traffic

=> for general IP traffic it is named AH.

   as for the MOBIKE traffic.

=> MOBIKE (and any other signaling protocol) is different because the
attack has a side effect outside the MOBIKE traffic itself (this is why
the attack is qualified as "transient" pseudo-NAT attack).

   The converse may not be true, i.e. a MOBIKE-only
   solution may not work for the general IP case.

=> I agree but this doesn't matter because the MOBIKE security target
is higher, i.e., any MOBIKE mechanism should include a defense against
the transient pseudo-NAT.

   I think Francis expressed his
   non-preference for a MOBIKE-only solution, in an earlier message. 
   
=> my position is the attack should be in the list of attacks considered
in the design phase/document. BTW it is in, and the discussion is more
about the 3rd party bombing, i.e., in my terminology the attack performed
by an authenticated/authorized peer (and obviously something is not right
in the authentication/authorization in this case).
Another point of interest is the security of NAT traversal (not in order to
modify it, but in order to compare) which is of course subject to the attack
but which includes its own defense (implicit update to the last seen peer
address and keepalive mechanisms which narrow the window of attack effect).

Regards

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 7 Sep 2004 18:56:50 -0700

Francis,

> Of course it has an immediate drawback: NAT traversal is no more possible.
Agreed. 

> the transient pseudo-NAT.
Do you mean "defense" as in detecting NAT (like NAT_PREVENTION in
Pasi's draft) OR a solution that would work when moving behind NAT ?

> in the authentication/authorization in this case).

This is a bit confusing. Are you saying that the attack is 3rd party bombing if
performed by authenticated peer and transient pseudo-NAT attack if done
by someone else ?

> address and keepalive mechanisms which narrow the window of attack effect).
It might be useful to clarify what we mean by NAT traversal in these threads.

1) NAT traversal : As defined in IKEv2 base spec. It works only during the beginning
    of IKE session.

2) Behavior of MOBIKE when moving behind NAT  - this is MOBIKE mechanism to support
     moving behind a NAT which is also NAT traversal. But this is something specific
     to MOBIKE and works during anytime not just during SA setup. MOBIKE may or may not
     end up supporing t this feature or it may support partially etc. But this is distinctly different from (1).

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Sep 2004 12:25:31 +0200

=> detecting NAT is the job of IKE. For MOBIKE itself it comes after the
initial exchange so uses only protected exchanges. As soon as an address
is inside an exchange (and it should be in an explicit mechanism) it is
protected.

   > in the authentication/authorization in this case).
   
   This is a bit confusing.

=> the original message is a bit old today. Please refer to it.

   Are you saying that the attack is 3rd party bombing if
   performed by authenticated peer and transient pseudo-NAT attack if done
   by someone else ?
   
=> yes (the original message listed attacks and refered to my terminology.)

   It might be useful to clarify what we mean by NAT traversal in
   these threads.
   
   1) NAT traversal : As defined in IKEv2 base spec. It works only
   during the beginning of IKE session.
   
=> this is the definition in the IKE context.

Regards