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

Re: Simplifying IKE


A few comments:

2a: eliminate ESP authentication
3a: require AH on all packets. No choice, no null mode. An IPsec connection
       authenticates all packets, period.

4. modify ESP to ensure it authenticates all data used in the deciphering
         of the payload

STEVE:  One of the fundamental goals of the Ferguson and Schneider paper
was to see the simplification of IPsec.  I think that unless justification
can be found by the IPv6/mobile camp, we should push forward to eliminate
AH altogether and not try to come up with compromise solutions.

Also, I think that there is going to be a LOT of resistance to making any
modifications to ESP.  Look at the chaos that is the IKE group.  I've
followed this thread in amazement, watching it degenerate and wondering if
anything remotely useful will come of the constant bickering.  Attempting
to make any modifications to ESP, no matter how small or trivial, will
probably cause a similar nonproductive uproar.  Perhaps the better idea is
to scrap the name ESP and move ahead with a new alternative with a new
protocol number that we could call the IP Authenticating, Encapsulating
Packet Security (AEPS -- or something like that, just different from ESP).
This alternative would take ESP and alter it, so that IP header compression
can be added, and the tail section (padding, authentication data and all)
can be moved to the AEPS header to make implementing it that much easier.

This would allow vendors, during a transition period, to be backwards
compatible with existing IPsec implementations that support ESP as is,
while still moving forward with the new standard.

I'd also propose that we allow the diehard faction that says IPsec MUST be
completely backwards compatible to have their way.  When negotiating an SA,
simply do not allow the negotiation of AH, or transport mode in any future
implementations. Eventually, the standard will move towards what people are
doing and eventually, the simplified model, with only AEPS will become the
standard and AH and ESP can be obsoleted (well, it would be nice if this
would work, I can dream, can't I? ;-).



To do this, we would have to specify support for at least one public
key technique as a MUST. I'd say RSA was the obvious possibility, and
we should have only the one MUST for simplicity.

STEVE:  I agree with you on this, but in practice, unless a PKI standard is
settled on, my boss is not going to approve of me implementing a
proprietary solution unless a consensus is reached in the IPsec community
first.  My gut feeling is that it isn't gonna happen unless the work at the
NIST on PKI suddenly becomes accepted as a standard.



I'd like to see AES as the only MUST, with null encryption and 3DES
as SHOULDs.

STEVE:  I'd like this as well, but AES in what modes and key sizes/block
rounds?  What makes the most sense in the networking environment that we
are working in?  Is there any work currently being done to study what
mode/key size/block size combinations are cryptographically sound, but
degrade performance the least?
Follow-Ups: