On 2007-06-26 08:11, Arifumi Matsumoto wrote:
Hi,On 2007-06-25 09:33, Arifumi Matsumoto wrote:Hi Brian, 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 protocols > and RFC 4191 [RFC4191]. If the address-selection mechanism is used > with a routing mechanism, the two mechanisms has to be able to work> synchronousely. 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 beable to have capability of next-hop selection as well as address selection. 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 mechanisms. -----
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 problems,> such as session hijack. However, we should note that address-> selection is ultimately decided by nodes and their users. There are > no means to enforce a specific address-selection behavior upon every> end-host from outside of the host. Therefore, a network > administrator has to take countermeasures for unexpected address > selection. 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 selectionproblems and also on the network environment. For example, if the mechanism allows a host to receive control messages only from routers in his subnet and his network isn't open to the public, authentication may not be necessary.In this section, we described general security issues that can have effect on the solution mechanisms. We didn't mention how to protect against thesesecurity risks, because we thought it depends on the mechanisms and network environment.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 secdir@mit.edu ?
I'm not sure... maybe best if the WG Chairs ask for an early
review.
Thanks
Brian