>>>>> On 12 Jul 2006 09:10:26 -0500,
>>>>> [EMAIL PROTECTED] said:
> In some sense, your point is true. However, in order to provide the DNS
> resolution service for the globally roaming hosts which is away from its
> home network, I believe that the TSIG-based approach is a good candidate.
> The actual key management between stub clients and recursive DNS servers is
> out of scope in this document.
Without reasonable scheme of key management, TSIG-based approach
cannot be a "candidate" IMO. It's irresponsible to me to say it's a
candidate, excluding consideration of the difficult part while we
actually know it's almost impossible.
I also think ignoring the reality of key management is against the
sense of the general guideline described in
draft-bellovin-useipsec-04.txt (which is referred to from the I-D
checklist). Although this draft concentrates on the use of IPsec, I
believe the same guideline should also apply to TSIG or any other
security mechanisms.
In addition, as I pointed out in the previous message, if a TSIG-based
approach is really a candidate, the roaming host is configured with a
TSIG key and with the corresponding server address in practice. Then
the roaming host doesn't even need the information provided in the RA
option in the first place. So, the use of S flag can only either be
insecure or meaningless, and that's why I suggest we remove this flag
for now.
Anyway, I believe I've clearly made my point on this issue as input to
the IESG. If the security ADs are fine with the operation of the S
flag, I won't insist on this point.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
