Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Mar 2004 18:23:20 -0800 (PST)

Sorry for not catching this earlier.

Section 4.1 says
   An ND proxy can also be used to extend a /64 prefix to multiple
   physical links of different properties (e.g, an Ethernet and a PPP
   link).
 
But isn't this solving a non-problem?
Today in IPv4 (where a prefix is delegated to e.g. a SOHO customer)
this doesn't seem to be an issue; either separate addresses are assigned
to the PPP link, or the PPP link ends up being unnumbered.

Why don't those approaches apply to IPv6?

Section 4.1.1 talks of a larger unmanaged network.
But why do we think we need IPv6 specific solutions to this problem?

If IEEE 802 bridges are not ideal maybe either we should tell this to the IEEE,
or pursue the various ideas that where discussed in the ZEROUTER BoF a while
back. Locking us into ndproxy as a solution to a problem that no IETF WG has
carefully looked at seems unwise.

Based on these concerns of mine, I disagree with recommendation #2.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 09:46:29 +0200 (EET)

> Why don't those approaches apply to IPv6?

PPP doesn't support v6 prefix delegation, and there is no will to make
it so.  Does v4 either?  (I'm not sure -- but maybe that's some vendor
extension.)

This approach works in the case where the ISP is advertising you an
IPv6 prefix using RA, and you want to extend it to another subnet.
On the other hand, in IPv4, there are no such advertisements.  Either 
the prefix is delegated somehow, or you use NAT.
 
> But why do we think we need IPv6 specific solutions to this problem?

Because with IPv4 we have NAT.. which is sad but true -- it's used 
precisely in a scenario like this... (Of course, v4 also has 
proxy-arp, but that's used less and less now that there are easier 
solutions such as NAT available..)
 
> If IEEE 802 bridges are not ideal maybe either we should tell this
> to the IEEE, or pursue the various ideas that where discussed in the
> ZEROUTER BoF a while back. Locking us into ndproxy as a solution to
> a problem that no IETF WG has carefully looked at seems unwise.

I don't think we're locking into a solution -- but giving flexibility 
to pick either explicit prefix delegation or ND proxying, whichever 
seems suitable.
 
> Based on these concerns of mine, I disagree with recommendation #2.

What would you suggest as an (easy) replacement for v4 NATs?  ND 
proxying seems like an obvious solution in a scenario like this (that 
is, when pure bridging does not work).

So, I'd appreciate if you could elaborate on this .. and if possible, 
provide text/clarification you'd like to see in the document to bring 
out the concerns better.

-- 
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: Erik Nordmark <[email-masked]>
Date: Fri, 12 Mar 2004 09:56:43 -0800 (PST)

> the prefix is delegated somehow, or you use NAT.

Ignoring the protocol aspects, I have an IPv4 (public) /29 prefix at home and
it seems to work just fine. 

Why does IPv6 need to be different
in this respect? What is broken or missing in IPv4 that needs to be
fixed or added in IPv6?

Before we can answer those questions we shouldn't do anything in this space
IMHO.

> is, when pure bridging does not work).

DHCPv6 prefix delegation takes care of things at the CPE router.

ndproxy also claims to solve the ZEROUTER problem - allowing multiple
links in a small site without any explicit configuration of routers
and without having to bridge everything together.
Firstly this is utterly out of scope for this draft and this v6.
Secondly, it doesn't really solve anything in this space.
Basically the choice is between building ndproxy boxes which can't prevent
loops, or build boxes which implement IEEE 802.1D spanning tree protocol.
In the first case you have ndproxy boxes that, when you plug them together 
at home you can cause the equivalent of persistent L2 loops where packets
circle  forever and never die.
In the second case you end up doing exactly what IEEE 802 bridges do; bridge
the whole network together by defining how to do IEEE 802 over non-802 media.
But as I said, that part is out of scope for this draft. 

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 21:40:48 +0200 (EET)

> in this respect? What is broken or missing in IPv4 that needs to be

I think this seems rather obvious.  IPv4 has NAT, IPv6 doesn't (and we 
hope it won't).

Longer answer: assume that you have a gateway and a host behind it
(or, think of it as two chained hosts, the first of which acts as a
gateway).  A very common home set-up.

Now, let's assume IPv6 ISP would not want to do prefix delegation (for
any of a number of reasons), or the home user wouldn't want to deal
with the mess, or pay for the premium service to get it.

Now, we have a few choices: a) ignore this case, b) develop IPv6 NAT, 
c) use ND proxying to give v6 access, to share the subnet, d) 
something else, what?

> DHCPv6 prefix delegation takes care of things at the CPE router.

Yes -- but still NATs are being used in internal networks.  Prefix 
delegation / routing is applicable to an extent, but doesn't carry you 
far enough (IMHO).

> But as I said, that part is out of scope for this draft. 

Well, this is a nice rant about ND-proxy, but a bit out of scope from
here.  People have no doubt proposed something like ND-proxy in the
ZEROUTER problem space, but if there is overlap, it doesn't really
concern us that much.  The current spec states that spanning tree in
ND-proxy is optional.  I would personally want to get rid of it
altogether, to discourage its use in the more complex setups where it
shouldn't be used in the first place.  But that's beside the point
here.  What folks want is bridge two media together; the work is
already in progress and nearing completion -- it will be pushed out in
IPv6 WG whether we will it or not.  

So, the only choice in this document we have is whether we mention its
usefulness in the specific problem space.  I personally think it may
be useful when the ISP (or you) for some reason doesn't want to do
full prefix delegation.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 Mar 2004 15:44:30 -0800 (PST)

> I think this seems rather obvious.  IPv4 has NAT, IPv6 doesn't (and we 

I think things are a bit more subtle than that.
My house has neither an IPv4 NAT or an IPv6 NAT.
There are products that do IPv4 NAT and (I'm pretty sure) IPv6 NAT.
The issue is under what circumstances one is required hence how
prevalent they become.
In IPv4 NATs are required due to issues related to the size of the
address space, which we've removed as a reason in IPv6.
Unfortunately that doesn't mean that other motivations for NAT go 
away in IPv6 :-(

> with the mess, or pay for the premium service to get it.

If an IPv6 ISP wants to get customers to pay per device/IP address,
why would they hand out a /64 to begin with? They'd just hand out a
/128.
Unfortunately the only technical solution which can handle
that is an IPv6 NAT.
I question the benefit of having a solution for the /64 case that doesn't
handle the /128 case.

> c) use ND proxying to give v6 access, to share the subnet, d) 

If you believe we need to handle the /64 and /128 case, does that mean that
we also should develop workarounds for ISPs that filter port 25 in this WG?
As a standards organization can't prevent ISPs from filtering in whatever
bizarre way that think solves their business needs.

What we can do is specifying standards that make it easy for ISPs and
customers to do things in a way that preserves the transparency of the
network. DHCP prefix delegation is part of that picture.

http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html
is useful reading in this space.

> delegation / routing is applicable to an extent, but doesn't carry you 

The recommendation in RFC 3177 is one way to handle this.
That doesn't solve the ease of having routers autoconfigure inside
the home site. IEEE 802 bridging solves this, and so do some of
the things discussed in the ZEROUTER context.
But as I said this is out of scope of this WG as far as I know.
(Please correct me if I am wrong.)

> here.  

I already stated that it was out of scope in my note.
I take it you then agree that we should remove all mention of ndproxy
from the draft in question since you agree with me that it is out of
scope :-)

FWIW I take exception to you calling my explanation a "rant" - that
is pretty close to an ad-hominum attack IMHO. Perhaps I should complain
about your behavior to the WG co-chairs :-(

> People have no doubt proposed something like ND-proxy in the

Odd - when I was in the IPv6 WG last week there was some discussion
about the fact that ndproxy and SEND can not be made to work together.
(Conclusion seems to be that proxy NA can be secured using SEND in the case
where there is a trust relationship between the host and the proxy, but
there is no such relationship in ndproxy hence it can not be secured.)
The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying
"we really need ndproxy - how do we get SEND fixed" - there seemed to be
almost complete disinterest in ndproxy as far as I could tell.

> be useful when the ISP (or you) for some reason doesn't want to do

I though you said it was out of scope for the v6ops WG above, so it shouldn't
be in the document.

We already have DHCP prefix delegation as a solution to the problem at
the connection to the ISP. How many solutions do we need in this space?

I feel the need to share this quote as this point in time:
  It's perfectly appropriate to be upset.  I thought of it in a slightly
  different way--like a space that we were exploring and, in the early days,
  we figured out this consistent path through the space: IP, TCP, and so on.
  What's been happening over the last few years is that the IETF is filling
  the rest of the space with every alternative approach, not necessarily any
  better.  Every possible alternative is now being written down.  And it's not
  useful.  -- Jon Postel

 Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 09:10:11 +0200 (EET)

> Unfortunately that doesn't mean that other motivations for NAT go 

NAT is used for a lot more than just due to a lack of address space.  
They're also used as security devices (out of scope here), *AND* as an
easy means to extend a subnet.  A common example is a WLAN-capable
router, which is doing NAT.. just because it's a simple thing it can
do.  Similarly, if a host would want to connect to an another host,
and share the prefix (compared to manually delegating another
subprefix to the router?!!), NAT would be the simplest thing to
deploy.

We need to kill that conception.  Bridging is a nice way in many 
cases, and when it doesn't work, ND-proxying appears to 
work just as well.

> I question the benefit of having a solution for the /64 case that doesn't

There is no stopping them if they want to get paid by the /128, of
course.  I'm thinking this from the perspective of the ISP: what's the
simplest thing for them to deploy.  It certainly doesn't seem to be
prefix delegation.  RA-based advertisement on a point-to-point link
seems like an obvious means.  I'm not even sure how one would go about
giving the user a /128 in the first place.

So, what I'm trying to see is the easiest way an ISP could deal with
"basic IPv6 usage case" (seems to be a /64 advertisement), which would
still encourage for the better service (/48 prefix delegation).  The
case where the ISP absolutely wants just support one IP address is out
of scope here.

Another angle here is how are you going to deal with the case where 
you have to have stacked gateways.  E.g., the home gateway is doing 
prefix delegation, and advertising /64's on its links.  One of the 
nodes at home is also a router, and behind it is a host.  How do you 
get v6 to that host behind the node?  That's a very common scenario 
today.  I think it in most cases you could probably move that node to 
the same link, but in some cases (e.g., mismatching media) it might 
not be possible.

> (Please correct me if I am wrong.)

Autoconfiguring router networks inside the home site is IMHO out of
scope here.  But I think the point of ND proxying was precisely the 
fact that IEEE 802 bridging does not work in all the cases.  (And if 
it did, we wouldn't be needing ND-proxy in the first place.)

> from the draft in question since you agree with me that it is out of

I meant that discussing how ND-proxying is applicable in ZEROUTER etc.  
environments appears to be out of scope.  The scenario has identified
one specific case where it is useful.  That is an entirely different
scenario than plugging 5 ND-proxies in the network in any way one sees
fit and assuming they should work just fine (which seemed to be what
you were implying, but I could have read it wrong).

> about your behavior to the WG co-chairs :-(

Discussing the applicability of ND-proxy in ZEROUTER environments
appeared to be rather out of scope here.. because we're not discussing
applying it in those environments.  So, the point of your anti-
ND-proxying note was IMHO well written, but not something that
belonged here -- rather maybe IPv6 WG which is working on ND-proxy.  
Sorry if I called that "ranting"; I don't see that as a too negative
term myself -- perhaps because I feel I'm ranting a lot myself on some
occasions ;-)

> almost complete disinterest in ndproxy as far as I could tell.

Well, I guess I interpreted the silence differently -- I thought "do 
we need SEND in the scenarios we're going to use ND-proxy?"

When you consider the applicability of SEND, it's probably highly
useful in environments like enterprise networks, server farms, etc.  
(in case someone breaks in there and would start hijacking etc.), in
public WLAN (and other) environments where you deal with untrusted
users, and similar cases.

It is probably not so necessary in a home network, or in the
point-to-point link between the ISP and a home network (where the ISP
can DoS/MitM/etc. you in any case).

So, my gut feeling is that people think -- ok, it's fine that ND-proxy 
doesn't work with SEND. Let's not try to fix either SEND or ND-proxy.

The critical issue here, IMHO, is whether the hosts which are unaware
of whether ND-proxy is used or not can enable SEND or not.  That is,
we wouldn't want the vendors to turn SEND off by default if that meant
the hosts would not work with ND-proxy.

I don't think this is the case, but I could be wrong.  I think this
depends on what kind of "triggers" SEND-capable nodes get from the
network before generating CGA addresses etc. -- do the e.g., wait for
the first SEND-enabled RA/NA, or whatever -- or do they always start
immediately (which might be a bit redundant until SEND is commonly
deployed).

(But this is something that should probably go to either SEND or IPv6 
WG...)
 
> I though you said it was out of scope for the v6ops WG above, so it shouldn't

Discussing its applicability in ZEROUTER etc. enviroments is out of
scope, but ND-proxy, in simpler setups, could be in scope here.
 
> the connection to the ISP. How many solutions do we need in this space?

I believe this is a separate problem.

(FWIW, I'd like to have something simpler than DHCP prefix delegation
in any case, maybe along the lines of draft-bykim-ipv6-hpd-01.txt, but
DHCPv6 probably has already gained too much momentum to make it worth
the effort..)

---

From: Fred Templin <[email-masked]>
Date: Mon, 15 Mar 2004 17:54:21 -0800

Erik et al,

>almost complete disinterest in ndproxy as far as I could tell.

Diverting just a bit from the main focus of discussion, another feature
introduced by ND proxying is that the NDproxies can support the path MTU
discovery process when bridging between dissimilar media - this is something
you don't get with  simple L2 bridging. The question I raised at the 
microphone
is whether the currently-specified ICMPv6 "packet too big" message approach
could be trusted, and this morphed into the wider "NDproxy/SEND 
interactions"
discussion referred to in this thread. But, the more specific question I 
didn't get
the chance to ask was whether the ICMPv6 "packet too big" message approach
is the best way to go in the first place?

As has always been the case, the choices for L2 bridges are: 1) silently 
drop
too-big packets (i.e., simple L2 bridging), 2) look into the L3 header 
and send
PMTU feedback (e.g., ICMPv6 "packet too bigs") as necessary, 3) look into
the L3 header and perform L3 fragmentation as necessary, or 4) perform
link-specific fragmentation and reassembly. Option 1) has the disadvantage
of no PMTU feedback and thus cannot be used for bridging dissimilar media
due to PMTU black holes. Option 2) has the disadvantage of unreliable 
delivery
of untrusted ICMPs, but even worse is the fact that the L3 header may not be
available for inspection in all cases yielding the same broken PMTU behavior
as for simple L2 bridging. Option 3) does not even work for IPv6, since
middleboxes are not allowed to perform IPv6 fragmentation.

Option 4) on the other hand has precedence in existing technologies (e.g.
 IEEE 802.11), is recommended by analytical works such as "Fragmentation
Considered Harmful", and would seem like a reasonable alternative as long
as it is well implemented and does not impart excessive delay/delay 
variance.
It is only practical when reassembly takes place at the egress node at 
the edge
of the bridged network (and not an L2 middlebox), but this is exactly 
the case
when IPv4 is used as the L2 for IPv6. In other words, when IPv4 
fragmentation
is used as the link-specific fragmentation/reassembly mechanism the 
fragments
not lost in the network will arrive at the same IPv6/IPv4 tunnel 
decapsulator.

Essentially, I see advantages for NDproxy over simple L2 bridging *if*
the  NDproxies are specified to use link-specific fragmentation (i.e., IPv4
fragmentation) whenever possible rather than always trying to send ICMPv6
"packet too bigs". Since the NDproxy has no way of knowing the size of the
reassembly buffer in the decapsulator, IPv4 fragmenation could only apply up
to the minimum MRU required for all decapsulators, which I believe [MECH]
currently sets at 1500bytes.

For too-big packets larger than 1500bytes, the NDproxy could still send
the ICMPv6 "packet too bigs" and hope for the best - but IPv6/IPv4
encapsulators would be well-advised to limit the size of the IPv6
packets/fragments they send to 1500bytes (or even smaller - down to
1280 bytes - if L2 encapsulatons might occur along the path) due to the
PMTU black hole issues described above.

Fred
[email-masked]

P.S. Adding Dave and Chirayu to the Cc: list to get this on the NDproxy
    issue tracker. (Issue is "NDproxy should use IPv4 fragmentation for
    IPv6/IPv4 encapsulated packets no larger than 1500 bytes").

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Mar 2004 17:47:25 -0800 (PST)

Odd that only you seem to feel it is worth-while to comment on
the need for proxynd; does nobody else care enough?

First of all, I agree with you that removing reasons for NAT boxes
needing to exist is something we should all do in the IETF; they
make the network non-transparent and make it much harder to use some
existing applications as well as creating/deploying new applications.

Our disagreements seem to be whether ndproxy is an effective and useful
means for doing this.

> seems like an obvious means.

I'd like to understand why DHCP prefix delegation isn't the simplest thing.
Is this something you think is broken in our standards? Or in implementations
of the standards?

As an aside I find it odd that when the car is broken one would look
for parts in the garage and kitchen to try to build a bicycle and use that
instead of the car. Shouldn't we try to fix the car instead?

>  I'm not even sure how one would go about

Easy.

Whether using stateless or stateful address configuration,
the ISP can send RA's without any on-link prefixes to the customer's box.
This means no prefix is made available to the pt-pt link between
the ISP's router and the customer's box. Hence the customer's box
can only use the configured IPv6 address.

> case where the ISP absolutely wants just support one IP address is out

I think RFC 3177 makes it clear that /48 should be the default.
And if the car (DHCP prefix delegation) isn't working well, let's work
on fixing it.

> the same link, but in some cases (e.g., mismatching media) it might 

But here you wander into the ZEROUTER domain which you've already said
is out of scope.
If I can discuss it with you using the word "rant" I'd do that.
The solution you want in this space is something which allows plug&play of
the devices that glue together the stacking. And since you don't know how
the customer will plug things together, I think you must deal with loops.

It is true that ndproxy as written can handle this, but it handles
it by running IEEE 802.1D spanning tree protocol over all media - including
non-IEEE 802 media - without specifying the details of how to carry IEEE 802 
bridge PDUs over Avian Carriers, bluetooth, etc.
That doesn't seem like the best approach.
An approach like draft-perlman-zerouter-rbridge-00.txt, which builds
a (very thin) overlay above the link layer between the rbridges look
a lot more interesting to me; no need to carry bridge PDUs around etc.

> term myself -- perhaps because I feel I'm ranting a lot myself on some

Apology accepted.

But you seem to be talking about the ZEROUTER problem statement just as 
much as I am; the problem is having multiple different L2 technologies 
and wanting to plug those together without any explicit configuration of
the boxes that connect the different L2 technologies together.

> can DoS/MitM/etc. you in any case).

What about a home network which is also a free public WLAN?
Given that WEP is not adding much security, having SEND would make
it possible to open up 802.11 home networks for public access
(apart from resource management issues).

> doesn't work with SEND. Let's not try to fix either SEND or ND-proxy.

I'd sure like to have that question be asked in the SEND, IPV6, and V6OPS
WGs - my capacity for reading peoples minds is quite limited.

> immediately (which might be a bit redundant until SEND is commonly

I don't see how this can be combined in a meaningful way.
If a host has a default config to do SEND, then a packet from a ND proxy will
look like an attacker (it will not look like an insecure node since the peer
will have a CGA address AFAIK).

> (But this is something that should probably go to either SEND or IPv6 

Agreed.

> scope, but ND-proxy, in simpler setups, could be in scope here.

Could you specify the problem statement that covers "simpler setups"
but where  loops are somehow impossible to create by the consumer?

> I believe this is a separate problem.

You must be having a problem statement in mind which is tailored to
ndproxy as the solution. Such narrow problem statements are not very helpful
IMHO - we need to understand the problem space here.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 14:11:48 +0200 (EET)

> Our disagreements seem to be whether ndproxy is an effective and useful

Agree.

> instead of the car. Shouldn't we try to fix the car instead?

See the "simpler prefix delegation" thread I just started on IPv6 WG 
list.

> can only use the configured IPv6 address.

But how does the customer's box get it's own (global) addess?  Do you 
assume you run something like PPPv6 on the link, which assigns one 
address and that's it?

> > the same link, but in some cases (e.g., mismatching media) it might 
[...]
> a lot more interesting to me; no need to carry bridge PDUs around etc.

Moved as a thread under a new thread on IPv6 WG list; seems like the 
best place to argue about the feature-set, as they're specifying it.

> the boxes that connect the different L2 technologies together.

The number of boxes to be plugged together is also a factor.  How I 
interpreted the ZEROUTER scope (I could be wrong; I never looked it 
for long) was that any number of routers, in any topology would be in 
scope.

> (apart from resource management issues).

This is a good point.

SEND + CGA helps a bit in the local link, between the nodes; 
ND-proxy does not prevent that.  This is also possible in the local 
subnet (to a large degree), as long you're not running ND-proxy on the 
WLAN bridge (you should use bridging instead, because you can!).

On the other hand, SEND + certificates, for router verification, does 
not help here in any case, because I don't think the ISP offering only 
/64 would be supporting SEND (if they would, it would no longer be a 
"simple" setup -- and they'd be giving a /48).

So, I don't think this is all that critical issue in practice.

> WGs - my capacity for reading peoples minds is quite limited.

This should be brought up after the other threads in SEND and IPv6 WG 
cease.

> will have a CGA address AFAIK).

Right -- but what is the alternative?  The ISP would not be supporting 
SEND in any case.
 
> but where  loops are somehow impossible to create by the consumer?

We are not preventing the customer from shooting him/herself in the
foot in many other specifications either -- why is this relevant here?  
:)  They can plug their routers upside down, advertise prefixes which
don't work, forget to enable IPv6 forwarding, etc. -- a lot of
different ways to get yourself in a mess.  Further, I don't think
anyone is thinking of enabling proxy-ND by default. Just clearly state
that proxy-ND should not be combined, and if absolutely have to 
combine them, only plug them in series.

But this was included in the IPv6 ML thread.

> IMHO - we need to understand the problem space here.

I believe the "simple home setup" is sufficiently common, but narrow
problem space.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 Mar 2004 06:35:21 -0500

In section 4.1.2, while the statement "The basic use of DHCP is insecure." 
is technically true, it does not apply to the discussion of DHCPv6 prefix 
delegation.  Section 15 of RFC3396 gives specific guidelines for the use of 
DHCPv6 authentication for DHCPv6 PD.  DHCPv6 authentication is defined as 
part of the base DHCPv6 specification, in section 21 of RFC3315.

The statement "To be useful in such environment in practice, the practical 
details of managing the DHCP authentication need to be analyzed." needs to 
be explained.  How is the authentication specified in RFC3315 and 
recommended for DHCPv6 PD in RFC3396 not adequate?

What are the security implications of ND proxy?

- Ralph

---

From: Fred Templin <[email-masked]>
Date: Fri, 19 Mar 2004 11:14:10 -0800

Submitting this issue report to the NDProxy authors,
and also cc'ing v6ops due to the recent discussions there:

Fred
[email-masked]

Description of issue: Path MTU black holes with NDProxy
Submitter name: Fred L. Templin
Submitter email address: [email-masked]
Date first submitted: March 19, 2004
Reference: http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00296.html
Comment type: ['T'echnical | 'E'ditorial]  - Technical
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]  - Must fix
Section: 4.1.1
Rationale/Explanation of issue:
Lengthy description of problem:

 From ([NDproxy], section 4.1.1):

   "Whenever any packet is to be forwarded out an interface whose MTU
    is smaller than the size of the packet, the ND proxy drops the
    packet and sends a Packet Too Big message back to the source, as
    described in [ICMPv6]."

"any packet" in the above should read: "any IPv6 packet". Even so,
the text assumes that the IPv6 header is available for the NDProxy
to inspect, and this will not necessarily always be the case (e.g., for
packets that pass through the proxy between neighbors using IPv6
header compression). When the IPv6 header is not available, the
ND proxy is left with no option other than silent-drop, resulting
in a Path MTU black hole.

By way of the example from ([NDProxy], section 5):

    A---|---P---|---B
    a     p1   p2    b

Suppose A and B have performed the initial IPv6 ND exchange,
with the ND messages proxied by P as per the specification. But,
suppose also that A and B negotiate IPv6 header compression, i.e.,
they establish per-hop state that allows headers to be reconstituted
when immutable parts are omitted over-the-wire. When A sends
a packet with a compressed IPv6 header that is no larger than the
MTU of segment (a->p1), but larger than the MTU of segment
(p2->b), P will be unable to return an ICMPv6 "packet too big".

Requested change:

There would not appear to be a simple and scalable method to
address the issue within the context of the current specification,
since [NDProxy] only specifies L2 address rewriting for proxied
IPv6 packets and not any additional "deep packet inspection". In
order for P to be able to return an ICMPv6 "packet too big" in
the above example, it would require some means for "snooping"
the IPv6 header compression negotiation between A and B and
also maintaining a "mirror image" of the header compression
state. Moveover, P has no way of preventing A and B from
negotiating header compression, nor any way of anticipating
the header compression method to be negotiated.

Possible resolutions appear to be: 1) Note the path MTU black
hole issue, 2) Recommend that IPv6 header compression be
disabled when an NDProxy may occur along the path, 3) devise
an alternate scheme for preventing the black holes.

---

From: Fred Templin <[email-masked]>
Date: Fri, 19 Mar 2004 12:45:03 -0800

Hi Ralph,

> What are the security implications of ND proxy? 

I believe that the implications are somewhat different if native
IPv6 is used vs. IPv6 tunneled over IPv4. In the case of native IPv6,
 ([NDPROXY], section 4.1.4) seems to provide opportunity for, e.g.,
simple man-in-the-middle redirection attacks, since the model requires
that the NDproxy be able to change the addresses that appear in the
TLLA options of proxied IPv6 redirect messages.

When IPv6 is tunneled over IPv4, the NDProxy effectively becomes
an ARP Proxy, and the TLLA options in the encapsulated IPv6 redirect
messages are unchanged. (Or, if they are changed, the receiver should
be able to detect this if the sender is using some form of authentication
for the IPv6 ND messages it sends.)

Based on the security and path MTU issues, it seems that:

  - native IPv6 should be used between IPv6 neighbors on the same
    segment, or neighbors that are separated by simple L2 bridges
    that connect segments of like media
  - IPv6 tunneled over IPv4 should be used between IPv6 neighbors
    when an NDProxy occurs along the path

In other words, the NDProxy can be greatly simplified (and issues
such as  security; path MTU black holes can be avoided) if only IPv4
ND messages (and not IPv6) are proxied. This would reduce the
functionality of the NDProxy to that of the existing ARP proxy
model, which I believe others have mentioned as widely deployed
in operational scenarios.

Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Mar 2004 18:08:53 -0800 (PST)

> assume you run something like PPPv6 on the link, which assigns one 

That isn't the only choice. DHCPv6 and stateless address autoconfiguration
works as well. (There is a reason the prefix options have
a separate "on-link" flag and "addrconf" flag.)

> ND-proxy does not prevent that.  

AFAIK ND-proxy is incompatible with using SEND. full stop.
You can't do any proxy advertisements transparently to the hosts and
still have SEND work.

> foot in many other specifications either -- why is this relevant here?  

Could you please point me at an IETF standard related to routing which
can create persistent routing loops where ttl is not decremented?
I never recall seeing such a beast. Folks in the routing area seem
to have a aversion to creating persistent routing loops; even though
temporary loops occur at L3 and the damanage is limited due to
the ttl decrement.
But ndproxy explicitly doesn't decrement the ttl/hop limit!
That is why I am extremely concerned here.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Mar 2004 16:43:41 +0200 (EET)

[...]

> an alternate scheme for preventing the black holes.

FWIW, it seems obvious that we should do something like 2); Header 
Compression breaks _so_ many other things in the specs that we should 
not be trying to address it here.

Whether or not this deployment scenario is obvious enough (to be a
disallowed one) is probably a matter of opinion.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Mar 2004 16:48:42 +0200 (EET)

> for the IPv6 ND messages it sends.)

There must be some confusion here; ND-proxy, as proposed, is only 
meant to proxy IPv6 traffic, not e.g. IPv4 proto-41 packets.

> Based on the security and path MTU issues, it seems that:

I think this is rather questionable. ND-proxy is already deployed on 
the path, so that it by design is able to do pretty much everything.  
No different from a router, for example.  So I don't see the issues 
here.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Mar 2004 17:11:29 +0200 (EET)

> You can't do any proxy advertisements transparently to the hosts and

SEND nodes are still capable to use SEND when they're (all) behind the
same ND-proxy.  Obviously, when they work in the "transition" mode,
they will also process non-SEND messages, such as those that originate
beyond ND proxy.  So, you can actually use a degree of SEND with
ND-proxy, but I think it does not work *through* the ND proxy.  
Depending on where you deploy it (and where you deploy the SEND
nodes), this may be relevant.

> That is why I am extremely concerned here.

Luckily enough ND-proxy is not going to be IETF standard, but
Informational :).  Nobody has bothered to document (different flavors
of) proxy-ARP, but that's there in the similar way as well -- without
spanning tree, and seems to be working whereever it's used.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Mar 2004 15:08:08 +0200 (EET)

> part of the base DHCPv6 specification, in section 21 of RFC3315.

Right.

> recommended for DHCPv6 PD in RFC3396 not adequate?

(Operational) key management seems problematic, even though DHCP 
provides support for that.

Maybe reword:

   The basic use of DHCP is insecure. This may be a problem if the link
   between gateway and ISP is shared by multiple subscribers. DHCP
   specification includes authentication options, but does not describe
   the task of managing the keys, and how the information would be
   shared between the customer and the ISP.  To be useful in such
   environment in practice, the practical details of managing the DHCP
   authentication need to be analyzed.

to:

   DHCP is insecure unless authentication is used. This may be a
   particular problem if the link between gateway and ISP is shared by 
   multiple subscribers. DHCP specification includes authentication 
   options, but the operational procedures for managing the keys and 
   methods for sharing the required information between the customer 
   and the ISP are unclear.  To be secure in such environment in 
   practice, the practical details of managing the DHCP authentication 
   need to be analyzed.

Perhaps that is a bit more fair statement of the issue(s) involved.

> What are the security implications of ND proxy?

Roughly equal or slightly worse, but then again, it would probably not
be applicable in this specific ("multiple subscribers in one big LAN")
environment in any case.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Mar 2004 21:32:42 -0800 (PST)

> nodes), this may be relevant.

Assuming you don't know which hosts implement and use SEND this is
equivalent to saying  it works when all the routers and all the hosts are 
on the same side of the ndproxy. Since nothing connects to the other side 
of the ndproxy I think you can disconnect the ndproxy as well.

> spanning tree, and seems to be working whereever it's used.

The IPv6 WG charter has:
Jun 04  Submit Proxy RA to IESG for Proposed Standard.

So we are not that lucky unless something changes.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Mar 2004 21:34:35 -0800 (PST)

> spanning tree, and seems to be working whereever it's used.

Sorry, I missed the last sentence.

The proxy arp implementations I know of decrement ttl.
Are there proxy arp implementations that do not decrement ttl?

Can't compare that with ndproxy which doesn't decrement the hop count.

Erik

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Mar 2004 17:04:02 -0500

Pekka - comments in line...

- Ralph

>provides support for that.

How is operational key management for the authentication mechanism described
in RFC3315 more problematic than for other mechanisms that use shared keys?

>Perhaps that is a bit more fair statement of the issue(s) involved.

No, I honestly don't think it's any more fair.  Most service providers
provide complete isolation of customer traffic through filtering even if the
link appears to be shared among multiple customers.  If customers do truly
share a link, there are *many* other attacks available and pointing out DHCP
as a specific problem is only telling part of the story.  Finally, I still
haven't heard an explanation of the requirement that "the practical details
of managing the DHCP authentication need to be analyzed."  DHCP can use a
password provided by the service provider to the customer.  What additional
analysis do we need to perform?

The issue of DHCPv6 security is adequately addressed in RFC3315 and need
not be rehashed here.  Anyone who reads RFC3315 (btw, the reference
[DNSDHCPV6] is never cited anywhere in the body of the document) will
see the security analysis for DHCPv6.

>be applicable in this specific ("multiple subscribers in one big LAN")

So ND proxy doesn't represent a security problem and requires no
authentication because its scaling properties preclude its use in what you
consider to be a typical deployment scenario?  Whatever the situation,
the security issues for ND proxy should be mentioned as well as those
for DHCPv6.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Mar 2004 12:53:13 +0200 (EET)

> in RFC3315 more problematic than for other mechanisms that use shared keys?

Those protocols are not often used 1) between administrative domains 
[where key management is arguably simpler] and 2) before getting IP 
addresses in the first place (that is, if you don't have an address 
yet, you cannot run mechanisms which help in making the key sharing 
simpler).

> link appears to be shared among multiple customers.  

But then it no longer is a shared link, and the above does not apply.

But you raise a good point: I think we should spell out the obvious,
that rather than trying to operate with *really* shared links, the
operators should strongly consider mechanisms (any pointers?) which
achieve the isolation, making the issues more complex.

> If customers do truly
> as a specific problem is only telling part of the story.

Yep, but that's the only story being covered in that section of the 
document...

> Finally, I still

If they provide a password, that's fine.  As long as it's clear how 
they provide it, and how it would end up being configured in the 
router. (Trivial if the ISP ships the box to the user, possibly 
non-trivial otherwise.)

I think the shared key model also requires that the key stays as it 
forever (providing for better brute-force attacks against it), unless 
you do re-keying or the like somehow.  But that would probably be 
equally problematic.

> see the security analysis for DHCPv6.

The security analysis in there is restricted to the scenario which 
may not be directly applicable here:

   This protocol is focused on solving the intradomain problem where the
   out-of-band exchange of a shared key is feasible.

This is inter-domain, and whether sharing keys is feasible is an open 
question. (In some cases, with some constraints, it certainly seems to 
be possible, but...)

> consider to be a typical deployment scenario? 

Yep.

> Whatever the situation,

Agreed.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Mar 2004 17:28:21 -0500

At 12:53 PM 3/25/2004 +0200, Pekka Savola wrote:
>[where key management is arguably simpler] and

I can walk into a WiFi hotspot today, establish a new trust relationship
that I haven't used before, and establish a secure link to the Internet
that uses a DHCP-delegated IPv4 address.  Delegating a prefix with DHCPv6
is essentially the same problem as obtaining an IPv4 address with DHCPv4.
What is the problem we need to solve with DHCPv6?

>  2) before getting IP

Whether or not an IP address has been obtained is irrelevant to the
problem and especially to DHCPv6 prefix delegation.

>achieve the isolation, making the issues more complex.

OK, and I think that secured, non-shared links really are the norm.

As security issues are explicitly described in more detail in the
DHCPv6 and PD RFCs, I suggest the text about security be replaced with
pointers to the discussions of security in those two documents:

4.1.2   Explicit prefix delegation

    Several networks have already started using an explicit prefix
    delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the
    gateway uses a DHCP request to obtain a prefix from a DHCP server
    managed by the ISP. The DHCP server identifies the gateway, for
    example, through identification information provided by the gateway
    in the DHCP request message or by the port or circuit through which
    the DHCP request message is received.  The server can implement
    prefix delegation policies based on the identity of the requesting
    gateway.  According to the recommendations in RFCxxxx the ISP
    assigns a /48 to the customer. The gateway then automatically
    assign /64s out of this /48 to its internal links.

(Editorial notes:
  * I don't think the acronym "ISP" is defined anywhere in the document
  * There doesn't seem to be a citation of RFC 3315 anywhere in the document
  * There should be citations of RFC 2131 and RFC 2132 for DHCPv4)

    Security issues associated with DHCP and prefix delegation are
    addressed in the "Security Considerations" section of RFC 3315
    and RFC 3633, respectively.

4.1.3   Recommendation

    The ND proxy and DHCP methods appear to have different domains of
    application. ND proxy is a simple method that corresponds well to
    "informal sharing" of a link, while explicit delegation provides
    strong administrative control. The ND proxy mechanism has not yet
    been accepted as an Internet Standard and the interaction
    between neighbor discovery and ND proxy needs to be specified.

>Yep, but that's the only story being covered in that section of the

It's also the only place in the document where specific security issues are
raised beyond the level of "Specific security issues should be studied and
addressed during the development of the specific mechanisms."

>you do re-keying or the like somehow.  But that would probably be

Which is exactly the model employed in the equivalent problem of
address assignment today.  Why are the requirements for prefix
delegation stricter than for what is deployed today?

>question. (In some cases, with some constraints, it certainly seems to

The common model today is to establish a separate security relationship
with different administrative domains and select the appropriate
relationship as needed.  The same strategy can be applied to prefix
delegation - if, indeed, any ISP actually deploys a network in which
customers really see each others traffic on a shared link.