Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie

[Ari Huttunen <Ari.Huttunen@F-Secure.com>]

Tero Kivinen wrote:
> If there is no NAT involved in the firewall, then the NAT-T will not
> be enabled, and you will be using just normal IKE and ESP traffic.
> There is NO REASON to use NAT-T unless you have NAT between the two
> hosts. The NAT-T NAT discovery will automatically detect if there is
> NAT between and enable using of NAT-T only and only if there is NAT
> between and the NAT-T is supported by both ends.

I disagree somewhat. The current drafts do not clearly forbid proposing
only ESPUDP encapsulation in QM when there is no NAT detected. There is
also no mentioning what the responder should do in such a case.

This was discussed earlier (off ipsec-list) and at that time it was
to be allowed, with the understanding that this results in ESPUDP usage without
there being a NAT. The intent of such a thing is indeed to go through 
improperly configured firewalls.

Please show me one real case where someone wants IKE to go through
a firewall but not ESP?

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Securing the Mobile Enterprise

---

References:

• Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
• From: Tero Kivinen <kivinen@ssh.fi>

---

• Prev by Date: Re: SPD per interface?
• Next by Date: RE: Ipsec load balancing devices - UDP-ESP impact
• Prev by thread: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
• Next by thread: Ipsec load balancing devices - UDP-ESP impact
• Index(es):
  • Main
  • Thread