Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Sep 2005 14:31:34 +0300 (EEST)

(FWIW, I think ND proxies are useful and needed.)  Some comments 
inline.  Adding ipv6 WG.

On Thu, 15 Sep 2005, Thomas Narten wrote:
> 1) I do not believe the material on IPv4 ARP proxy should be
> included. It is not in-scope for the IPv6 WG to be developing it, and
> any document on proxy ARP in IPv4 really requires review from the
> broader community. AFAIK, that review has not taken place.
>
> Recommendation: remove the IPv4 material and place in a separate
> document

v4 part is said to reflect what one implementation does, but I guess 
even for Informational, that info might be too much.  I guess it could 
be taken out of fleshed out in a separate spec (if anyone is 
interested in documenting proxy-arp behaviour..)

> 2) This document breaks SEND (but does not say this clearly). I have
> doubts that we should be publishing documents that break our standards
> track protocols (especially ones that we believe are important). Or at
> the very least, if it is published, very strong wording is needed to
> point out that it is incompatable with SEND, e.g., an IESG note.

Wording could be enhanced, but I do not think this document should be 
blocked by the missing SEND details.

> 3) this document may have implications for DHC. In particular,
> document says:

This is moot if v4 parts are removed.

> 4) The history of this document is troubling, and I believe it does
> not have strong support from the WG. Rather, I'd characterize this as
> an effort that has gotten this far mostly because the vast majority of
> the WG has tuned out and no longer is following the work.
>
> The history of this effort (though I may be biased) is that the IPv6
> WG desired a simple proxy mechanism for the following case. Suppose
> one has an access router connecting to an upstream ISP, and that link
> is assigned a prefix (say X). It would be nice if the access router
> could readvertise that prefix (say for a home network), acting as a
> simple bridge.
...
> But it's scope is quite a lot broader than what
> the charter called for.

I'm not sure if I understand your comment.  Are you saying the ND 
proxy spec is too complicated?

Well, I myself suggested removing the spanning tree loop prevention 
from the draft completely (now it has a bit in the RAs) because it 
wasn't needed in the applicability we had in mind.  But folks that 
didn't like ND proxy argued that infinite loops are not nice, even in 
illegal configurations, so we're stuck with some additional 
specification.

How would you like to see it simplified?  Do you have an alternative 
in mind?

(To me, ND proxies seems "as simple as it can get" excluding loop 
prevention which I argued for removal but folks thought the failure 
modes were too dangerous..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Sep 2005 14:46:47 +0200

People might want to look in the tracker at the other comments
that have come up.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12623&rfc_flag=0

     Brian

Pekka Savola wrote:
> be taken out of fleshed out in a separate spec (if anyone is interested 
> in documenting proxy-arp behaviour..)
> 
> I'm not sure if I understand your comment.  Are you saying the ND proxy 
> spec is too complicated?
> 
> Well, I myself suggested removing the spanning tree loop prevention from 
> the draft completely (now it has a bit in the RAs) because it wasn't 
> needed in the applicability we had in mind.  But folks that didn't like 
> ND proxy argued that infinite loops are not nice, even in illegal 
> configurations, so we're stuck with some additional specification.
> 
> How would you like to see it simplified?  Do you have an alternative in 
> mind?
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Sep 2005 16:44:48 +0300

> blocked by the missing SEND details.

Well, what we can discuss is whether there needs to be some SEND
support before the document can go forward. But there's actually
three issues in the SEND support:

o Sufficiently clear documentation that this does not work with
SEND. Personally, I found the security considerations section
lacking in this respect. The tracker seems to indicate the
section was not clear to others either.

Suggested text sent to the authors.

o There may be a need to specify or at least explain how this
works in a SEND mixed mode scenario; ideally we'd like to
downgrade (not just fail) to plain old ND if SEND doesn't
work through this. It appears that this can be made to work,
but it would be very useful to document this. This does
not require much effort, and again, text has already been
sent to the authors.

o Whether we actually want to define a secure approach to
proxies. Here I'd personally be OK even with no security
for proxying, as long as the above issues were corrected.
But you could also argue the other way; the IETF usually
does require mandatory-to-implement security mechanisms
to go with its protocols.

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2005 11:12:55 +0200

Jari Arkko wrote:
...
> to go with its protocols.

I'd be a bit concerned if I could, for example, walk into
my neighbour's apartment, hop to his wireless LAN, and
find myself getting proxy ND from a third neighbour I'd
never met, without some sort of AAA process. But for
an Experimental draft we can't really insist on a solution -
for me the question is whether the warnings are sufficient.

    Brian

---

From: Danny Mayer <[email-masked]>
Date: Tue, 20 Sep 2005 12:11:54 -0400

> for me the question is whether the warnings are sufficient.
You don't even need to leave your apartment to do that. It's scary how 
insecure people's wireless LAN setups are.

Danny

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Sep 2005 10:31:50 -0700

> insecure people's wireless LAN setups are.

Your 'insecure' is some people's 'plug and play' for their visitors.

While I don't always agree with it, it's not clear it's not an equally
desirable outcome.

Joe

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 21 Sep 2005 19:59:45 +0200 (CEST)

> While I don't always agree with it, it's not clear it's not an equally

I'm not 100% in the loop on this topic But, IF it's optional to have no 
security, that's okay, but default should always be security. 
that is, not possible to walk into someones appartment like described 
above without the owner have himself configured it like that.

-- 

------------------------------
Roger Jorgensen              |
[email-masked]        | - IPv6 is The Key!
http://www.jorgensen.no      | [email-masked]
-------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Sep 2005 11:07:45 -0700

> above without the owner have himself configured it like that.

If the default configuration is 'security required' then the default
behavior is likely to be 'won't operate until completely configured'.

It's a trade-off - and what's the expense?

Joe

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Sep 2005 14:03:30 -0700

> modes were too dangerous..)

The suggestions on the IPv6 list in the past was to keep the bit in the 
RA so that complex topologies (which might have loops) can be detected, 
but not include any attempt for the proxies to work when there is a 
loop. Thus a proxy would not use downstream interface where there is 
another proxy advertising RAs with the bit.

That would be sufficient to handle the scenarios in the document.

    Erik