[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-addr-select-ps-01.txt and draft-ietf-v6ops-addr-select-req-02.txt WGLC
On 2007-06-26 08:11, Arifumi Matsumoto wrote:
On 2007-06-25 09:33, Arifumi Matsumoto wrote:
thank you for your comments.
Brian E Carpenter wrote:
I think this is useful work. I have no substantive comments
on draft-ietf-v6ops-addr-select-ps. I have a couple of
concerns with draft-ietf-v6ops-addr-select-req-02:
> 2.8. Next-hop Selection
> The mechanism can control next-hop-selection behavior at hosts or
> cooperate with other routing mechanisms, such as routing
> and RFC 4191 [RFC4191]. If the address-selection mechanism is
> with a routing mechanism, the two mechanisms has to be able to
Do we really want to mix these two issues? Wouldn't a better design
be to say that RFC 4191 *is* the solution to control next-hop selection
and choice of source address? Then the constraint here is only to allow
simultaneous usage with 4191.
Some mechanisms that are already proposed to us or to WG seem to be
able to have capability of next-hop selection as well as address
So, we didn't yet narrow down to the simultaneous usage with the
existing routing mechanisms.
I think we should do so. Surely we don't want to create a situation
where address selection interferes with RFC 4191?
Our point of this requiremt item is that when you think about a solution
mechanism for address selection problems, you also have to consider
about the interaction with next-hop selection. This is because it is
not uncommon that address selection problem and next-hop selection problem
occur at the same place.
At the same time, I understand your concern about the interference.
So, how do you think about the following sentence for this item ?
2.8 Next-hop Selection
As it is often the case that address selection problem and next-hop
selection problem occur at the same place, the simultaneous usage with
a routing mechanism, such as routing protocols and RFC 4191 [RFC4191],
has to be considered and supported.
Therefore, even if the mechanism itself has a capability of next-hop
selection control, it must not interfere with the existing routing
Yes thanks, OK for me.
This is a hard problem, as we know from the exit router selection
discussions in multi6/shim6. It is mixed up with traffic engineering
questions, ingress filtering deployment, and probably other things.
> 3. Security Considerations
> Incorrect address-selection can lead to serious security
> such as session hijack. However, we should note that address-
> selection is ultimately decided by nodes and their users.
> no means to enforce a specific address-selection behavior upon
> end-host from outside of the host. Therefore, a network
> administrator has to take countermeasures for unexpected address
As a threat analysis, this seems a bit weak. Should we say after the
first sentence that this threat requires address-selection messages
to be authenticated?
Protection method depends on the mechanism for solving address selection
problems and also on the network environment. For example, if the
allows a host to receive control messages only from routers in his
and his network isn't open to the public, authentication may not be
In this section, we described general security issues that can have
on the solution mechanisms. We didn't mention how to protect against
security risks, because we thought it depends on the mechanisms and
What does the last sentence mean? Does it mean that ingress
filtering needs to be implemented at the first-hop router?
Yes, I think ingress filter is an effective preventive method.
What I want to stress is that even if the network administrator delivers
address selection policies to every host, he should not believe his
policies is adopted in every host.
I suggest getting a security directorate review immediately,
to see whether that agrees with you or with me :-)
I'm okay with consulting a security directorate.
According to this page http://sec.ietf.org/instructions.html,
what I have to do is to send an e-mail to email@example.com ?
I'm not sure... maybe best if the WG Chairs ask for an early