Subject: Comments on draft-ietf-send-psreq-03

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 06 Oct 2003 10:12:52 +0530

Hello,

I went over the draft during the weekend, and jotted down few comments.

CP

Technical comments
-------------------

 1. Threats for a L2-switch, and ND-proxies. L2-switches, and ND- proxies
    build their neighbor cache by snooping the source IPv6 address, and
    the corresponding link-layer address. It is possible to send fake
    NS/NA/RA/RD/redirect/Data (any packet which is used to build the
    neighbor cache), and do a redirect/DOS attack.

    I think section 4 should list a threat concerning such devices.

 2. Flood DoS is described in section 4, but none of the attack is listed
    as "Flood DoS". I haven’t evaluated the attacks for this one, but a
    quick scan shows that 4.1.1 qualifies as Flood DoS.

 3. Section 4.2.1.
       a. What is the "entering node"?
       b. I might be a bit confused - isn’t the section referring to the
          first-hop router? Can you also give the reference number to a
          section number in RFC2461 talks of this threat?
       c. The 3rd paragraph talks of RFC 2461, and 2462. Is there a
          conflict between these two documents? I am not able to
          understand why the default router selection procedure in
          section 6.3.6 needs a rule that concerns with the lifetime of
          the router.

 4. Mention the type of attack in section 4.2.2.

Editorial comments
------------------

 5. Reorganize the text concerning threats in section 4. The flow of text
    for all the text is not similar. It hampers readability, and it is
    difficult to identify the missing pieces. For example, section
    5.1.2 does not mention the type of attack.

    My suggestion is that the text for each threat should be
    divided amongst the following headings. (More headings may be
    headed as required)
------------------------------------------------------------------

THREAT DESCRIPTION

<Describe the threat>

TYPE OF ATTACK

<DOS or Redirect/DOS??>

EXTENSIONS

<In what ways can the attack be extended? If the type of attack is 
different for each extension then mention that.>

MESSAGES INVOLVED

<List the messages that are involved in the threat, and 
its extensions.>

THREAT ANALYSIS AND SOLUTIONS

<Analyze the threat for each model. Describe solutions if available, 
and provide a reference for each known solution wherever possible.>
------------------------------------------------------------------

As an example let me rewrite the threat listed in Section 4.1.3.

------------------------------------------------------------------
THREAT DESCRIPTION

   In networks where the entering hosts obtain their addresses using
   stateless address autoconfiguration [4], an attacking node could
   launch a DoS attack by responding to every duplicate address
   detection attempt made by an entering host.  If the attacker claims
   the address, then the host will never be able to obtain an address.
   The attacker can claim the address in two ways: it can either reply
   with an NS, simulating that it is performing DAD, too, or it can
   reply with an NA, simulating that it has already taken the address
   into use. This threat was identified in RF2462 [4].

TYPE OF ATTACK

   DoS.

EXTENSIONS

  None.

MESSAGES INVOLVED

  NS/NA

THREAT ANALYSIS AND SOLUTIONS

  1. Model 1. This attack is not a concern if access to the link is
     restricted to trusted nodes; if a trusted node is compromised,
     the other nodes become exposed to this DoS threat.

     Solution : The operator may act as an authorizer, keeping track
                of allocated addresses and making sure that no node
                has allocated more than a few (hundreds of) addresses.
                On the other hand, it may be detrimental to adopt such
                a practice, since there may be situations where it is
                desirable for one node to have a large number of
                addresses, e.g, creating a separate address per TCP
                connection, or when running an ND proxy.  Thus, it may
                be inappropriate to suggest that ISPs could control
                how many addresses a legitimate host can have; the
                discussion above must be considered only as examples,
                as stated in the beginning of this draft.

  2. Model 2, and 3. This attack can be performed in both these
     models, as there is no trust relationship between the nodes.

     Solution : The node performing DAD is able to verify whether the
                sender of the NA response is authorized to use the
                given IP address or not. <References?>

     Solution : For model 3, one may want to structure the addresses
                in such a way that self authorization is
                possible. <References?>
------------------------------------------------------------------

    I found it a bit tedious to correlate the "+,-,R" symbols in the 
    trust columns with the actual threat description. After the rewrite, 
    it should be easy to do that.

 6. Abstract. Rephrase the last sentence to "The output forms a clear
    problem statement and a set of requirements for Securing IPv6
    Neighbor Discovery."

 7. Section 4.2.5, 3rd paragraph.

    s/finite system/system with finite resources/

 8. Section 4.2.6. 5th paragraph.

    s/target link will get all replies/target link may get replies/

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 15 Oct 2003 12:42:00 +0300

Dear Chirayu,

Thanks a lot for your comments, and sorry for not answering
earlier.  Our only excuse is that there is a procedural
problem with your comments, and we have requested advice from
the ADs.  We are still waiting for the reply.

The problem is that the psreq draft has already passed the
IESG review, I have already resolved the minor issues that
they had, and now the draft is waiting for their acceptanse
on the resolutions.  In other words, the draft is fairly
long on its way to become an RFC.

Based on the that status, and the fact that the draft does not
specify a protocol but is only informational, we are inclided
to reject your editorial suggestion #5 as a too large one.
While it might be good, its doesn't warrant the required new
review.   What comes to the other editorial comments, let

 >     problem statement and a set of requirements for Securing IPv6

The last sentence has already been changed, as per IESG request.

 >     s/finite system/system with finite resources/

IMHO the concept of "finite system" is well enough defined.
As an informal indication, google finds about 8500 uses of it.

 >     s/target link will get all replies/target link may get replies/

I changed this to read "target link may get a large number of replies".
Thanks for catching this.

>     I think section 4 should list a threat concerning such devices.

While your intention is good, I think that any such work should be
left for future.  There has been some discussion about these kinds
of use scenarios before.  However, only maybe a couple of people have
shown real interest on working on those problems, and so far we have
seen no real, concrete input.

If you are interested, maybe you could write a new -00 draft, and
submit it as an individual draft.  If there is interest in continuing
the SEND work once the current work has been completed, such input
would be very valuable.  In any case, if the draft is high quality,
it may be interesting enough to be published as an Information RFC
even without a working group.

Currently our plan is to close the SEND WG as soon as the current
wg items are completed.

>     quick scan shows that 4.1.1 qualifies as Flood DoS.

The structuring of the introduction in Section 4 and the rest of
section 4 is different.  We have not really made a difference between
flooding DoS and other types of DoS in the rest of section 4.
Maybe we should have such distinction, but at least I am not willing
to do it at this stage any more.  Sorry.

>        a. What is the "entering node"?

Well, a node attempting to discover a router is most probably
a new node entering to the link.  I readily admit that the text
is not very clear.  If you could propose how to revise the text,
that would be great.

>           section number in RFC2461 talks of this threat?

The text has been inherited a few times.  I would need to read RFC2461
carefully in order to find out which section it is.  But, yes, it would
be good to add a reference to the specific section.

Does anybody else remember right away?

>           section 6.3.6 needs a rule that concerns with the lifetime of

I am not really an expert on the differences between 2461 and 2462.
Could somebody else provide an answer?  If good enough, I can add
it to the draft (if the IESG approves, of course).

>  4. Mention the type of attack in section 4.2.2.

Good catch.  It is mostly a DoS attack, but could also be used
to redirect (to the next better router).  Added.

A pre-release of the updated draft, with the resolutions to the IESG
issues and your concerns, is available at

http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.txt
http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.html
http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.xml

The changes are highlighted in

http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15-diff.html
http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15-chbar.txt

--Pekka Nikander