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

Re: Mobile IKE/IPSEC



At 14:02 21.8.2000 +0300, you wrote:
>	Is there any draft/RFC discussing possiblilities to use IPSEC/IKE
>for devices with dinamic addresses (eg: Dial-up)?
>The problem arises because a device with a variable address that wants to
>acces a intranet through a SG. How can I configure the SG IPSEC/IKE for this
>situation?
>	The idea would be use in some way the ID used in IKE to transmit
>some kind of info to do that. 
>	Is there any IKE mode which fit best to this case?
>
>		dial-up device - DD
>		Security gateway - SG
>		Intennal host n - Hn
>
>			DD ========== SG ------------	H1
>								H2
>								...
>								Hn
>
>	Sorry if the subject has been discussed before (Just give a pointer
>to some releveant message if that's the case)
>
>Toni
>

First of all, this might be helpful:

>typedef enum {
>  /* IPSEC_ID_RESERVED			= 0, */
>  IPSEC_ID_IPV4_ADDR			= 1,
>  IPSEC_ID_FQDN			= 2,
>  IPSEC_ID_USER_FQDN			= 3,
>  IPSEC_ID_IPV4_ADDR_SUBNET		= 4,
>  IPSEC_ID_IPV6_ADDR			= 5,
>  IPSEC_ID_IPV6_ADDR_SUBNET		= 6,
>  IPSEC_ID_IPV4_ADDR_RANGE		= 7,
>  IPSEC_ID_IPV6_ADDR_RANGE		= 8,
>  IPSEC_ID_DER_ASN1_DN		= 9,
>  IPSEC_ID_DER_ASN1_GN		= 10,
>  IPSEC_ID_KEY_ID			= 11
>} IkeIpsecIdentificationType;
>
>PHASE 1 using preshared keys
>============================
>
>The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and KEY_ID are 
>recommended in a phase 1 exchange using preshared keys. 
>In agressive mode, the values can be used for an immediate 
>policy lookup. In main mode, the responder
>must retrieve the secret from the spd before it receives the ID, thus
>only IPV4_ADDR is useful in main mode.
>
>Is the responder has a "group" policy to allow several hosts 
>with volatile IP addresses to connect, the use of aggressive mode
>and ID types USER_FQDN and KEY_ID is recommended. 
>
>DER_ASN1_DN and DER_ASN1_GN are meaningful IDs as well, if an
>implementation chooses to store policy data indexed by these IDs.
>
>Address ranges and subnets are not allowed in Phase 1.
>
>An IKE implementation MUST at least implement IPV4_ADDR.
>However, USER_FQDN is a very useful ID because end users
>are able to understand and remember them.
>
>PHASE 1 using pk signatures
>===========================
>
>The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and DER_ASN1_DN are 
>recommended in a phase 1 exchange using signatures. 
>In agressive mode, the values can be used for an immediate policy lookup.
>In main mode, only the initiator's IP address is available for the 
>initial policy lookup of the responder. Therefore, the policy must 
>contain (IP address, ID) or (IP address range, ID range) pairs.
>After receiving the 5th packet of MM, the responder has to do
>a second policy check. 
>The responder must reject a MM where the IDV4_ADDR ID and the
>IP address does not match.
>
>Is the responder has a "group" policy to allow several hosts 
>with volatile IP addresses to connect, the use of aggressive mode
>and ID types USER_FQDN and DER_ASN1_DN is recommended.
>It should be noted that these IDs, especially DER_ASN1_DN may 
>contain valuable information which is not suitable to be transmitted 
>in cleartext. In this case, I recommend public key encrytion. The 
>alternative is having one policy entry (0.0.0.0/0, (list of all IDs)).
>
>The ID must show up in the certificate! E.g., if the ID is USER_FQDN,
>the subjectAltName must contain an email address.
>
>DER_ASN1_GN is may be used as an alternative to IPV4_ADDR, IPV6_ADDR, FQDN
>and USER_FQDN.
>The subjectAltNames in certificates are encoded as general names, so
>DER_ASN1_GN is a generic pointer to a subjectAltName.
>One could even argue that USER_FQDN is not a valid ID and that email
addresses
>must be encoded using DER_ASN1_GN. I don't think so.
>
>Address ranges and subnets are not allowed in Phase 1.
>IPSEC_ID_KEY_ID is not useful.
>
>An IKE implementation MUST at least implement IPV4_ADDR and DER_ASN1_DN.
>
>PHASE 1 using pk encryption
>===========================
>
>Same as signatures, but the ID is safe in agressive mode.
>
>Quick Mode
>==========
>
>QM IDs act as selectors for packets. src and dst addresses of IP packets
>transmitted through the SA must match the negotiated IDs.
>While it is possible to not send IDs in QM, it is not recommended.
>
>IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET,
>IPV6_ADDR_RANGE
>may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET
>may be mixed.
>

Well, it seems that there is no "perfect" solution.

Don't use pre-shared keys, they're crap.

Some people just go with Main Mode, with DER_ASN1_DN as IKE ID.
Other people use Aggressive Mode, with IPSEC_ID_USER_FQDN.
Then there are the people who go "Use the latest draft!".

Have a nice day.

Jrn


References: