Subject: [dhcwg] comments on draft-vijay-ipv6-icmp-refresh-otherconf-00

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 16:31:48 +0200 (EET)

Hi,

Vijay wanted me to look at these, so blame him.. Comments below ;-)

substantial
-----------

First, I note that the document talks about "administered protocol".  This
is interesting, if you want to have this procedure also work if you'd use a
different protocol than DHCPv6 to get information (e.g., another DNS
discovery method, etc.).  But this little detail should probably be
discussed in a couple of sentences in a new paragraph in the introduction.

Second, as the other DHCPv6 reconfigure protocol
(draft-vijay-dhc-dhcpv6-mcast-reconf) is limited to stateless DHCPv6 only,
how does this interact with stateful DHCPv6?  That is, I guess the
assumption is that stateful DHCPv6 uses reconfigure messages, not these
signals?  Should that be made explicit?  (note that the stateful DHCPv6
reconfigure messages may have different security requirements/assumptions)

....

   This option SHOULD NOT be sent in RAs, if O bit is unset.

==> is it worth spelling out what happens if it is sent even so?  Maybe not?

   Once this option is enabled in RA, it SHOULD appear in the subsequent
   RAs for a minimum time period for better reliability.  This time
   SHOULD be configurable in the routers.  If it cannot be configurable,
   then RAs SHOULD contain this option till the routers are triggered to
   send this option with a new Transaction-id or to disable the option.

==> make it clearer what you mean by the last sentence.  It could be read
that if it isn't configurable, the option should be included forever, only
with new Transaction-id's..?  Maybe just 2-3 times to all nodes is enough?

   3) In this case, either the DHCPv6 or the administrator will trigger
   the routers to send RAs with Refresh Other Configuration Option.
   The RAs can be retransmitted as per the retransmission mechanism
   specific to DHCPv6 for reliability.

==> DHCPv6 on its own doesn't trigger anything -- right?  Administrator is
making the change, which is reflected by DHCPv6 -- which might cause sending
out these messages (if you use the DHCPv6 counterpart of the spec, which is
not given).  Maybe a bit of reword here?

9. Security Considerations

==> this section fails to mention the reason why DHCPv6 reconfigure messages
must be authenticated, and why these messages should also be authenticated. 
That is, if you are able to get a window of opportunity for e.g., MitM for a
while, being able to get all the clients to reconfigure, pointing at you,
creates a new security threat (when, before, you'd have to wait if someone
happened to reconfigure during that attack time window).  So, being able to
initiate reconfiguration at will on all the nodes of the link adds to the
security threats.

editorial
---------

     ND Support to trigger the nodes refresh the other configuration

==> uppercase the first chars, like:

     ND Support to Trigger the Nodes Refresh the Other Configuration

(I guess ND would have to be spelled out here -- and the name made shorter,
if possible.)

Abstract

   Neighbor Discovery for IPv6 [RFC2461] provides a way by which the

==> no references in the abstract!!

1.  Introduction

==> please split the looooong paragraph to 2 or more!

   nodes MUST ignore this option and they MUST not invoke the
   administered protocol to refresh their configuration.

==> s/MUST not/MUST NOT/

Security issues regarding the Neighbor
   Discovery protocol are being discussed in IETF SEND [SEND] WG.  It  
   can be used once it is ready.

==> SEND WG has almost concluded the work, working on WG LC issue
resolution, so this statement could probably be a bit more positive than
this.

  [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander,
      "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt,
      June 2003. 

==> it's draft-ietf-send-ndopt now

Full Copyright Statement

==> include IPR statement here as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Vijayabhaskar A K <[email-masked]>
Date: Mon, 22 Mar 2004 21:54:34 +0530

Hi Pekka

Thanks for your comments

>Vijay wanted me to look at these, so blame him.. Comments below ;-)
Ok fine. Will add more details

>how does this interact with stateful DHCPv6? 
>
Its true that multicast reconf protocol will be used only for stateless 
dhcpv6, but it can be extended to use in the stateful dhcpv6 also

> That is, I guess the
Thats the reason why it is not explicitly mentioned.

>==> is it worth spelling out what happens if it is sent even so?  Maybe not?
Ok. Will add.

>with new Transaction-id's..?  Maybe just 2-3 times to all nodes is enough?
Good point.. The text needs to be modified to "If it cannot be 
configurable, then RAs SHOULD contain this option for fixed X (may be 
2-3 as you said) number of times, till a new reconfiguration is 
triggered (identified by new xid)  or to disable the option"

>==> DHCPv6 on its own doesn't trigger anything -- right?  
>
Correct

>Administrator is
Ok fine

>initiate reconfiguration at will on all the nodes of the link adds to the
Since it is explained in DHCPv6 spec, I thought its ok to not mention 
it. Will put some words here

>==> include IPR statement here as well.
All the editorial comments looks fine, I will update. Thanks for your 
comments

Vijay