Hi Tero,
Anyways I think the document is in quite good shape, I think the
section 2.2 needs to be more specific about how to send the empty ID
payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of
data is very bad idea. The current text says you can omit data, and
that the type can be anything. The problem is that in most cases the
implementation has code that will parse the ID payload using standard
rules and now if the ID payload has type of ID_IPV4_ADDR and 0 bytes
of data, the parsing will fail.
I agree this may chocke some implementations. The idea was that
if implementation notice that Auth Method is NULL, it must
not parse ID Payload at all. But I understand that depending
on the order in which payloads are processed by particular
implementation, this may be inconvinient for implementers.
It would be better to say that if you are sending empty ID payload,
you msut use ID_KEY_ID type which already allows any data, including
empty.
Actually, even with ID_KEY_ID it is a bit of hack.
I'd rather define the entity "Empty ID Payload" as
ID Payload with ID Type of zero and zero-length content
(so that even ID Type be undefined) and require
implementations to use it if they want to keep anonimity.
Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
ignored", and I think that is again bad idea. I think logging and
auditing the ID for problem solving purposes is good idea even if it
does not have any meaning for the authentication. I.e. at least then I
can contact helpdesk and say that my NULL authentication connection to
server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
from your logs...
Actually, I tried to address Paul Wouters' concern that without
strong "MUST" here implementations may use ID even if it is
not authenticated. But, from my understanding of the wording,
"MUST be ignored by IKE" doesn't mean that implementation
is not allowed to log the ID, that is always useful ror auditing
and troubleshooting. I probably should make this more clear.
Regards,
Valery.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
