Subject: draft-ietf-v6ops-addr-select-ps-01.txt and draft-ietf-v6ops-addr-select-req-02.txt WGLC

From: Fred Baker <[email-masked]>
Date: Wed, 20 Jun 2007 16:35:52 -0700

This is to initiate a two week working group last call of draft-ietf- 
v6ops-addr-select-ps-01.txt and draft-ietf-v6ops-addr-select- 
req-02.txt. Please read these now. If you find nits (spelling errors,  
minor suggested wording changes, etc), comment to the authors; if you  
find greater issues, such as disagreeing with a statement or finding  
additional issues that need to be addressed, please post your  
comments to the list.

We are looking specifically for comments on the importance of the  
documents as well as its content. If you have read the documents and  
believe them to be of operational utility, that is also an important  
comment to make. If you have read them and think they miss an  
important consideration, that is very important.
<?xml version="1.0" encoding="UTF-8"?>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2007 14:28:18 +0200

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.

 > 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?

What does the last sentence mean? Does it mean that ingress
filtering needs to be implemented at the first-hop router?

     Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 25 Jun 2007 16:33:31 +0900

Hi Brian,
thank you for your comments.

> 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.

> first sentence that this threat requires address-selection messages

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.

> 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.

Best regards,

--
Arifumi Matsumoto
    IP Technology Expert Team
    Secure Communication Project
    NTT Information Sharing Platform Laboratories
    E-mail: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2007 16:34:49 +0200

On 2007-06-25 09:33, Arifumi Matsumoto wrote:
> 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.

> 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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 26 Jun 2007 15:11:04 +0900

Hi, 

> 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.
-----

> 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-masked] ?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 11:56:53 +0200

>  selection control, it must not interfere with the existing routing

Yes thanks, OK for me.

> what I have to do is to send an e-mail to [email-masked] ?

I'm not sure... maybe best if the WG Chairs ask for an early
review.

Thanks

     Brian