Subject: Progress on Design

From: "James Kempf" <[email-masked]>
Date: Fri, 1 Nov 2002 09:26:58 -0800

Progress is being made on a strawman design by the SEND design team. The team is
Bill Sommerfeld, Perry Metzger, and Bill Arbaugh. Though we have unfortunately
missed the 00 draft deadline, Perry is working on a draft and the intent is to
have something available prior to the meeting. Perry has also volunteered to
present and lead a discussion at the meeting.

                    jak

--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Sun, 17 Nov 2002 21:53:27 +0200

Hi Pekka,

(This is a 3rd resend. I may have an e-mail problem; hopefully
you didn't receive this many times...)

I read this document on my way to Atlanta. Thanks for
writing it, it looks very good!

I do have a few comments though:

   - The consequences of sending packets to the wrong address
     on the link aren't fully described in 4.1.1. It might be helpful
     to adopt the upper-layer-security-present-or-not distiction,
     if you remember we did that back in manual-icmpv6-sas-01...

   - 4.1.1 s/attack results/attack succeeds/

   - In 4.1.1 the subnet router anycast address capture
     attack: Perhaps you should clarify that attackers
     can see all such communications in any case, but
     what this attack does is that it prevents the
     real nodes from receiving the traffic.

   - In 4.1.2 you talk about the NUD attack. You say
     that communications can be disrupted for a long
     time. Isn't it the case that we can only spoof
     NUDs in the case that the node in question isn't
     really up? So the effect that we get is that
     the sender believes the peer is up when he really
     isn't. The effects of this depend on the specific
     application. Sometimes this has no effect since
     the communications would have been lost anyway.
     Sometimes a user could have been told about the
     problem, or an alternate server tried.

   - In 4.1.3 you suggest that the operator could act as an
     authorizer for DAD. Without seeing further details I'm not
     yet convinced we can do this. What specifically does the
     router do to effect this? Does the router have to know
     the mac address of the client, and are you assuming the
     mac addresses can't be faked? Or perhaps this was a part
     of the trusted operator case definition. And if the
     router can do all this and limits the addresses to some
     number, will that help victims if the number of victims
     is less than this number?

   - 4.2.1 last paragraph: You say that there are no solutions
     for the ad hoc case. It may be the case there are no
     perfect solutions, but there appears to be at least
     partial solutions if we assume an SA to a known peer
     in the Internet. (I don't think such assumption precludes
     calling the local network ad hoc.)

   - In 4.2.3 you say that there are no solutions for the
     Redirect problem in the ad hoc case. Again, I believe
     there's at least a partial solution that relies on
     address ownership proofs and comparison of the source
     address of the Redirect to our current routing table
     for the offending address.

   - In 4.2.4-5 isn't this attack also a potential mitm attack?

   - The attack described in paragraph 2 of 4.2.5 is really
     interesting! I guess this could also be used as a bombing
     attack against the real owner of the prefix?

     There's a related possibility of advertising the victims
     prefix as an autoconf prefix on a busy WLAN link, and
     then have all nodes on this link try to communicate
     to the external world with this address. If the local
     router doesn't have ingress filtering on, then the victim
     will get all the replies for those initial communication
     attempts.

   - The attack in 4.3.1 is also really interesting and
     possibly serious. OTOH, some care in using the caches
     in implementations should fix this, assuming the
     implementation knows which side of the network is
     the Internet and which one is local. Of course the
     attack can come from either side, but www.cnn.com
     probably doesn't want its internal ND made inoperational
     by outside attackers.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 17 Nov 2002 17:31:14 +0200

Hi Pekka,

Jari