Subject: RE: [Ipsec] big IKE packets

From: "Yoav Nir" <[email-masked]>
Date: Wed, 1 Sep 2004 10:03:56 +0300

OK.

Yes, solving the cert too-big-for-MTU is important.

I don't know how representative it is of others' experience, but I can tell
you about my company's experience with IKEv1.  In general, enterprise
gateways have no problems talking to one another using large UDP packets.
The routers allow this, although my experience may be tainted by working
only with modern gateways.

The place where cert-too-big is a problem is for the case of a home user or
small office behind a broadband modem.  These things do drop UDP fragments,
and in many cases they prevent phase 1 from completing.

I'm just not sure Suren's idea is the best way to solve this.  What my
company did was to allow IKE to pass over TCP (we used port 500).  This has
some advantages, and some disadvantages.  I'll list them, as far as we've
learned:

Advantages:
  1. Takes care of long messages and retransmissions.
  2. Since an IKE message has a length field, requires virtually
     no change in the protocol.

Disadvantages:
  1. Like all TCP ports, this is a potential for DOS attacks that
     needs to be mitigated.
  2. When the evil, fragment-dropping router is also a NAT 
     device (nearly always) you cannot open a TCP connection from
     the responder back to the initiator, so you need to have a
     separate phase2 (or CCSA in IKEv2) exchange running with UDP
     after the original exchange so as to map the ports.

Certs are not the only source for messages.  In IKEv1 there were also large
proposals.  In IKEv2 there could be EAP methods, large traffic selectors,
etc.  Things like hash-and-URL solve one problem, but I think IKE over TCP
is a better solution.

Like any proposal, I guess this too falls into the too-late-for-IKEv2
category, but it still could be submitted as a private draft.

-----Original Message-----
From: Michael Richardson
Subject: Re: [Ipsec] big IKE packets 

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> It would be a lot easier for those of us who think "let's not
    VPNC> re-invent TCP in IKEv2" to know what you are talking about if
    VPNC> we had an Internet Draft will your full proposal for the
    VPNC> fragment handling. Without that, we'll just keep saying "it's
    VPNC> too hard, and it's not important enough" and you'll keep
    VPNC> saying "it really isn't, and it is important".

  Remember, that I'm the guy who thinks that one of the reasons that 
certificates shouldn't be exchanged in-band is because of problems like
this :-)
  I do, however, hate PSK, and want it to go away, so if solving this
problem makes progress, then I'm willing to help.

  I twigged on this after reading parts of the last month of the
pki4ipsec list, and started to think about it in the shower or
something.

  I would be happy to write a document --- but others need to say, "yes,
solving the cert too-big-for-MTU is important".

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

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 1 Sep 2004 13:31:13 +0300

Those stupid DSL routers know (sort-of) how to deal with TCP.  They can live
with UDP (as long as it does not need fragmentation).  They usually drop
ICMP, ESP and AH.  I wouldn't trust them to pass SCTP. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 1:02 PM
To: Yoav Nir
Cc: 'Michael Richardson'; 'Paul Hoffman / VPNC'; [email-masked];
[email-masked]
Subject: Re: [Ipsec] big IKE packets 

 In your previous mail you wrote:

   Things like hash-and-URL solve one problem, but I think IKE over TCP
   is a better solution.

=> if we agree to change UDP for a better protocol, IMHO SCTP is
the best candidate (BTW it was designed for signaling, and IKE is
a signaling protocol).

Regards

[email-masked]

PS: interaction of IKE over SCTP and MOBIKE should give some fun!

---

From: Francis Dupont <[email-masked]>
Date: Wed, 01 Sep 2004 12:01:42 +0200

Regards

---

From: Paul Koning <[email-masked]>
Date: Wed, 1 Sep 2004 12:51:28 -0400

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

 Yoav> Those stupid DSL routers know (sort-of) how to deal with TCP.
 Yoav> They can live with UDP (as long as it does not need
 Yoav> fragmentation).  They usually drop ICMP, ESP and AH.  I
 Yoav> wouldn't trust them to pass SCTP.

To what extent should we pessimize the protocol design to work around
defective network equipment?

	  paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Sep 2004 22:44:03 +0300

To quite a large extent.  If that equipment worked correctly, it would 
be able to work with fragments, and we could do with UDP and ESP, no 
need for NAT-T.

As it is, TCP is supported by all equipment, and is implemented in 
every operating system.  Who uses SCTP?

---

From: Paul Koning <[email-masked]>
Date: Wed, 1 Sep 2004 16:54:42 -0400

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

 Yoav> To quite a large extent.  If that equipment worked correctly,
 Yoav> it would be able to work with fragments, and we could do with
 Yoav> UDP and ESP, no need for NAT-T.

 Yoav> As it is, TCP is supported by all equipment, and is implemented
 Yoav> in every operating system.  Who uses SCTP?

Not many people use SCTP.  But it is an IETF standard.  It has been
suggested as a suitable protocol.  If we decide not to use it for
technical reasons, that's fine.  But I don't think "we can't use good
protocol X because there are crummy network equipment vendors who mess
up that protocol" is a good policy.

     paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2004 18:37:05 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Koning <[email-masked]> writes:

    Yoav> As it is, TCP is supported by all equipment, and is
    Yoav> implemented in every operating system.  Who uses SCTP?

    Paul> Not many people use SCTP.  But it is an IETF standard.  It has
    Paul> been suggested as a suitable protocol.  If we decide not to
    Paul> use it for technical reasons, that's fine.  But I don't think
    Paul> "we can't use good protocol X because there are crummy network
    Paul> equipment vendors who mess up that protocol" is a good policy.

  Should we define a standard way to do IKE over SCTP? Yes.

  Does it solve the problem at hand? Unfortunately not.

Let me state the problem again:

Statement 1: IKE (v1 and v2) can create UDP datagrams which are larger
	     than the MTU.

Statement 2: IP permits these datagrams to be fragmented by the sender,
	     such that the receiver can assemble them.

Statement 3: there exist faulty network devices which attempt to filter
	     based upon port numbers, and fail when the datagrams are
	     fragmented.

Assumptions/Notes

Statement 1
a) If the only source of large IKE packets is certificates, then there are
   other mechanisms for exchanging certificates. They include HTTP, LDAP,
   possibly HTTP POST from the "road warrior" to the gateway, etc.

   I.e. we don't need to solve this problem in IKE.

b) There are are other reasons why IKE datagrams can be large.
   One reason in IKEv1 is proposals. 
       Postulate: IKEv2 mitigates this to the point where it doesn't matter.

Statement 2

a) A gateway may wish to never have to assemble fragments for port-500
   to avoid fragment attacks.

Statement 3

a) The broken equipment can not be replaced.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Francis Dupont <[email-masked]>
Date: Thu, 02 Sep 2004 10:37:08 +0200

=> if I understand you well, you argue for IKE over HTTP (:-)?

Regards

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 2 Sep 2004 12:10:28 +0300

Perish the thought.  Then some smart firewall will drop your IKE because it
does not look like HTTP, so it's either a worm or file-sharing.

Better use HTTPS.  Nobody understands SSL  :-) 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, September 02, 2004 11:37 AM
To: Yoav Nir
Cc: [email-masked]; 'Michael Richardson'; 'Paul Hoffman / VPNC';
[email-masked]
Subject: Re: [Ipsec] big IKE packets 

   Those stupid DSL routers know (sort-of) how to deal with TCP.  They can
live
   with UDP (as long as it does not need fragmentation).  They usually drop
   ICMP, ESP and AH.  I wouldn't trust them to pass SCTP. 

Regards

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Sep 2004 15:03:35 +0300

> be able to work with fragments, and we could do with UDP and ESP, no 

Not really. ESP cannot never go through the NATs without the NAT's
doing some guesswork, or without the IPsec to telling the NAT the SPI
mapping it is using. I.e. NAT will not know which inbound SPI matches
what outbound SPI, and it cannot forward packets to the correct
recipient.

NAT-T does this by giving the information to the NAT boxes in the form
of UDP port numbers.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Sep 2004 20:30:24 +0200 (MET DST)

> defective network equipment?

I have seen a strong increase in support questions that involve MTU problems
since Microsoft added IPsec and ESPinUDP encapsulation in their products.
We are seeing an ever increasing deployment based on X.509 certificates,

I don't think it is wise to ignore the problem; especially in a design
phase where these problems are known and possibly addressed.

There are a lot of cheap, broken, networks out there. And it is not getting
prettier with the next generation wireless/gms/umts/gprs. (And it won't be
ipv6 either ;)

If we can't even get it to work now, it surely won't work in the future.

Paul