Subject: Proxy ND?

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 10:44:02 -0800

A quiet IETF mailing list two weeks before a meeting is a real luxury, so I am
reluctant to distrurb the peace, but here goes.

Anybody want to describe how to secure Proxy ND? The CGA address gives the
recipient of the NA the assurance that the sender is authorized for the source
address, but not the target address in the packet.

            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: Fri, 07 Mar 2003 22:06:03 +0200

> address, but not the target address in the packet.

Good question.

Technically, if the proxy and the true owner of the address share a
security association (as in MIPv6), this node could give an authorization
cert to the proxy. The proxy NA would carry the following information:

- PKnode (as usual)
- target address, where IID = hash(PKnode,...) (as usual)
- cert for PKproxy, signed by SKnode (this is new)
- signature of the NA, signed by SKproxy (new signer)

Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 14:00:43 -0800

I think you mean:

    > PKnode (as usual)
    > source address, where IID=hash(PKnode,...)  (as usual)

or? (see below for rest).

> - cert for PKproxy, signed by SKnode (this is new)

Is this an X.509 cert? If so, it might be pretty big. Also, I think it has to
contain the PK of the SKnode, otherwise the receiver can't check the CGA on the
target address.

and here:

    > target address, where IID=hash(SKnode,...)

            jak

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Mar 2003 11:34:39 +0200

> or? (see below for rest).

Hmm.... no, I don't think so. At least when MIPv6 HAs act as ND
proxies, they set the source address to the home agent's address
and its the target address that matters. See draft 21, section 10.4.1.

I haven't thought of whether this breaks some of the IPsec
processing rules we have. Have you?

> contain the PK of the SKnode, otherwise the receiver can't check the CGA on the

I was assuming it contains the PK as well. Yes, it could be big.
Actually, it might make sense for such certs to be distributed using
the DC mechanisms than in the AH packet itself.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 16:02:10 +0200 (EET)

> - signature of the NA, signed by SKproxy (new signer)

Considering a link protection solution without CGA, it is likely that a
lot of traffic (at least) initially will follow a path similar to the
proxy-ND case .. so this is probably *not* just a corner case to be dealt
with, but a critical piece of the infrastructure.

It seems likely that nodes will have to authorize the router to act on
their behalf when initiating communications to another node in the subnet
they don't have any prior association with.

In this way, if we can make all nodes trust the router(s), in some
fashion, we can build up the SEND infrastructure from there.

(this was probably fairly obvious to the w.g., but here goes anyway.. :-)

-- 
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: Jari Arkko <[email-masked]>
Date: Sun, 09 Mar 2003 10:45:32 +0200

> fashion, we can build up the SEND infrastructure from there.

Interesting idea. In a way, this happens when the router and the
first node are upgraded to SEND: everyone else sends their ND
packets to the router, and all communications of the one SEND
node come through the router. The SEND node believes it is the
only node on the link. The other nodes are not on the link,
and ND is not used for communicating with them. Just like
any other node in the Internet.

Obviously, the non-SEND nodes will not authorize the router
or the router will not authorize them in any way. These are
existing nodes. So for that we don't need secure proxy ND.

But I guess your question is if we can simply provide SEND
for the RD part, and build secure ND from that? For instance,
since the host trusts the router's keys, it would believe an
NA sent by the router for a peer. The tricky part is, however,
getting the router to believe the peer. And it needs to, otherwise
sending an NA signed by the router would be pointless. With
delegation chain discovery, all hosts can trust the router. But
how to get mutual trust? This seems harder, basically something that
would require host certs or CGA. And if you have those, is
there a need for the router to act as a mediator?

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Mar 2003 20:36:47 +0200 (EET)

> any other node in the Internet.

Yep.
 
> or the router will not authorize them in any way. 

Yes, but if that'd help, the SEND router could perform certain proxy
functions on behalf of the SEND node for non-SEND nodes; naturally,
certain functions are already necessary, but some others (e.g. the router
might not believe some types of messages used for ND spoofing or other
attacks) could also be added if that'd be of any help.  Might get too
complicated, though..

> These are

Agree.
 
> for the RD part, and build secure ND from that? 

Yes.

> For instance, since the host trusts the router's keys, it would believe
> an NA sent by the router for a peer. The tricky part is, however,
> sending an NA signed by the router would be pointless. With delegation
> chain discovery, all hosts can trust the router. But how to get mutual
> trust? This seems harder, basically something that would require host
> certs or CGA. And if you have those, is there a need for the router to
> act as a mediator?

In particular, all the SEND nodes might not have shared roots -- it might
be difficult to have everyone trust everyone else.  The approach here is
secure proxy-ND.  However, this could be made a bit more streamlined:
there has to be a trust relationship with the router and host A.  The
router could (maybe, can't estimate the complexity and the overhead),
certify to node B that node A is a "good guy", which might help in
building an association with node A and B.

It seems (quick thinking) to me that the approach for host-host
communication could be one of:

 1) CGA
 2) secure proxy-ND through router
 3) router certifying host A to host B and vice versa: assistance in
delegation chain discovery between the hosts if they don't have shared
roots.
 4) fallback to insecure ND or the like if two hosts have no shared roots
(ie. operational imperative to "get enough roots and certificates!")

However, the SEND protocol is quite unclear to me yet on how exactly the
certifying process even between a router/host would work without CGA.  In
particular, it seems some certificatetied to certain global and even
link-local addresses which the other party can verify is needed.  This
brings up the question how that kind of certifying process could be done
(particularly the link-local part, which seems like something only the
admin of the link could be able to give -- which would lead to either a
trivial or a very difficult solution).

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 15:44:11 -0800

> processing rules we have. Have you?

Since there is no cryptographic tie between the frame address and the IP
address, the host doing proxy ND can set the IP address on the packet to
whatever it wants.

> the DC mechanisms than in the AH packet itself.

Yes. Also, the cert could be self-signed if the host isn't provisioned, since
provisioning of hosts is the hard case currently.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 11:17:43 -0800

Jari,

> there a need for the router to act as a mediator?

Suppose instead of securing ND, SEND simply turns it off. That is, a node
establishes a security association with the router and routes all packets
through it, regardless of whether they are on the local link or not. So the
NS/NA messages are never sent for routing purposes.

One issue I can see with this is with DAD. We would have to specify some way for
router to do that. I suppose we would have specify some changes to the Neighbor
Cache, so that hosts owning addresses (and can prove ownership) renew them like
DHCP leases do by sending periodic NAs to the router. The router would have to
do proxy ND.

As for mutual trust, I agree this is an issue. It would require that hosts be
provisioned with their own certificates, something that has so far escaped the
Internet world. If CGAs are used, the router can know that the host is
authorized to use the address.

But this seems like a pretty big change to RFC 2461, so it would be better if we
could avoid it.

            jak