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

Re: Bruce Schneier on IPsec

At 07:41 AM 2/1/2000 -0500, Bill Sommerfeld wrote:

At this point I will not same too much about Schneier's paper.  We talked a 
bit at RSA and I am working on my official response (and not in any 
official IETF position; remember I stepped down as co-chair).

However, what I saw over time was a requirements creep, or rather a 
combination of a number of separate requirements, all munged into one 
(actually two, IPsec, and IKE) protocol.

The workgroup effectively killed off AH for IPv4 at the Danvers IETF, but 
it took a while to admit that and develop a NULL encrypt mode for ESP.  The 
ONLY arguements for AH in v4 space were political/administrative.  I will 
drop this line of reason at this point before I dig a fight line :)

ESP tried to meet to separate requirements:  gateway needs and end ssytem 
needs and evolved tunnel and transport modes.  Steve Kent and others did a 
fantastic job balancing these two power poles.  The vendors concentrated on 
gateways and tunnle mode; lots of reasons for this.

I now view this as a tactical move to get initial IPsec deployment, but not 
what the Net needs.

End to end IPsec needs to be the strategic goal and the total hygenics 
around such a goal needs review.

IMNSHO, IPsec end to end means: ESP transport mode, A KMP with fewer policy 
knobs and simpler rekeying at least, and distributed control (for 
organizations) of security.

> > I read the Counterpane paper, and I strongly agreed with almost
> > everything they said. About the only exception was their proposal to
> > do away with transport mode, which is exactly opposite of what should
> > be done. As you say, tunnel mode should be eliminated in favor of
> > standard tunneling techniques (IP in IP, GRE, etc) before the packet
> > is handed to IPSec.
>
>I agree and disagree here.
>
> From the protocol/over-the-wire standpoint, this is exactly right.
>
>However, from the POV of packet filtering/policy checking, tunnel mode
>and transport mode require very different sorts of policy checks on
>the addresses in the outer and inner ip headers.
>
>Now, if all of your interfaces (including your tunnels) are set up
>with appropriate inbound filters, this isn't a big deal, but
>traditionally, that sort of filtering is not part of an IP stack.
>Always having the inner ip header (making the outer ip header
>irrelevant) would allow the check to always be done as part of ipsec
>rather than over in some other part of the system.



Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com
Follow-Ups: References: