[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remaining open issues for RFC-2401bis
-----BEGIN PGP SIGNED MESSAGE-----
Kent> Since all ID's sent via IKE are used for access control, it seems
Kent> reasonable to assume that, in general, people have interacted
Kent> with a management interface to enter these IDs.
Let's rephase this so that I agree:
When IPsec is used for access control (such as VPNs or
RemoteAccess), then all IDs sent via IKE are used for access
control, it seems reasonable to assume that, in general, people
have interacted with a management interface to enter these IDs.
Maybe this is a tautology. Maybe not.
As long as there is a mapping from the ID to the access control policy,
then I don't have a problem with this statement.
VPNC> Also fully agree. I'm happy if we change this field in IKEV to
VPNC> "UTF-8 text string" (changing it to ASCII is not a reasonable
VPNC> option). However, I'm not happy with leaving IKEv2 alone and
VPNC> having that requirement (or, even worse, that assumption) come
VPNC> in 2401bis. If IKEv2 is left as it is, 2401bit should not
VPNC> change the interpretation of the field. Otherwise, boxes that
VPNC> follow 2401bis might fall over when handed a non-UTF-8 octet
VPNC> stream.
That's fine, but I personally see Kivinen's point.
I don't know why a UTF-8 can't go into a different ID type.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQGBzXIqHRg3pndX9AQEsTgP+N3n8IxpMAVidpRntsk2H/COwzG4oz7Lv
cMqK8+5inJ2+wqmjeTUnQo+1H/5EPlRbrwxR/dHJWwBd5kn8nNubYQNGHFfZIIJj
rSAZgJjjOQk9/JoGFOD1EmTQGk6OQnmF5Ar70vJ1X911od/qSIxPt9V+MEGBy1y9
nWPcojxgw7E=
=//Tn
-----END PGP SIGNATURE-----