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

From: Thomas Narten <[email-masked]>
Date: Thu, 15 Sep 2005 11:44:53 -0400

I'm sending this to the int-area because the concerns I have are
broader than the just the ipv6 WG. This document is really about
bridging/proxy arp in general, and it does not restrict itself to
IPv6; it also covers IPv4.

I've read this document a couple of times (it is on the IESG's plate
to review), but have general concerns. I wonder if others in the
community share my concern.

The bottom line is that I think the IPv6 portion of document/protocol
is both under-specified and too broad in scope and I worry that there
are a lot of potential gotchas lurking. I also worry that it will
break some of our standards track protocols. And if it gets widely
implemented, we'll have to deal with the resultant mess. We have
plenty of experience in IPv4 with proxy arp, and some of it has been
unpleasant.

I have the following meta concerns:

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

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.

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

	One limitation of this rule is that if the authentication
	protocol for DHCPv4 described in [DHCPAUTH] is used, only
	clients that set the BROADCAST flag themselves will be able to
	use DHCPv4 through the proxy.

If this document breaks some forms of DHC, that needs to be noted up
front and more visibly. I also think more discussion would be
appropriat here, to be sure we fully understand the issue here.
Again, I'm also not sure we should be promoting documents that cause
problems for existing standards track protocols.

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. That way the end site wouldn't need a separate prefix
(say if the ISP as stingy and didn't want to give it out). I had
always assumed this configuration was a simple star topology with the
access router at the center.  Indeed, the current IPv6 charter says:

> - Develop Proxy Neighbor Discovery solution for prefix delegation
>   and publish. This enables a simple site border router to
>   re-advertise downstream a prefix it hears on its upstream link.

The WG had such an item in its charter for a long time (years), but
from what I can tell, there was limited interest in terms of actually
doing the work, so it languished. What "the WG" finally produced was
the above document. But it's scope is quite a lot broader than what
the charter called for. And, I think its fair to say that the work
reflects a small number of contributers (with good intentions) but
apathy and almost no help from the rest of the WG (e.g., the last WG
LC received no comments). So, this document is going through the
process by default, rather than being a strongly reviewed piece of
work.

Margaret (as AD) raised a similar point about the scope of this work
in the WG a few months back.  For details, review the discussion
during the WG last call in May: (sorry, I can't find a a good URL to
point to -- sigh). There was hardly strong support for the document,
and in fact, the reviews were negative and the document was taken off
standards track and put on experimental in response to that thread.

In summary, I believe  there are good reasons why the document in its
current form should not be published with an IETF blessing.

Some possible options:

1) Drop the work completely. This may not be as silly as it seems. A
   basic premise of this work is that its somehow not possible (or too
   hard) to get a proper prefix delegated from an ISP. However, there
   is little evidence that this will be a real issue in IPv6. Current
   RIR address allocation polcies and existing ISP practices is to
   give out chunks of address space (rather than /64s), or a single
   address. 

2) Move all the IPv4 material to a separate document (this should be
   done in any case if work on this continues). Also, the IPv4
   material would need serious  review from the IPv4 community.
   
3) Pull out all the more general bridging stuff for the IPv6 case and
   just solve the narrow problem described earlier, namely a single
   router acting as a star/hub for proxying.

4) Add an IESG note with a warning that this has potential issues and
   the IETF doesn't recommend widespread adoption/use. (Indeed, the
   current applicability statement is really weak and gives
   insufficient guidance in terms of where this technology can safely
   be used)

And what I'd _really_ like to see, more than anything else, is strong
support from the community both for scope of this document and the
details of what are contained in the document. In the absence of that,
if the document is published, I'd like to see a strong note adequately
characterizing the issues above.
   
Thomas

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Sep 2005 15:47:12 -0700

Thomas,

I share your concerns about this draft. At a minimum, pulling the IPv4 
specification out of the draft seems appropriate.

My particular concern, though, is with the lack of support for security. 
When SEND was finalized, we had some very vague ideas about how to do proxy 
ND security which didn't seem ready for standardization. Now, after about a 
year and a half of discussion in IRTF/MOBOPTS, I think we are beginning to 
have some firmer ideas about how SEND could be extended to proxy ND. If the 
WG decides that it would like to continue working on this and decides that 
security is important, we could bring some of the IRTF/MOBOPTS work into 
IETF.

            jak

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Sep 2005 16:46:00 -0700

Hi Thomas,

I am the "shepherding chair" on this document and feel I should 
respond.  Also, it seems to me that these comments should have also been 
sent to the authors.  I forwarded your email to them and added them to the 
cc: list.  I hope they are included in further discussion.

>plenty of experience in IPv4 with proxy arp, and some of it has been

It's important to add that the w.g. after a lot of discussion, decided to 
move this forward as an Experimantal RFC.  It's not standards track.

>Recommendation: remove the IPv4 material and place in a separate

I personally, don't disagree.  The part I care about is the IPv6 part, but 
I also didn't see any technical problems with the IPv4 portions, so we 
didn't push to remove it.  I also don't agree that the people who have 
reviewed this don't understand IPv4.

>point out that it is incompatable with SEND, e.g., an IESG note.

This was discussed extensively in the working group.  The argument is that 
SEND doesn't support proxies that are allowed by ND.  This is discussed 
fairly extensively in the security considerations section.

However, I wouldn't object to a stronger mention that it doesn't mix with SEND.

>problems for existing standards track protocols.

This would be another reason to remove the IPv4 parts.

>the WG has tuned out and no longer is following the work.

I don't agree.  There are people who think this approach is useful.

>standards track and put on experimental in response to that thread.

This certainly isn't a document with a giant amount of energy behind it, 
but I think it does serve a useful purpose.  The specific scenario you 
describe of a star is where the interest is and it does do that.  The 
current draft has been pared way down in response to comments.

>    give out chunks of address space (rather than /64s), or a single

One important scenario is the mobile phone with a link behind it.  This 
provides a simple mechanism to share a single /64 prefix.  It's transparent 
to the upstream and avoids the need to allocate and provision multiple 
prefixes.  Isn't one /64 enough for a mobile phone :-)

>    material would need serious  review from the IPv4 community.

I think my preference would be to remove the IPv4 parts all together.

>    router acting as a star/hub for proxying.

I think most of the remaining proxy stuff is for the case when multiple 
proxies are combined inadvertantly.  This seems good to me.  The simple one 
bit mechanism seems like a good solution to this.  I don't think this 
should be removed.

>    insufficient guidance in terms of where this technology can safely

Please suggest text.

Thanks,
Bob

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Sep 2005 08:33:32 +0300

Bob Hinden wrote:

> This was discussed extensively in the working group.  The argument is 
> that SEND doesn't support proxies that

I remember this discussion.

> are allowed by ND.  This is discussed fairly extensively in the 
> security considerations section.

I recently reviewed this document again, and found out that the
non-requirements section does not mention SEND support at all
(even if it talks about IPsec support for ND). It also seems that
the security considerations text should be revised and make a
clearer explanation of the limitations, as well as what the
SEND "mixed mode" implications are.

These problems could be fixed, of course, and I have sent e-mail
to the authors with suggested new text.

> However, I wouldn't object to a stronger mention that it doesn't mix 

I think this is what is needed as a minimum. We might also
consider what James suggested (perhaps as another work
item, not tightly integrated with this draft).

--Jari

---

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.

> Recommendation: remove the IPv4 material and place in a separate

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..)

> 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,

This is moot if v4 parts are removed.

> 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

---

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: 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: 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: Joe Touch <[email-masked]>
Date: Wed, 21 Sep 2005 11:07:45 -0700

Roger Jorgensen wrote:
> On Tue, 20 Sep 2005, Joe Touch wrote:
> 
>>Danny Mayer wrote:
>>
>>>Brian E Carpenter wrote:
>>>
>>>>Jari Arkko wrote:
>>>>...
>>>>
> 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.

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

---

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

-- 

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