RE: [Ipsec] big IKE packets

["Yoav Nir" <ynir@checkpoint.com>]

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
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec