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

Re: Identity Type



 In your previous mail you wrote:

   OK, here we go again. Others have seen this before, 
   but the email is not that long, really.
   
=> as this question is a major source of interoperability problems I really
believe someone (you?) should publish this kind of stuff as an I-D ASAP
and try to get this as an RFC (informational?) at the next IETF meeting.

   It should be noted that these are
   my personal opinions, not a standard.
   
=> the son-of-ike is supposed to fix this but a short document can be
available (ie. published as an RFC) very soon.

   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. 
   
=> USER_FQDN has the same format than a NAI (RFC 2486) then it is
my preferate today even if we should not encourage to confuse user
authentication and IKE/device authentication.

   However, USER_FQDN is a very useful ID because end users
   are able to understand and remember them.
   
=> this is another argument in favor of USER_FQDN...

   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.
   
=> I agree.

   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.
   
=> do you mean it is not recommended to send or to not send?

   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.
   
=> I'd like to have a rationate for QM IDs explaining for instance that
a FQDN is ambiguous/expensive (ie. a resolution of the name to addresses
gives an unexpected address or several addresses) or simply not useful
(ie. a resolution gives the IP address of phase one).

Thanks

Francis.Dupont@enst-bretagne.fr


References: