[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Position statement on IKE development


As a newcomer to IPSec field (but not to the IETF) one of the things that
continues the amaze me is the deliberate effort that has been made to create
a wall between IKE and IPSEC. IKE is written such that it is a general
protocol
that can negotiate SAs for protocols other than IP such as AppleTalk, IPX,
...
Yet the primary (and possibly only use) of IKE is for negotiating IPSEC SAs
(in addition to the IKE SA). The IPSEC DOI (unfortunately) is also written
in
a pretty generic manner and does very little to aid a developer writing IKE
software from scratch. For example, what exactly IKE can negotiate with
respect to
IP selector fields and ranges is pretty much left to the interpretation of
the
developers. 

IMHO, IPSEC SA negotiation also is the biggest cause of headaches in 
interoperability problems between different implementations. Which I believe
was what
Henry was alluding to below.

Therefore, I would suggest that any effort in replacing IKE also consider
replacing/rewriting portions of IPSEC DOI such that:

1) Text is clear and one could write easily working code from it.
2) The IPSEC SA negotiation within IKE is well-defined and not open to
interpretation.
3) All error cases are documented and handling is clearly specified.
4) Some references added to the text to at least outline what to do when
negotiating behind a    
   NAT/firewall and refer to relevant RFCs/drafts.

As far as I am concerned, IKE is the moral equivalent of a signaling
protocol that 
establishes  connections (IPSEC SAs in IKE case) and should be specified in
enough
detail as such.

I have seen similar problems while developing MPLS code with the MPLS specs
but as we were writing software while the drafts were still drafts, most of
the complaints did get addressed
before they became RFCS.

Also note that I am making these suggestions with a constructive desire.

Regards,

Bora

ps. I would be willing to volunteer in such an effort as I described above.

|-----Original Message-----
|From: Henry Spencer [mailto:henry@spsystems.net]
|Sent: Friday, August 03, 2001 7:22 AM
|To: Alex Alten
|Cc: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org;
|ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
|Subject: Re: Position statement on IKE development
|
|
|On Thu, 2 Aug 2001, Alex Alten wrote:
|> ...Their suggestion to use a process like NIST's for selecting
|> the AES standard is an excellent one. It's a pity they did 
|not suggest
|> it a decade ago. However it should be considered seriously not only
|> for the replacement of IKE, but possibly also for the modification or
|> simplification of the entire IPsec protocol suite...
|
|I think this is throwing the baby out with the bathwater.
|
|While the packet-level parts (ESP etc.) do have some flaws, 
|most of those
|can be fixed simply by taking a big black pen and crossing out 
|superfluous
|parts of the existing specs (e.g., all of RFC 2402).  While 
|there is room
|for some debate about exactly which parts should be crossed out (e.g.,
|there are people who still think AH is useful), I think there would be
|little or no support for redesigning the surviving parts.  So a design
|competition does not seem very useful in this area.  Moreover, 
|*this* is
|the area where there is massive investment in silicon, solder 
|traces, etc. 
|Just deleting features does not, by and large, invalidate that 
|investment.
|
|IKE is the disaster area.  The rest of IPsec could use some judicious
|featurectomies, but is not badly broken.
|
|                                                          Henry Spencer
|                                                       
|henry@spsystems.net
|
|
Follow-Ups: