Subject: Re: WG Last call on draft-ietf-send-psreq-01

From: Alper Yegin <[email-masked]>
Date: Mon, 03 Feb 2003 17:58:52 -0800

Hello,

Here are some comments/questions based on my review...

My understanding is that, there are two areas that needs to be
worked out. First one is how to secure ND using IPsec when all the
required SAs are already manually configured. I'd think the details
will be worked out in the SEND WG. Secondly, if there are no
pre-configured SAs, the methods to generate them (i.e., bootstraping)
needs to be defined. I think at this point PANA may be used as a building
block, but the details about how to turn a newly generated trust relation
(e.g., a shared secret) into the required IPsec Sas need to be worked out.
Is that a fair understanding of the scope of the work? If so, I think this
should be clarified in the document.

Section 3.1:
   "However, none of the currently standardized
   automatic key distribution mechanisms work right out-of-the-box.  For
   further details, see [10]."

It'd be good to expand on this statement. Especially what is missing
with the current mechanisms, and if and how SEND will fix them.
As I understand, there is not separate requirements draft, therefore
setting the scope of the work in this document is needed.

Section 3.2:
  "The link layer authentication protocol MAY allow the
   client nodes and the access router to create a security association.
   Notice that there exists authentication protocols, e.g., variants of
   EAP, that do not create secure keying material and/or do not allow
   the client to authenticate the network."

L2 authentication protocol may create a trust relation between the client
and the L2 access device, which is not generally same as the access
router. 

  "Even if the underlying link layer is aware of all the nodes' link
   layer addresses, and is able to check that no source addresses were
   falsified, there may still be vulnerabilities."

I'm not sure if L2 access device checking source IP address to
prevent such atttacks are practical. Are there any such solutions?

  "That is, the router would check ICMPv6 packet contents, and
   filter packets that contain information which does not match the
   network topology."

This approach has limitations, because not in all networks an
access router is a MitM to inter-host communication (e.g., multi-access
links).

Section 4.1.1:
   "In the case just the operator is trusted,
   the nodes may rely on the operator to certify the address bindings
   for other local nodes."

Are there existing solutions like that, or is this just a speculation
that one can develop such a solution? If the draft is going to talk
about solutions, it should clarify their status (available, possible,
etc...)

Section 4.2.1:
   "However, the threat can be partially
   mitigated through a number of means, for example, by configuring the
   nodes to prefer existing routers over new ones."

But this itself is very limiting, as now you cannot introduce a new router
to the network. (I'm not sure if visiting these possible approaches in
this draft is a good idea, because at times they open up such additonal
questions. These require more analysis that can be done later.)

Section 4.2.6:
       "2.  The attacker implements a bogus DHCPv6 server or relay and the
       'M' and/or 'O' flag is set, indicating that stateful address
       configuration and/or stateful configuration of other parameters
       should be done.  The attacker is then in a position to answer the
       stateful configuration queries of a legitimate host with its own
       bogus replies."

The draft should point out if "secure" dhcp can be a solution.

Section 4.3.1:
   "In a way, this problem is fairly similar to the TCP SYN flooding
   problem.  Rate limitating Neighbor Solicitations, restricting the
   amount of state reserved for unresolved soliciations, and clever
   cache management may be applied."

I'm not sure this solves the problem, because this still starves the
legitimate users. I think this discussions is not appropriate for this
draft. It's too much solution oriented.

Section 4.4:

   "+  The threat is present and at least one solution is known"

This gives the impression that there is a fully-working standard
solution to the problems. But I think what we really mean is that
there are some candidate proposals that require further analysis.

alper 

On 1/23/03 9:32 AM, "James Kempf" <[email-masked]> wrote:

> WG Last Call on draft-ietf-send-psreq-01.txt starts today and runs for two
> weeks, until Feb. 6. This draft is intended to be a comprehensive security
> analysis of threats to Neighbor Discovery as it currently exists today in RFCs
> 2641 and 2642, according to three different trust models that group current
> network deployments into three different equivalence classes. As such, it
> functions as a requirements template for the SEND design team.
> 
> It is *extremely important* that this draft be read and commented on by the WG
> prior to submission to the IESG. Please make an effort to review the draft
> within the Last Call period, and submit any comments to the mailing list or
> the
> editor (Pekka).
> 
> Text, HTML and XML versions of the draft
> are available at the interim web page:
> 
> http://www.tml.hut.fi/~pnr/SEND/
> 
> The HTML version is directly available at:
> 
> http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-01.html
> 
> The draft was submitted to the IETF drafts respository today and should show
> up
> there shortly.
> 
>           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
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2003 21:59:34 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:
    Alper> My understanding is that, there are two areas that needs to be
    Alper> worked out. First one is how to secure ND using IPsec when all the
    Alper> required SAs are already manually configured. I'd think the details
    Alper> will be worked out in the SEND WG. Secondly, if there are no

  I think that I missed something (which is very likely, since I've been
skimming). The ND is a broadcast. How can you have a shared secret among a
group and still consider it a secret?

  Or is this just to talk to the/a router?

  So, yes, I think that this is a problem.
  
    Alper> pre-configured SAs, the methods to generate them (i.e., bootstraping)
    Alper> needs to be defined. I think at this point PANA may be used as a building
    Alper> block, but the details about how to turn a newly generated trust relation
    Alper> (e.g., a shared secret) into the required IPsec Sas need to be worked out.
    Alper> Is that a fair understanding of the scope of the work? If so, I think this
    Alper> should be clarified in the document.

  This second part - turning something you got from PANA into a IPsec level
keying material is either just a question of convention (i.e. "use bytes 0-15
as the AES key, and bytes 16-35 as the SHA1 key"), or a matter of some 
entropy expansion (assuming PANA doesn't give you enough bits, but a
reasonable amount of entropy).

  I guess I should go read more.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
--------------------------------------------------------------------
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: Tue, 4 Feb 2003 08:35:11 +0200 (EET)

> setting the scope of the work in this document is needed.

Personally, I'm not sure how much one should go on about solutions, but 
either way works for me.
 
> and the L2 access device, which is not generally same as the access

"L2 access device" could be ambiguous, I think.  Perhaps that should be
expanded a bit.

Consider these cases:

 - node connected to a router
 - node connected to an ethernet switch connected to a router
   (including any L2 bridging mechanisms, such as a WLAN access point 
    working in bridged mode)
 - node connected to a hub connected to an ethernet switch, ...
 - ...

Are all of the first ones in these lists L2 access devices?

> access router is a MitM to inter-host communication (e.g., multi-access

In most, it's not, but if such a mechanism is adopted, it might be 
possible to emulate a virtual link like that.
 
> about solutions, it should clarify their status (available, possible,

I'm not sure I think expansion on solutions here is a good idea.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Feb 2003 08:43:40 -0800

Alper,

Please look at the charter for SEND. There is no intent to do anything with
manual SA configuration or key sharing. The intent is to use a reserved IPsec
identifier for a public key cryptographic algorithm that can be used to verify
the AH headers. The protocol work is focussing on extensions to the ND/RD
protocols to allow authorization of credentials for authenticating NA and RA
messages. Also, some work on backwards compatibility with existing ND.

The exact relation with PANA and DHCP is under discussion. The ADs suggested we
co-ordinate with the chairs. We've been discussing an algorithm for credential
authorization based on well-known and highly deployed credential distribution
techniques, such as are used with SSL, that might be useful for securing DHCP as
well. We are not sure what the relationship with PANA might be, but we are
certainly open to discussion with the chairs.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Tue, 04 Feb 2003 10:21:26 -0800

> group and still consider it a secret?

Symmetric keys or asymmetirc keys might be used. I think first question is,
if you have the right keying material in the right place, how do you use it.
Second one is, how do you get the keying material there...

(I think shared secret among a closed group is still a secret :)

> reasonable amount of entropy).

At least some guidlines are needed. A secret delivered/derived by the
authentication method might have to be used with IKE to create the SAs.

alper

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPj8slYqHRg3pndX9AQFwsgP9EC7iU4w7ShqAZ4fK1kw1ouLaW5ICLxFE
> HI5Skv3CMwAfwNnkozixTpLlDHgrqBAvHAXv+vgOC/GPwg+3D2b/iq1YM3UMDAhZ
> 8x/kMmuZIpxkmyFADUCUIz6DmKqg5eJ9p4t0L2/5T5pVU/zcFvnKOpyp3tXJ3LQN
> n6L2a0a5G2U=
> =IvDU
> -----END PGP SIGNATURE-----

---

From: Alper Yegin <[email-masked]>
Date: Tue, 04 Feb 2003 10:27:23 -0800

> Are all of the first ones in these lists L2 access devices?

Except the last one..  L2 access device and the first hop router may
or may not be co-located, as you illustrated above.

> I'm not sure I think expansion on solutions here is a good idea.

What I mean is, if the draft is going to mention solutions, it should
also give some idea about whether they are standard solutions
(preferably with a reference), ad-hoc solutions, or possible solutions
one might develop (pending lots of details being worked out). Or else,
we cannot make a good assesment of what level of attention should
be given to each problem...

alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 04 Feb 2003 10:52:31 -0800

James,

> messages. Also, some work on backwards compatibility with existing ND.

I didn't mean to imply symmetric cryptography actually. Symmetric or public,
once we have the right keying material in the right places, the details on
how they will be used to secure ND is needed. And I think specifying a
reserved IPsec id etc. is a part of this.

The other component is, how do we get the keying material to the right
places.  Second item in the charter specifically mentions a key distribution
protocol.. 

> certainly open to discussion with the chairs.

In order to "assure authenticatable distribution of public keys" in the
access network, you somehow need to rely on a trust relation between
the node and the access network. That relation can be potentially created
by PANA when the client requests access to the network.

alper