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

Re: On the Use of SCTP with IPsec

To: carney@securecomputing.com
Subject: Re: On the Use of SCTP with IPsec
From: Mike Ditto <ford@incog.com>
Date: Tue, 27 Feb 2001 19:32:47 -0800 (PST)
CC: Markku.Savela@iki.fi, ipsec@lists.tislabs.com
In-reply-to: <200102272330.RAA27113@jumpsrv> (message from Mike Carney on Tue,27 Feb 2001 17:30:44 -0600)
Sender: owner-ipsec@lists.tislabs.com

> > One should not add more complexity to the IKE. Instead one should
> > remove *ALL* selector information (that is used to check the policy)
> > from IKE phase 2 negotiations.
> > 
> > The kernel checks the policy anyway (if it follows RFC2401 correctly),
> > IKE doesn't need to to anything else but negotitiate the phase 2
> > session keys.
> 
> Hmm, I guess I'm missing something...
> 
>    Lets say you are a VPN gateway developer who wishes to interoperate
> with a VPN client.  The VPN client establishes a tunnel from a DHCP
> assigned interface address using a virtual IP address inside the tunnel.  
> How does the kernel discover what virtual address has been selected by
> the client (currently the phase 2 identity) if IKE doesn't tell him?

You let phase 2 complete.  You receive and decrypt an IPsec packet.  You
look at the inner IP header's source address.

					-=] Mike [=-

Michael Ditto                           	Office: +1 (650) 786-0457
Solaris Security Technologies           	Fax:    +1 (650) 786-0495

References:

Re: On the Use of SCTP with IPsec

From: Mike Carney <carney@securecomputing.com>

Prev by Date: Re: On the Use of SCTP with IPsec
Prev by thread: Re: On the Use of SCTP with IPsec
Next by thread: Re: On the Use of SCTP with IPsec
Index(es):
- Main
- Thread