Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec

From: [email-masked]
Date: Thu, 6 May 2004 17:21:29 -0500

> -----Original Message-----
> From: ext Joe Touch [mailto:[email-masked]]
> Sent: 06 May, 2004 4:27 PM
> To: Swami Yogesh (Nokia-NRC/Dallas)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec
> 
> 
> 
> That presumes that Bob is willing to either
> 
> 1. accept non-IPsec'd tunnel'ed packets
> 	which he should not, once IPsec is enabled, by the rules
> 	in RFC2401 anyway - DENY any packets not IPsec'd as a
> 	catchall rule
> or
> 

Could you please elaborate a little bit... In my picture Bob doesn't
even see anything happening. 

> 2. accept new SAs in which the source address of the inner or outer 
> header is Alice, from Trudy
> 	any inner source that isn't Trudy ought to be invalid for
> 	any packet from Trudy, or Bob is ASKING to be spoofed
> 

So if I understand this correctly, then what you are saying is that if
Trudy sends a packet as follows,

IPhdr1[AH-hdr[IPhdr1[IPhdr1[IPHdr1...[IPHdr-2, TCP ]]]]]...]

(where IPHdr-1 is a valid IP header between Alice and Trudy, but only
IPHdr-2 is the IP header between Alice and Bob) then IPSec engine should
parse the headers all the way up to IPHdr-2 and then throw it! I haven't
read the new AH draft, but this would mean a simple DoS on IPSec engine
itself (especially when there are no keys/Certs to prevent SPI
formation.) Also, what if one of the IPHdr-1 (lets say the third one
from left) has a lot of repeated NOPs and a MF bit set in that IP
header. How does the IPSec engine handle parsing of headers in this
case?

If it means only checking the first and second IPHdr-1 after the AH
header, then the attack is not preventable without a policy that stops
all IP in IP.

The policy of preventing all IP in IP whenever the SPI is formed using
AnonIke is too restrictive, IMO. It would mean that if I want to have
some form of IP tunneling between two host and also use TCP over that
tunnel, then I cannot have secure TCP! To me this is not a reasonable
policy for a general TCP security solution.

(I didn't understand the policies you pointed out, so I cannot comment
on them now.)
 
Yogesh 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 17:03:18 -0700

Yogesh,

[email-masked] wrote:
>>-----Original Message----

Sorry - I got Bob and Alice mixed. The issue is that packet receivers 
should not accept non-IPsec'd packets once IPsec is on; just covering 
the bases.

> parse the headers all the way up to IPHdr-2 and then throw it!

Yes.

> I haven't
> formation.)

Yes. And that's not new at all. YuShun is right - tunnels are a problem 
for spoofing. Tunnel creation should be whitelisted - i.e., permit only 
those you know (which omits ALL ANONike) to create tunnels whose headers 
are in some range you permit (even for non-ANONike peers).

Again, none of this is new. If you are concerned about spoofing you 
shouldn't allow it.

> Also, what if one of the IPHdr-1 (lets say the third one

IPsec is supposed to.

> header, then the attack is not preventable without a policy that stops

Each decapsulated header pushes the packet back through IPsec. That 
means the endpoint needs to create N SPIs to make this work. So don't 
let parties create too many SPIs or to create tunnels that aren't 
whitelisted.

> (I didn't understand the policies you pointed out, so I cannot comment

Tunneling to a gateway then TCP to that same gateway is a bit odd; why 
not just use transport mode to that gateway?

As Yushun pointed out, it may be sufficient to require whitelists for 
tunnels, which are probably required if you want to avoid spoofing 
through a tunnel gateway anyway. That would (by definition) kill all 
ANONsec requests for tunnels through that gateway (since you wouldn't 
whitelist 'from anyone' unless you want to be spoofed).

Joe

---

From: Yu-Shun Wang <[email-masked]>
Date: Thu, 06 May 2004 17:36:02 -0700

Hi,

Comments inline...

>>From: ext Joe Touch [mailto:[email-masked]]

...

> IPhdr1[AH-hdr[IPhdr1[IPhdr1[IPHdr1...[IPHdr-2, TCP ]]]]]...]

No. I think tunnel mode (or transport mode with IP inside) from
*unknown* peers should be prohibited in order to prevent tunneled
spoofing attacks. And this should be the case for both AnonIKE
and (real) IKE.

I am not an IPsec/IKE Expert (IANAIE? :-), but I guess most
policies start with white lists of all known IKE peers and what
they are allowed to do. And at the end, you have rules
like "block all from everything else" or something to that
effect. The rule above (no tunnel mode or transport mode+IP
from unknown peers) should be one of the catch-all rules
at the end if there isn't already one. (This, of course, is
assuming IKE policy processing is sorted like firewall rule
matching.)

So AnonIKE relaxes the requirement of CA in IKE and then
some. But it does not relax how one should write the policy.
Though as Joe said, the first version did not address that.

> header. How does the IPSec engine handle parsing of headers in this

See above. Just take out tunnel mode (or transport+IP) from
unknown peers from the policy.

> policy for a general TCP security solution.

I had the same concern at first. But the firewall analogy
changed my view. If one allows tunnel mode between any src
& dest in the inner packets in regular IKE, having the CA
requirement only authenticates where the attacks come from,
but does not prevent the attacks. Same applies to AnonIKE.

IMHO, the real question for AnonIKE is whether allowing
anyone to negotiate transport mode (non-IP payload) SAs
opens up new/serious holes in places we haven't thought of
(such as DDoS against router IKE/IPsec processing, etc.)

Regards,

yushun

-- 
Yu-Shun Wang <[email-masked]>
USC Information Sciences Institute