Subject: [Ipsec] big IKE packets

From: Tero Kivinen <[email-masked]>
Date: Wed, 1 Sep 2004 13:20:31 +0300

Michael Richardson writes:
> I wonder if one solution to the problem of large IKE packets
> (that require fragmentation) wouldn't be to define a fragmentation
> header in IKE.

There is also such method, it is called IP. The IP packets already
offers fragmentation, why should we do it again on the IKE level?

If the operating system vendor who implemented IP stack didn't know
how to make the fragmentation, how can you expect him to be able to
make IKE fragmentation to the IPsec stack of the OS?

The only difference would be the separate acks for fragments, but I do
not think this fragmentation in IKE would really help, as it just adds
one more complicated option, and I think people would be leaving the
implementation of it out from their products.

The HTTP transfer of certificates is much better sulution for that.
-- 
[email-masked]

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Sep 2004 11:59:40 -0500

On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote:
>   But, they would be vulnerable to the TCP RST attacks that we might in 
> fact trying to defend against in the first place.

IKEv2 is not BGP.  Presumably RSTing an IKEv2 TCP connection (if IKEv2
ran over TCP) wouldn't affect any live SAs :)

Yes, running IKEv2 over TCP adds a DoS to IKEv2, but IKE is,
essentially, about bootstrapping a secure network given an insecure
network, so that seems Ok to me.  (And surely IKEv2 suffers from other
DoS attacks anyways?)

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Sep 2004 13:07:47 +0300

> ran over TCP) wouldn't affect any live SAs :)

Actually it would delete all the IPsec SAs negotiated with the IKEv2
SA which was terminated. So it would affect all SAs.
-- 
[email-masked]

---

From: "M.Chenna kesava Reddy" <[email-masked]>
Date: Fri, 03 Sep 2004 15:48:13 +0530

Hi surendra,
As for as I think  HTTP is allowed by firewall, and Ike will always
sends it's ip address and port as part of URL.

Thx
mcreddy

suren wrote:

>Hi,
>   As I understand, the IKE node can send Hash of public key of 
>   its certificate and URL (including port number) from which the peer
>   can retrieve its certificate. I guess, it is to ensure that there is
>   no fragmentation on IKE packets as some routers might not honor
>   fragmentation. 
>
>   I see that there would be firewall related issues in this. 
>   Since, the IKE needs to make a new connection (HTTP connection) to
>   the URI given in Cert payload, any firewalls in between should have 
>   a policy (ACL) to allow this HTTP connection.
>
>   This could be a deployment problem. The administrator of firewall
>   need to create a ACL to allow all connections outbound.  
>   This is one of the problem being faced by administrators on CRLDP
>  (CRL Distribution point) too. At least in this case, the distribution
>   points are smaller and in most cases deterministic and the
>   administrator of firewalls can create appropriate policies
>   statically.
>
>   What do you think of this following proposal.
>   - IKE Peer which receives Certificate payload always sends its 
>     IP address and port as part of URL.  (Assumption here is that, 
>     all services typically are allowed between IPSec Peers).
>   - When the IKE node receives HTTP request, it could send HTTP
>     Redirect to new URL, which could be outside its node.
>   - IKE Peer is expected to use same source IP address and Port 
>     (May be using REUSE address option in sockets) to connect to 
>     new HTTP Server and Port. 
>   - Since, most of firewalls support 'address binding' feature, 
>     it should work.
>
>Does this make sense? Comments?
>
>Thanks
>Suren
>www.intoto.com
>
>
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Sep 2004 10:19:24 -0500

> SA which was terminated. So it would affect all SAs.

I don't get it.  IKEv2 runs over UDP, where there's no RST.

So why would running it over TCP introduce this RST->SA-death scenario?

What am I missing?

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Fri, 03 Sep 2004 20:45:00 +0300

No.  At the end of the initial negotiation, the TCP connection is 
terminated and the SA remains.  Further child SAs will be negotiated in 
new TCP connections or using UDP packets. (or SCTP if we write support 
for that too)

The SA is not bound to any message passing mechanism.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Sep 2004 12:52:54 -0500

Thank you.

So, why not run IKEv2 over TCP (or SCTP)?

I think the DoS attacks on unprotected TCP connections for IKEv2 are
something we can probably live with as the price of bootstrapping a
secure network.  So, unless I'm missing something, DoS attacks TCP do
not make for a sufficient rationale for rejecting IKEv2 over TCP.

In the Kerberos V world we had the same middle-box/large packet
traversal problem; running the KDC exchanges over TCP worked for
Kerberos (a bit of encapsulation, a PDU length, had to be prefixed to
the Kerberos PDUs).

Is NAT-T more difficult if IKEv2 is run over TCP?

Nico

---

From: Yoav Nir <[email-masked]>
Date: Fri, 03 Sep 2004 21:13:59 +0300

If you are behind a NAT device, you need to have at least one packet go 
over UDP from the iniitator to the responder.

In IKEv1 you could do this by passing phase 2 over UDP.  In IKEv2 
you'll need an extra exchange (empty notification, or CCSA).  As I am 
writing this mail, I am connected to my mail server from behind a home 
DSL router.  IKEv1 over UDP did not work, because packet #5 of Main 
Mode did not pass ( or maybe it was packet #6).  IKE over TCP worked 
like a charm, but it was only done for phase 1.

TCP is usually considered more dangerous than UDP because DoS attacks 
are generally easier to mount on TCP.  (RST attack, SYN attack)  I 
think this is the reason for the resistance to using anything other 
than UDP.

Maybe someone can write a draft for IKEv2 over TCP (and SCTP) as 
optional extensions to IKEv2.  Then maybe we can collect all the 
optional extensions people keep suggesting, and make them into a big 
document titled "IKEv2 Optional Extensions".

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Sep 2004 21:45:28 +0300

> I don't get it.  IKEv2 runs over UDP, where there's no RST.

And if the UDP connection is broken down (== no reply from the other
end), the IKE SA is removed, and all the IPsec SAs created using them
IKE SA are also removed. 

> So why would running it over TCP introduce this RST->SA-death scenario?

If IKE is run over TCP, my interpreation of TCP connection breaking
down, would be the same as UDP connection breaking down, i.e. the IKE
SA is removed. 
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Sep 2004 14:06:22 -0500

> down, would be the same as UDP connection breaking down, i.e. the IKE

The second paragraph of section 2.4 of the IKEv2 I-D leads me to a
totally different interpretation.

My interpretation is that the peer that accepted the TCP connection
should wait for its peer to connect again, who, in turn should try to
re-connect; if both peers can connect to the other (NAT makes this
difficult), then both should try to re-connect.  Plus timeouts, as per-
section 2.4.

Also, use of UDP for some parts of IKEv2 appears to be necessary anyways
(for NAT-T), so the use of UDP for dead peer detection when TCP
connections reset seems quite reasonable (I assume such datagrams would
be small enough to avoid fragmentation issues).

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Sep 2004 10:58:09 +0300

> new TCP connections or using UDP packets. (or SCTP if we write support 

That is one way to do it, but I have to say that it is not efficient
or obvious way to do it. This means that for each informational
message your are sending, or when creating new child SAs, you suddenly
have to do the TCP connection setup again, which doubles the number of
round trips needed etc.

There are multiple ways of doing the TCP transport stuff, and as we do
not have the spec for it, there is no point of arguing about how the
nonexiting IKE over TCP works.

If we want we can start arguing about how it should be done, what are
the good and bad things with each proposal. 

> The SA is not bound to any message passing mechanism.

I would disagree with that design choice. In the IKEv2 we did try to
tighten up the binding between IKEv2 SA and IPsec SA, and I would see
it completely appropriate to follow the same design choice here, i.e.
bind the transport mechanism connection and IKE SA together. It does
take care of lots of corner cases and simplifies the things.

The another approach where the IKE SA and transport mechanism
connection would not be tied together would be more like IKEv1 way of
do it. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Sep 2004 11:05:17 +0300

> Is NAT-T more difficult if IKEv2 is run over TCP?

Not really, but the performance of the TCP over TCP is very bad,
unless the IPsec would do something like retransmit detection and
filtering etc. 
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Sep 2004 23:32:12 -0500

> unless the IPsec would do something like retransmit detection and

We're talking about running IKEv2 over TCP, not encapsulating ESP/AH in
TCP.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Sep 2004 23:39:39 -0500

> have to do the TCP connection setup again, which doubles the number of

I wouldn't necessarily have IKEv2 do one TCP connection per-transaction,
but I'd have IKEv2 reconnect if the TCP connection is reset of if
there's timeouts, very much in the spirit of section 2.4 of the IKEv2
I-D.

> nonexiting IKE over TCP works.

Section 2.4 of the IKEv2 I-D provides the guidance, I think, for how to
run IKEv2 over TCP.

> take care of lots of corner cases and simplifies the things.

But this wasn't done with UDP as the IKEv2 transport...  Why?  Because
UDP is connectionless.  Since the reason for proposing IKEv2 over TCP in
the first place has nothing to do with TCP being connection-oriented but
everything to do with PMTUs and NAT traversal I don't see why one would
then want to make this leap and desire to tie IKE_SAs and their children
to indicidual TCP connections -- that just does not follow.

Nico
--

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 7 Sep 2004 09:55:08 +0300

The way I see it, the reason for proposing IKE over TCP is that TCP can pass
arbitrary-length messages reliably a lot better than UDP.  This capability
is needed for the initial exchange, but not so much for informational and
child-sa exchanges.  Also, it is not good behavior to keep an idle TCP
connection for extended periods, because otherwise you might have a shortage
of sockets.  Any server, including and IKEoTCP server should close the
connection if it is idle for more than several seconds.

If I were writing a draft for IKEv2 over TCP, I would say that any
supporting implementation:
- MUST be able to do initial exchanges over TCP
- MAY be able to be the initiator of non-initial exchanges over TCP
- MUST be able to be the responder of non-initial exchanges over TCP
- MUST be able to do non-initial exchanges based on an SA created with TCP,
over UDP.
- SHOULD close a TCP connection when it has no more SAs to negotiate.
- SHOULD close a TCP connection if it has been idle for 60 seconds.

I would also say a peer is dead only if it cannot be reached with UDP, and
that once an exchange is complete, the resulting SA is valid regardless of
the transport, and regardless of whether or not the connection is still
valid. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicolas Williams
Sent: Tuesday, September 07, 2004 7:40 AM
To: Tero Kivinen
Cc: Michael Richardson; [email-masked]; Yoav Nir; Paul Koning;
[email-masked]
Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Sep 2004 11:35:20 +0300

> We're talking about running IKEv2 over TCP, not encapsulating ESP/AH in

Nope. Someone was asking if NAT-T is more difficult if IKEv2 is
running over TCP. As in NAT-T the ESP uses same channel than IKE
packets, it means that those packet will also run over TCP, thus TCP
over TCP performance is issue here.

Of course you could define new NAT-T which would use different channel
for ESP and IKE, but that was not the question.

----------------------------------------------------------------------
2.23 NAT Traversal
...
      The IKE initiator MUST check these payloads if present and if they
      do not match the addresses in the outer packet MUST tunnel all
      future IKE and ESP packets associated with this IKE_SA over UDP
      port 4500.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Sep 2004 11:51:34 +0300

> there's timeouts, very much in the spirit of section 2.4 of the IKEv2

After rereading the section 2.4 once again, I disagree about your
interpretation of the section 2.4.

> Section 2.4 of the IKEv2 I-D provides the guidance, I think, for how to

Nope. It does not say a single word about TCP. Trying to interpret
text written in UDP context in the TCP context can give very different
results.

> UDP is connectionless.

If my UDP socket would suddenly disappears because of the operating
system is running out of the resources, I would be going to interpret
it as a connection loss, and delete IKE SA (i.e. if the OS decides
that it will not be forwarding any packets to that UDP port to me
anymore). Of course I do not know any way in the normal socket
interface where I could that information but...

> Since the reason for proposing IKEv2 over TCP in the first place has
> nothing to do with TCP being connection-oriented but everything to
> do with PMTUs and NAT traversal I don't see why one would then want
> to make this leap and desire to tie IKE_SAs and their children to
> indicidual TCP connections -- that just does not follow.

It is little bit hard to talk about protocol which is not defined
anywhere, and which people have different idea how to design it.

As I said earlier this discussion is in completely wrong level. We
might start talking about the design choices of the running IKEv2 over
TCP (i.e. whether to create one TCP connection and tie it to the IKE
SA, or create TCP session per request reply or create TCP session
once, but recreate it if it breaks etc).

But I think that discussion is now quite pointless as we do not think
we are going to define IKEv2 over TCP now.

Anyways trying to interpret the IKEv2 text written in UDP context in
TCP context is not very usefull, and especially if we start making
modifications to the way the protocol works in the same time, without
defining those. 
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Sep 2004 10:10:53 -0500

> over TCP performance is issue here.

It seems you have not read the answers that my asking that question
generated.

One answer was that part of the IKEv2 protocol must be run over UDP in
order for UDP encapsulation of ESP/AH to work.

Nico
--

---

From: Paul Koning <[email-masked]>
Date: Tue, 7 Sep 2004 11:26:11 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:

 Yoav> The way I see it, the reason for proposing IKE over TCP is that
 Yoav> TCP can pass arbitrary-length messages reliably a lot better
 Yoav> than UDP.  This capability is needed for the initial exchange,
 Yoav> but not so much for informational and child-sa exchanges.
 Yoav> Also, it is not good behavior to keep an idle TCP connection
 Yoav> for extended periods, because otherwise you might have a
 Yoav> shortage of sockets.  Any server, including and IKEoTCP server
 Yoav> should close the connection if it is idle for more than several
 Yoav> seconds.

Definitely not.  "May" -- sure.  Some implementations may have small
limits on TCP connection counts.  Others may have no trouble at all
having thousands open at a time.  Certainly the amount of state needed
to keep a TCP connection open isn't all that large, if you compare it
with the SA state.

     paul