[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.
J–rn
References: