Subject: New version of draft-ietf-send-psreq to be posted

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Nov 2002 14:49:15 +0200

Bill, Jari, Pekka,

I'll be posting a revised version of the psreq draft
in a few days.  In the meanwhile the revised version
is available at

http://www.tml.hut.fi/~pnr/publications/draft-ietf-send-psreq-01-pre.txt

If you have time it would be excellent if you can have
a look to see if your concerns have been addressed.

--Pekka Nikander

--------------------------------------------------------------------
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 Savola <[email-masked]>
Date: Thu, 28 Nov 2002 20:16:01 +0200 (EET)

> a look to see if your concerns have been addressed.

Thanks for the quick update.

A few more substantial comments:

 1) is there a need to clarify the stance wrt. the use of encryption
somehow?

 2) perhaps this:

   This threat is partially mitigated in RFC2462; in Section 5.5.3 of
   RFC2462 it is required that if the advertised prefix lifetime is
   less than 2 hours and less than the stored lifetime, the stored
   lifetime is not reduced unless the packet was authenticated.

should be augmented by the fact that as per RFC2461 6.3.6 there is no such
2-hour-rule for _default router selection_ (it is unclear which parts 
of the threat the "partial mitigation" refers to).

 3) 

   | 4.2.4 | Bogus on-link prefix       | RD  | DoS   | RA    | - | + | R 

==> with the new threat addition, I believe this is also a problem in the 
first case.

 4) it's a bit cornercase whether 4.2.5 could be counted as + in the first 
case, at least if we assume the DynDNS vulnerability to be possible?

Editorial:

==> references are a bit out-of-date, no biggie (at least MIP_TH, DHCPv6, 
ABK)

     1. A model where all authenticated nodes trust each other to
        behave correctly at the IP layer and not to send any ND or RD
        messages that contain false information.

==> RD has not been defined yet.

   For example, it might still be acceptable that a compromised node
   is able to launch a denial-of-service attack, but it is undesirable
   if it is able to hijack existing connections or establish
   man-in-the-middle attacks on new connections.

==> reword: s/if it is/to be/ ? (sorry..)

   This threat involves Neighbor Solicitation and Neighbor
   Advertisement messages.

==> s/messages//

   This attack can be extended into a redirect / man-in-the-middle
   attack if the attacker replies to the Neighbor Solicitations with
   spoofed Neighbor Advertisements, thereby luring the nodes on the
   link to send the traffic to it or to some other node.  

==> should "man-in-the-middle" be removed -- I think all redirect attacks 
can be used for MITM?

  There is also a related possibility of advertising the a target
   prefix as an autoconfiguration prefix on a busy link, and then have
 
==> s/the a/the/

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 29 Nov 2002 13:08:51 +0200

>  1) is there a need to clarify the stance wrt. the use of encryption

Jari proposed this too.  This is covered in Section 7 in [MAN-SA].
I just don't know how to include it sufficiently briefly.  For now
I've just added a reference to [MAN-SA] in the end of Sect 4.

Maybe we should publish [MAN-SA] as informational, too?

> of the threat the "partial mitigation" refers to).

Added the following text:

    However, the default router selection procedure, as defined in
    Section 6.3.6. of RFC2461, does not contain such a rule.

> ==> with the new threat addition, I believe this is also a problem in the 

Actually no, IMHO.  The redirect version of 4.2.4 requires NA/NS 
spoofing.  If we prevent NA/NS spooring, 4.2.4 alone is reduced to DoS 
only (or is it?).  Anyway, I added the following footnote to the table:

   1) Note that the extended attack defined in 4.2.4. combines sending
      a bogus on-link prefix and performing NS/NA spoofing as per
      4.1.1.  Thus, if the NA/NS exchange is secured, the ability to
      use 4.2.4. for redirect is most probably blocked, too.

> case, at least if we assume the DynDNS vulnerability to be possible?

I agree that this is a borderline case.  On the other hand, I'd like
to see a genuine host-zeroconf design for the corporate intranet case.
That is, I'd like to make it possible to plug in a host to a corporate
intranet without any configuration (just as today), and let it work
securely even in the case that another host is compromised *later*.
I'm not sure if we can easily protect against this without any host
config.

Note that IMHO router config is perfectly OK even in the corporate
intranet case.

> ==> references are a bit out-of-date, no biggie (at least MIP_TH, DHCPv6, 

Fixed, tnx.

> ==> RD has not been defined yet.

Fixed.

> ==> reword: s/if it is/to be/ ? (sorry..)

I think that the current wording is less ambiguous (and still 
grammatically correct).

>    This threat involves Neighbor Solicitation and Neighbor

I give up and sacrifice readability to uniformity.  Fixed.

> ==> should "man-in-the-middle" be removed -- I think all redirect attacks 

Ditto.

>    prefix as an autoconfiguration prefix on a busy link, and then have

Fixed.

--Pekka

---

From: Pekka Savola <[email-masked]>
Date: Sat, 30 Nov 2002 18:35:47 +0200 (EET)

> I've just added a reference to [MAN-SA] in the end of Sect 4.

IMO, section 7 of [MAN-SA] is not specific to manual ICMP SA's and should
be removed to either separate draft or here.  There might be more, other
generic security discussion there.

Perhaps Jari might have an opinion?
 
> Maybe we should publish [MAN-SA] as informational, too?

btw. s/drat-/draft-/g
 
>       use 4.2.4. for redirect is most probably blocked, too.

Agree.
 
> I'm not sure if we can easily protect against this without any host

Agree -- I really don't have ideas how to deal with this case.  IMO, nodes
should not just blindly register addresses, but whether they do it (like
that) is another issue.  Perhaps another footnote..
 
> Note that IMHO router config is perfectly OK even in the corporate

Agree.
 
> I think that the current wording is less ambiguous (and still 

Ok by me. :-)