Answers in line
Arifumi Matsumoto wrote:
Ray,
thank you for your comments.
On 2012/02/22, at 2:56, Ray Hunter wrote:
I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks.
Some comments.
1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status "single-homed"
and "only one upstream line" is time dependent. A highly-mobile device may have a
semi-permanent 4G uplink, and a temporary wifi uplink dependent on the user's current location.
Whether a new Address Selection Policy table is installed or not should not depend primarily on the
order that the interfaces are brought up.
If we think about the routing table, the entries related to a certain network
interface will also be added and deleted, when the interface goes up and down.
So, it seems to me that this issue is not too new, or strange for implementors.
My concern is that the guidance in this draft is not correctly
formulated IMHO.
I agree that incorrect use of the addr-select-opt may lead to a security
issue, in that node-global behavior is affected by the proposed option.
Thus traffic intended for interface 1/ network 1 may be misdirected to
interface 2 / network 2 by receiving an address-selection policy option
from network 2.
However, this security risk is not directly correlated to the number of
active interfaces at the time the policy is received IMHO.
In some situations I can think of, you may well want to trust a
particular DHCPv6 server to configure a link address on an interface,
plus maybe some hints about which name servers or time servers to use to
set up an initial connection, but not to set a policy for which address
ranges and hence interfaces to select for which traffic. Even receiving
policy information over one active interface may not be considered a
reasonable risk by some e.g. if a second interface is brought up later
(e.g. a tunnel), and (some of) the old policy information from the first
interface is not flushed because that first interface is still up and
the second interface does not provide a policy update.
In a corporate environment, it may well be desirable to receive policy
updates on multiple interfaces without having to explicitly configure
this, because all updates ultimately have been derived from a trusted AS
source.
Therefore I think the risk is more closely related to the consistency
and provenance of the DHCPv6 derived address selection policy
information i.e. whether the device is receiving the option from more
than one Autonomous System simultaneously, or from an AS source that is
not trusted.
I'd be happy if the draft contained a warning of the risk, without
getting into details of how to mitigate the risk in implementation.
2) Suggest splitting transport of policy/configuration information from actual
use of the policy/configuration information by the end node. I'm thinking of
how routers may have multiple sources of routing information (derived from
various sources: static, RIPng, OSPFv3) but they may only install subsets of
the total known information into the single active forwarding table using local
policy configuration concepts such as Administrative Distance and locally
defined route filters.
Do you suggest splitting them into different documents, or just defining the
transport information format and leaving others to implementation dependent ?
I do not see much value in just dividing this into two documents. It just makes
it troublesome to understand this mechanism.
Regarding the latter case,
IMO, this mechanism is so new, and no operational experiences are gained by
administrators, implementors, and so on. So, we first have to propose the
expected /recommended way to use this mechanism. If you find the current
specification goes beyond recommendation in some points, please tell it to me.
I humbly suggest considering which WG is appropriate for defining which
portion of the overall mechanism. There seems to be a very large overlap
with MIF, and one possible way to handle this would be to have the pure
transport of the option defined in your 6man draft (which I guess could
be pretty non-contentious), and defining the use of the information in
the MIF workflow. Another option might be simply to co-post the draft to
the MIF WG.
<snip>
I think it is a matter of implementation, and common for several other DHCPv6
options.
It may be helpful for implementors, but this document should not be the right
place for this generic issue.
Thanks !
Agree. This is off topic for your draft, but maybe someone will take up
the generic challenge in another draft.
<snip>
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
