[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-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 be
able 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?

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 selection
problems 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 these
security 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 :-)

  Brian