Re: New issue 18: Threat discussion

I think we already agreed that (say) AH can be used
to fight this in general. However, I wanted to make
a couple of additional points. First, this type of packet
modification vulnerabilities appear to come in two
variants: those where you have to be a mitm during the
beginning of a session vs. you can change the addresses
at any time. I believe IKEv2 situation is of the latter
type, as long as some NAT was discovered initially.
Plain IP traffic is however typically of the former type:
changing an address in a packet would not redirect a
TCP stream in middle of a session.

Secondly, the AH protection that Francis mentioned
is obviously for "other" protocols and for payload
packets. The protocol that creates the SAs for this
protection can, however, also have the vulnerability.
I think that's the issue that we are talking about here...

--Jari

[email protected] wrote:
> 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
>>
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>