Subject: RE: Request to Advance: <draft-ietf-ipv6-ndproxy-00.txt> [RESEND]

From: "Dave Thaler" <[email-masked]>
Date: Mon, 31 Jan 2005 16:00:04 -0800

Catching up on email...

I will go through the rest of last weeks responses over the next day or
so.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Erik Nordmark
> Sent: Monday, January 24, 2005 9:26 AM
> To: Brian E Carpenter
> Cc: Thomas Narten; Margaret Wasserman; Brian Haberman; IPv6
> Subject: Re: Request to Advance: <draft-ietf-ipv6-ndproxy-00.txt>
[RESEND]
> 
> Brian E Carpenter wrote:
> >  > First, lets keep in mind that this is an Informational document.
> >
> > I wonder whether Experimental wouldn't send a clearer signal
> > that there is some doubt about the viability of the solution.
> 
> That would be better than informational.

I have no objection.

> But I still think the document should say "MUST prevent loops; SHOULD
> run IEEE 802.1D to prevent loops" and then talk about cases when the
> protocol is not needed. 

I agree.

> The one example we have is the case of PPP (e.g.
> to a GGSN) where the probability of a loop would be very small, so in
> that particular case there is no need for 802.1D (and there might be
> other examples, but the 802.11 scenario in the document isn't one of
> them).
>
> > I can see how this could be very useful in certain types of
> > network environment, and publishing as Experimental will allow
> > people to share experience and try to fix the open questions.
> 
> ok
> 
> > Since the deployment future of SEND is unknown, I don't think
> > it's appropriate to block this work because of SEND.

Right.  As Brian pointed out, proxy ND is already part of RFC 2461,
and it's already PS.  It's also still in draft-ietf-ipv6-2461bis-01.txt
which is targeted for DS.

The fact that SEND doesn't yet support proxy ND is not specific to
this specification, it's something for SEND to solve.

I'll respond to other points in subsequent email.

-Dave

> Yes, but at least the document should be internally inconsistent and
not
> claim in section 3 that working with SeND is a requirement, even
though
> it doesn't work with SeND.
> 
>     Erik
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 Jan 2005 17:49:49 -0800

> this specification, it's something for SEND to solve.

The general case of proxy ND, which this specification uses, can not 
provide any security against MiTM because by definition the proxy is a 
MiTM. Thus it is completely unreasonably to assume that SeND will solve 
this.

There are specific cases of proxy for SeND can be extended, that have 
the property that there exists a security relationship between the host 
and the proxy. An example of this is a MIP home agent. In such a case 
one can extend SeND to allow for the mobile node to delegate its key 
(somehow) to the home agent.

But with ndproxy you both want things to be transparent to the hosts, 
and you want the ndproxy proxies to rewrite the ND packets. You can't do 
that and prevent other nodes (aka attackers) from forging ND packets.

Thus any secure solution in this space requires at least one of:
1. that the host be modified to have a secure relationship with the
    proxy
2. that the proxies do not modify the ND packets

Note that #2 can be done, but it requires that the proxies be able to 
receive packets addressed to any MAC address (just like bridges do).

This is very much analogous to Ralph's comments about DHCP.

So expecting SeND to provide security when by design you need MiTMs in 
the proxies isn't truth in advertising about this protocol.

    Erik