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

Re: ipsec in tunnel mode and dynamic routing

Joe, Steve,

Here is an example where keeping a pointer to the SA in question (and
a way to access the SA authentication/identification information) would
be a real asset:  the ability to leverage IPsec security services at
the application level.

Imagine an implmentation of IPsec within a host where during IPsec
processing, the host kept a pointer to the SA along with the packet (a
metadata pointer).  As the packet goes up the IP stack, other layers
(e.g. Application) could access the security information for
themselves.  This allows the application modify its behavior based
upon the IPsec security information.

If the host is implementing a firewall, this would allow the firewall
module to see the IPsec authentication and process the packet
accordingly.  It is not IPsec performing the firewalling (or the
aforemetioned application), however if IPsec is integrated into the OS
then it can make the authentication information available to other
modules that process a packet.

-derek

Joe Touch <touch@ISI.EDU> writes:

> Stephen Kent wrote:
> 
> > At 2:03 PM -0800 11/30/01, Joe Touch wrote:
> > 
> >> Stephen Kent wrote:
> >>
> >>>
> >>> 2401 requires that the SA binding be maintained only within the IPsec 
> >>> implementation. I understood your comments to suggest something else, 
> >>> e.g., a separate firewall module not part of IPsec. If I 
> >>> misunderstood, I apologize.
> >>
> >>
> >>
> >> We want the SA is kept outside the IPsec, so that packets that pass 
> >> through other modules in the meantime will retain their SA, e.g., Sec 
> >> 8.4.
> >>
> >> Joe
> > 
> > 
> > Joe,
> > 
> > Your sentence is not well formed, but I suspect we do have a serious 
> > disagreement here.
> 
> 
> Delete the /is/. Sorry about that :-)
> 
> Yes, it appears we do disagree - let's see where the thread goes, though.
> 
> 
> > An SA is an IPsec concept and thus it exists only within an IPsec 
> > module. IPsec has never been just an encryption protocol, although some 
> > have suggested otherwise.  Encryption, by itself, does not provide 
> > protection against the major forms of attack that most Internet users 
> > experience.  Rather, access control is the security service that is the 
> > focus of most security mechanisms that we employ, if one remembers that 
> > the primary motivation for authentication (user or otherwise) is as an 
> > input to an access control decision.
> > 
> > Since the authentication of the other IPsec peer is an IPsec function, 
> > it makes sense to retain that authentication info and use it to filter 
> > traffic within IPsec, i.e., to perform identity-based access control 
> > enforcement there.
> 
> 
> In that case, what we have is a failure of firewall code (ipfw, e.g.) 
> and tunnel mechanisms (gifconfig, e.g.). If that code is "inside" the 
> IPsec implementation, the SA would be available.
> 
> There is more to packet processing than just encryption and 
> authentication, _however_ that doesn't mean that the configuration 
> interface needs to be as integrated as the implementation. If, for 
> example, all firewall processing and tunneling were _implemented_ inside 
> IPsec, then the SAs would be properly available.
> 
> So, I agree that the implementation should be integrated, but not 
> necessarily that the configuration should be as tightly integrated.
> 
> Joe
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
References: