Subject: [dhcwg] comments on draft-hirotaka-dhc-source-address-selection-opt-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Mar 2005 08:42:16 +0900

I've read the draft, and have the comments below.

In short, while I understand the motivation from off-list talk with
authors, I still have several fundamental questions.  If I were to ask
for raising my hand, I'd not be able to support this document as a wg
item as yet.

Substantial comments (or questions)

1. at least from this document, it's not clear whether we really need
   this kind of generic DHCPv6 option.  In particular, the assumption
   in section 6 that ISP1 doesn't have global connectivity while ISP2
   does seems very artificial.  I cannot understand why we are
   suddenly led to this example.

   If this option is useful for a general multihome case, the draft
   should first discuss that case (rather than the odd-looking
   unbalanced example).  But it does not seem to be the case to me (or
   at least it's not clear to me).

   What happens if both ISP1 and ISP2 have global IPv6 connectivity?
   Can this option help something in this case?

   On the other hand, assume neither ISP1 nor ISP2 has global IPv6
   connectivity.  Then isn't it enough to let the "longest-matching"
   rule of RFC3484 do the job for avoiding the trap of ingress
   filtering?

   I also have a question from yet another point of view.  In the
   "unbalanced" example of Section 6, the essential information for
   the "user router" seems the fact packets to A::/32 should be sent
   to ISP1 and others (including ::/0) to ISP2.  This is, in essence,
   just routing information.  Since we already need some kind of
   routing information in the typical PD usage, I don't see the need
   for the redundant information baring the new DHCPv6 option.

   BTW: in the case of the PD usage, the "assigned" prefix (e.g.,
   A::/48) should be provided in the PD framework, so this information
   in the SASP option seems redundant.

   I see we may need some new mechanism between the user router and
   end nodes in order to relate the routing information (e.g., the
   default route is the path to ISP2) to source address selection
   rules, in order to avoid the ingress filtering trap.  But, in this
   case, I think we only need a single mechanism, whether it's DHCPv6
   or RA.  Remember that even an end host that configures addresses by
   stateless address autoconfiguration may still need DHCPv6 for
   getting (recursive) DNS server addresses.  Similarly, even an end
   host that configures addresses by DHCPv6 will still need RAs to get
   on-link prefixes.  So, a single mechanism would be enough for
   providing source address selection rules, whether it's RA or
   DHCPv6, and whether receiving node uses RA or DHCPv6 for address
   configuration.

   BTW: the source address selection problem with ingress filtering is
   exactly what one of general multihoming issues.  So, one may ask
   for discussing this in the context of (e.g.) multi6 wg.  We'll at
   least need to be asked why we cannot use solutions being considered
   in multi6.

Semi-substantial comments

2. the scenario described in this draft seems to assume (perhaps
   implicitly) that the user router can get all the prefix information
   (from ISP1 and ISP2) at once.  However, the PD procedures with the
   ISPs should in general be asynchronous events.  So, the user router
   should somehow deal with the asynchronous information for providing
   consistent rules with end nodes.  It's not very clear from the
   current draft on how the user router behaves wrt this concern.
   (Perhaps this is not a serious issue...I'm just not sure about this
   from the current text)

3. In section 6, the draft says:

   o  End nodes set up their IPv6 addresses by using a stateful DHCPv6
      function or receiving router advertisement message.  They also
      request the SASP option by transmitting Information-Request
      messages to the router.

   But if the end node uses DHCPv6 for address set-up, it should also
   be able to get the SASP option in this procedure; I don't see why
   the node needs to transmit Information-Request in this case.  (But
   see also the more fundamental question above).

4. Also in Section 6,

   o  When the requesting client detects a change in a delegated address
      or address prefix, it requests the Source Address Selection Policy
      option again.

  This statement is not very clear to me.  What is the "requesting
  client" in this context?  Is it the user router, a end node, or
  both?  (Perhaps the definition in Section 3 is not very clear in the
  first place)  Also, how does it "request" the option again?

5. In section 7,

   A malicious DHCPv6 client may be able to mount a denial-of-service
   attack by sending repeated requests for the Source Address Selection
   Policy option, thus exhausting the DHCP server's resources.

I'm not really sure about the point of this statement.  What kind of
"server's resources" are concerned here?  Since the SASP is quite
stateless, shouldn't the "malicious" client consume further
"resources" such as address/prefix pools?  Or, does this sentence
considers the processing load at the sever side?  But if so,

   To guard against attacks, both DCHP clients and servers SHOULD use
   DHCP authentication, as described in section 21 of RFC 3315,
   "Authentication of  DHCP messages."

I don't think this is very accurate.  A malicious client can still
bother the server, consuming the server's resource of processing load,
by sending repeated requests with bogus authentication information.

Editorial comments

6. In section 1, second paragraph
   s/packet- forwarding/packet-forwarding/

7. there's a mixture of "usable" and "useable" in the second bullet of
   Section 6.  This should be consistent.

8. In section 7, last paragraph
   s/"Authentication of  DHCP messages."/"Authentication of DHCP messages."/
   (there's a redundant white space)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 10 Mar 2005 13:57:42 +0900 (JST)

Junmei-san,

Thank you for reading our draft in detail.

 | Substantial comments (or questions)
 | 
 | 1. at least from this document, it's not clear whether we really need
 |    this kind of generic DHCPv6 option.  In particular, the assumption
 |    in section 6 that ISP1 doesn't have global connectivity while ISP2
 |    does seems very artificial.  I cannot understand why we are
 |    suddenly led to this example.

We believe that the closed network example is not artificial.  There
will be some cases that users want to use multiple connections
simultaneously, such as global connectivity and VPN,  and global
connectivity and some kind of ASP services (Video streaming, IP Phone
and maintenance of home appliances). Actually, some implementation
of IP phone already uses closed network model.

 |    If this option is useful for a general multihome case, the draft
 |    should first discuss that case (rather than the odd-looking
 |    unbalanced example).  But it does not seem to be the case to me (or
 |    at least it's not clear to me).
 | 
 |    What happens if both ISP1 and ISP2 have global IPv6 connectivity?
 |    Can this option help something in this case?

CPE router can inform nodes which prefix should be used to a
destination prefix (in this situation, CPE router will inform
the nodes which uplink is selected as default).

 |    On the other hand, assume neither ISP1 nor ISP2 has global IPv6
 |    connectivity.  Then isn't it enough to let the "longest-matching"
 |    rule of RFC3484 do the job for avoiding the trap of ingress
 |    filtering?

Basically yes. 

However, end user network knows assigned prefix information only
and it has no information abut other prefixes that upstream ISPs
may have. This may be covered if routing information is available,
but in this case, other problem will occur (I'll describe below). 

 |    I also have a question from yet another point of view.  In the
 |    "unbalanced" example of Section 6, the essential information for
 |    the "user router" seems the fact packets to A::/32 should be sent
 |    to ISP1 and others (including ::/0) to ISP2.  This is, in essence,
 |    just routing information.  Since we already need some kind of
 |    routing information in the typical PD usage, I don't see the need
 |    for the redundant information baring the new DHCPv6 option.

There are some cases that address selection policy cannot be created
from the routing information.

For example, 
 - a router that advertise routing information and a DHCP-PD server is
   the different node.

 - a DHCP-PD server wants to assign multiple prefixes that have
   different selection policy.

In these cases, it is generally impossible to make relationships
between routing information and assigned prefix.

 |    BTW: in the case of the PD usage, the "assigned" prefix (e.g.,
 |    A::/48) should be provided in the PD framework, so this information
 |    in the SASP option seems redundant.

If the DHCP-PD router assigns only one prefix, it may be surely
redundant to have the prefix value in SASP option.  But it is
necessary to keep the relation of assigned prefix and SASP policy,
when it delivers multiple prefixes and multiple policies.

 |    I see we may need some new mechanism between the user router and
 |    end nodes in order to relate the routing information (e.g., the
 |    default route is the path to ISP2) to source address selection
 |    rules, in order to avoid the ingress filtering trap.  But, in this
 |    case, I think we only need a single mechanism, whether it's DHCPv6
 |    or RA.  Remember that even an end host that configures addresses by
 |    stateless address autoconfiguration may still need DHCPv6 for
 |    getting (recursive) DNS server addresses.  Similarly, even an end
 |    host that configures addresses by DHCPv6 will still need RAs to get
 |    on-link prefixes.  So, a single mechanism would be enough for
 |    providing source address selection rules, whether it's RA or
 |    DHCPv6, and whether receiving node uses RA or DHCPv6 for address
 |    configuration.

Well, I think I have to look into more about this issue, whether DHCP
is always vital for every node or not.

 |    BTW: the source address selection problem with ingress filtering is
 |    exactly what one of general multihoming issues.  So, one may ask
 |    for discussing this in the context of (e.g.) multi6 wg.  We'll at
 |    least need to be asked why we cannot use solutions being considered
 |    in multi6.

Surely, ingress filtering issue in multiple global network connectivity 
environment is multi6 matter. Our proposal can solve this issue as I
stated above, and I believe that our proposal can go well with the 
coming multi6(shim6) new proposal for the hints of source address selection.

Actually, we made a presentation at multi6 meeting in DC, and multi6
chairs advised us multi6 does not target the closed network case.

 | Semi-substantial comments
 | 
 | 2. the scenario described in this draft seems to assume (perhaps
 |    implicitly) that the user router can get all the prefix information
 |    (from ISP1 and ISP2) at once.  However, the PD procedures with the
 |    ISPs should in general be asynchronous events.  So, the user router
 |    should somehow deal with the asynchronous information for providing
 |    consistent rules with end nodes.  It's not very clear from the
 |    current draft on how the user router behaves wrt this concern.
 |    (Perhaps this is not a serious issue...I'm just not sure about this
 |    from the current text)

This asynchronous behavior doesn't lead to such a serious trouble,
I agree that I have to mention about it too.

 | 3. In section 6, the draft says:
 | 
 |    o  End nodes set up their IPv6 addresses by using a stateful DHCPv6
 |       function or receiving router advertisement message.  They also
 |       request the SASP option by transmitting Information-Request
 |       messages to the router.
 | 
 |    But if the end node uses DHCPv6 for address set-up, it should also
 |    be able to get the SASP option in this procedure; I don't see why
 |    the node needs to transmit Information-Request in this case.  (But
 |    see also the more fundamental question above).

Absolutely. I'll correct it soon.

 | 4. Also in Section 6,
 | 
 |    o  When the requesting client detects a change in a delegated address
 |       or address prefix, it requests the Source Address Selection Policy
 |       option again.
 | 
 |   This statement is not very clear to me.  What is the "requesting
 |   client" in this context?  Is it the user router, a end node, or
 |   both?  (Perhaps the definition in Section 3 is not very clear in the
 |   first place)  Also, how does it "request" the option again?

I fully agree that this sentence is surely ambiguous.

What I wanted to say is:

- a prefix and a source address selection policy is strongly bound.
- when a prefix is invalidated, the corresponding source address 
  selection policy also has to be invalidated.

We'll rewrite this part.

 | 5. In section 7,
 | 
 |    A malicious DHCPv6 client may be able to mount a denial-of-service
 |    attack by sending repeated requests for the Source Address Selection
 |    Policy option, thus exhausting the DHCP server's resources.
 | 
 | I'm not really sure about the point of this statement.  What kind of
 | "server's resources" are concerned here?  Since the SASP is quite
 | stateless, shouldn't the "malicious" client consume further
 | "resources" such as address/prefix pools?  Or, does this sentence
 | considers the processing load at the sever side?  But if so,
 | 
 |    To guard against attacks, both DCHP clients and servers SHOULD use
 |    DHCP authentication, as described in section 21 of RFC 3315,
 |    "Authentication of  DHCP messages."
 | 
 | I don't think this is very accurate.  A malicious client can still
 | bother the server, consuming the server's resource of processing load,
 | by sending repeated requests with bogus authentication information.

We will also rewrite security consideration section.

 | Editorial comments
 | 
 | 6. In section 1, second paragraph
 |    s/packet- forwarding/packet-forwarding/
 | 
 | 7. there's a mixture of "usable" and "useable" in the second bullet of
 |    Section 6.  This should be consistent.
 | 
 | 8. In section 7, last paragraph
 |    s/"Authentication of  DHCP messages."/"Authentication of DHCP messages."/
 |    (there's a redundant white space)

Thank you very much.

Yours sincerely,
--
Tomohiro Fujisaki

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Mar 2005 15:19:57 +0900

>>>>> On Thu, 10 Mar 2005 13:57:42 +0900 (JST), 
>>>>> <[email-masked]> said:

> the nodes which uplink is selected as default).

Aside from whether the half-global, half-closed model is realistic or
artificial, I still think there's an issue of document organization.

Introduction of this document begins with general multihoming issue.
But the document then only provides the half-closed example.  It
really confuses a normal reader who does not have any background of a
commercial ISP in some country:-) Possible natural document
organization is thus either (but not limited to):

- begin with general multihoming issues (as the document currently
  is), explain how the proposed option works in the general case,
  *and then* show it can also (particularly) be useful in one special
  case of the half-closed, half-global model.

- concentrate on the half-closed, half-global model only.  begin with
  an explanation of how this type of special multihoming is realistic,
  and show how the proposed option solves this particular case.

The reality consideration is also helpful in the first approach, but I
believe it can be omitted since it's just one special example of a
general issue and solution.

					JINMEI, Tatuya