[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
I think the extreme position is that what IPSEC does best is:
i) Establishing keys between two known entities (IKE).
ii) Allowing those entities to pass datagram payloads securely between them
by providing encryption, authentication and anti-replay defenses.
It also provides some tunnelling (VPN) and firewall services that are
inferior to the free-standing implementations. IPSEC does not facilitate
resilient routing and you're still likely to need a firewall in addition to
IPSEC.
People have suggested and, I think, implemented stacks where the IPSEC
tunnels are treated as interfaces and hence can be accomodated by routing
protocols. This also allow a firewall (integrated in the same stack) to
make decisions based on the IPSEC tunnel.
This would allow the IPSEC, routing protocols and firewalls to concentrate
on what they do best.
Of course, there would be still a problem of configuring all this securely.
This has been discussed here before but, as usual, the discussion flared up
and died away without any sort of concensus.
As an aside, is there a 'standard' way for an application to request a
specific IPSEC policy for its traffic?
Chris
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: 15 August 2001 00:09
> To: Chris Trobridge
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Simplifying IKE
>
>
> At 7:59 AM +0100 8/8/01, Chris Trobridge wrote:
> >I have to admit I started in the "keep tunnelling - los
> transport" camp, but
> >with more experience I would definitely prefer transport
> mode + IP-in-IP.
> >This makes gateways and end-to-end cases identical. It also
> separates
> >routing issues associated with tunnelling from IPSEC.
>
> remember that a major difference between tunnel and transport modes
> is what headers are examined for access control purposes. if one
> changes to IP-in-IP tunneling above IPsec, it would be important to
> retain this security facility, which means we still need to know
> where to look in the stack, ...
>
> >I'd also like to see all IPSEC traffic between two hosts
> carried by just one
> >SA. I can't see any value in using multiple SAs between to
> hosts. IPSEC
> >should be just providing a secure pipe between two hosts -
> what goes through
> >it is better regulated by a firewall. There is an argument
> that you might
> >want to use different strengths of crypto for performance
> reasons but there
> >is generally a focus on performing one type of encryption
> really well rather
> >than supporting multiple types.
>
> IPsec is not designed to be just an encryption protocol. It provides
> access control comparable to that of a static, packet filtering
> firewall, but with per-SA authentication that a firewall, if placed
> behind an IPsec device, cannot provide.
>
> >
> >I'm less keen on AH and would lose it if at all possible.
> Authenticated ESP
> >provides authentication, integrity and anti-replay of the IP
> payload - what
> >do you care if the IP header has been tampered with? (what
> is missing from
> >ESP auth - just the destination IP address?). Per-hop use
> of SAs currently
> >appears limited as keys are typically only shared by the end-points.
> >
> >I would like to see things like null encryption and specific
> algorithms not
> >being MUST (or even plaintext bypass). My main reason for
> this is that you
> >can reject these by policy anyway but that exclusion from
> build is required
> >for products that go through tough security evaluations.
>
> Null encryption and null authentication are artifices, because IKE
> had allocated two slots for algorithms for ESP, before we allowed
> modular security service use. One could do away with these
> conventions in a reengineered IKE.
>
> Steve
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Follow-Ups: