Subject: comments on thaler-ndproxy-01

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 16:02:50 +0200 (EET)

Hi,

The doc is pretty good but needs more work  The most important thing 
appears to be identifying the which features we need (considering the 
tradeoffs)

substantial
-----------

1) The impression of the document is that it's underspecified but workable. 
If the goal is to make it more fun to implement this (instead of more
boring :-), by omitting the details of the specification, this document
succeeds.  If not, the details need to be added.. Well, the details probably
need to be added anyway, because some of these apparently obvious methods
could vary a lot from person to person (a couple of examples in the 
semi-editorial section)

2) I'm not sure whether they should be included in the scenarios, but I
think they're very relevant.  That is, deploying the ND proxy to perform
bridging firewall functions on a subnet for multiple reasons.. remember,
that's one of the *major* reasons why NATs are also deployed in more or less
transparent/zero-conf manner.  Of course, in most cases, this can be solved
with a regular bridging firewall as well, no need to use an ND proxy.  For
example as in scenario 1:

         |         +-------+           +--------+
   local |Ethernet |       | Wireless  | Access |
         +---------+   A   +-)))   (((-+        +--> rest of network
   hosts |         |       |   link    | Point  |
         |         +-------+           +--------+

.. assume that local hosts could also, theoretically, have wireless
interfaces themselves, and communicate directly over the wireless link
without the presence of A.  Now, a major reason to deploy something like A
would be the ability to add firewall rules in A, to protect all the local
hosts in one go.

To sum it up, I'm not 100% sure how much of this needs to be spelled out or
not.  Maybe one could include a few words on what other functions the ND
proxies (firewalling etc.) could be used to provide between the segments,
with some caveats.

What would probably also be very useful is to spell out some of the 
scenarios where ND proxy is NOT needed, but regular bridging would
be OK as well -- to give a view that bridging and ND-proxying really do
provide a complete set of solutions.  (Just to make it easier to show 
folks that NATs are really not needed -- this is a bit out of scope of the
original document, but could be really useful if not done somewhere else
(e.g., v6ops solutions documents..)).

3) I'm not sure whether specifying the mechanism for IPv4 is within the
mandate of this WG.  But it seems to come in free, so, no huge resistance
here.  The worry is just that there may be some v4 features we're not really
aware of and making ND proxying work on v4 might actually take a lot more
effort than we realize at first (difficult to say at this phase).

4) I want the loop-prevention features to be to non-requirements.  If loop
prevention is required, the ND-proxy is deployed improperly.  The only thing
from loop prevention I'd appreciate is that the failure mode would be
obvious when/if ND proxying was deployed in such a manner that a loop would
occur.  (This would result to moving the loop prevention stuff to an
appendix or removing it..)

5) Non-goals has:
o    Support Neighbor Discovery, Router Discovery, or DHCPv4
     packets using encryption with an ESP header.  We also note
     that the current methods for securing these protocols do not
     use an ESP header.  Where encryption is required, link-layer
     encryption can be used on each segment.

==> Uhh, isn't the current approach hostile to IPsec AH as well, as the
payload of the packets (e.g. SLLA, TLLA) are modified, unless the ND proxy
acts as some form of authorized intermediary?

==> I'm not sure whether link-layer encryption sentence is accurate.  Let's
consider two cases: the L2 encryption uses a shared secret (known by the
proxy) -- OK; the L2 encryption uses stronger methods (usually the more
useful deployment of L2 encryption) -- the ND proxy needs act as MITM here,
but then L2 encryption will fail, right?  

So, it would seem that in the presence of IPsec AH, IPsec ESP, or link-layer
non-shared key encryption the deployment of ND-proxies may be problematic,
but with some restrictions, possible.  These will need to be considered
explicitly somewhere, e.g. a deployment or security considerations section.

6) I'm not sure if the spec as written supports the seamless movement
between bridged segments, which was a requirement, for example:

If the received packet is an ICMPv6 Redirect message, then the
proxied packet should be modified as follows.  If the proxy has a
valid (i.e., not INCOMPLETE) neighbor entry for the target address
on the same interface as the redirected host, then the TLLA option
in the proxied Redirect simply contains the link-layer address of
the target as found in the proxy's neighbor entry, since the
redirected host may reach the target address directly.

==> now, consider the same if the node moved to a different segment since
the neighbor entry was created?

Or in:

The NA is received by P, which then processes it as it would any 
unicast packet; i.e., it forwards this out interface 1, based on
the neighbor cache.  However, before actually sending the packet
out, it inspects it to determine if the packet being sent is one  
which requires proxying.  Since it is an NA, it updates its
neighbor entry for B to be REACHABLE and records the link-layer
address b.  P then replaces the link-layer address in the TLLA
option with its own link-layer address on the outgoing interface,
p1.  The packet is then sent out interface 1.

==> this doesn't seem to work when moving between segments without a:
 1) a cache timeout, or
 2) the host, immediately after moving, sending a packet, updating the
proxy's cache.  If the host is silent before moving and afterwards, 
there will be no indication where it has gone. Right?

7) doesn't the following break the requirements of transparent introduction
-- for both hosts (need to consider the bridge as a router), and for the
router (it needs to be aware of the ND proxy, right?)v

From=20an IPv6 perspective, RFC 2461 [ND] already defines the
ability to proxy Neighbor Advertisements.  The requirements for
securing proxied messages are similar to those for securing Router
Advertisements, since the receiver must verify that the
advertisement came from a valid router/proxy, rather than from the
owner of a specific address.

8) An IPR section is required. Is there known IPR on this?

9) The link layer address changes could affect the packet size.  Note that 
as the length is given in the units of 64 bits, for most (all?) the 
applicable link types that indicates that the packet size won't be 
changed.  Could be worth pointing out.

However, adding MTU option in sect 4.1.3.3 is a different issue 
altogether.  Actually, it would also be possible to overflow the RA size 
by adding the MTU, if the RA is really loaded witrh prefixes.  This is of 
course very theoretical, but probably needs to be mentioned explicitly!

semi-editorial
--------------

==> needs a ToC, as it's over 15 pages

Expires December 2003                                     [Page 1]
=0C

==> something is wrong with the page breaks

When a proxy interface comes up, the node puts it in "all-
multicast" mode so that it will receive all multicast packets.  It
is common for interfaces to not support full promiscuous mode
(e.g., on a wireless client), but all-multicast mode is generally
still supported.

==> s/all multicast/all multicast and broadcast/, right? (not sure whether
the definition of multicast explicitly includes broadcast...)

When any IP or ARP packet is received on a proxy interface, it
must be parsed to see whether it is known to be of a type that
negotiates link-layer addresses.  This document covers the
following types: ARP, IPv6 Neighbor Discovery, IPv6 Router
Discovery, IPv6 Redirects, and DHCPv4.

==> Could you spell out, for clarity, some protocols:
 a) which are not supported by this spec, or
 b) which do not need to be supported by this spec (but one could think
whether they need be), e.g. DHCPv6?

The link layer header, and the link-layer address within the
payload for each forwarded packet will be modified as follows:
[...]

==> as noted above, these are a bit underspecified.. ("where in the
packets"?)

As with all forwarded packets, the link-layer header is also new.
Any Authentication Header would also be removed, and a new one may
be added as discussed below under Security Considerations.

==> note that Security Consideration doesn't currently discuss this :-)

When any IPv4 or ARP packet is received on a proxy interface, it
must be parsed to see whether it is known to be one of the
following types: ARP, or DHCPv4.

==> again, not specified how ARP or DHCPv4 packets are recognized; this
should be pretty obvious, but is a bit under-specified..

==> I note that IPv4 Redirects are not supported, but this hasn't been
spelled out anywhere.  Omission or intentional ?

To support scenario 2, if the MTU of the upstream segment is
smaller than the MTU of the downstream segment then IPv6 Router
Advertisements (RAs) must also be proxied as follows.  If the RA
contains an MTU Option, the RA is forwarded unmodified.
Otherwise, the proxy adds an MTU Option with a value of minimum of
the link MTUs of the proxy interfaces, and then proxies it as
described above.

==> it should probably be spelled out here, due to the non-requirement,
ND-proxying doesn't work at all if the routers are connected to a link with
higher MTU.

 It also creates a neighbor entry for B
(on an arbitrary proxy interface) in the INCOMPLETE state.  Since
the packet is multicast, P then needs to proxy the NS out all
other proxy interfaces on the subnet.  Before sending the packet
out interface 2, it replaces the link-layer address in the SLLA
option with its own link-layer address, p2.

==> the use of terms "all other proxy interfaces", etc. are a bit misnomers
in this particular example of just two interfaces.  I'd suggest expanding
the example so that P has three interfaces, but only with two nodes A and B
(one interface is empty)

Loop prevention can be done done by having the proxy implement the
Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
proxy interfaces.

==> is this really enough of a specification?? :-))

Operation of the Spanning Tree Protocol (STP) over other types of
link layers is done by encapsulating the STP frame in an IPv6
header as follows.  The Next Header field is set to [TBA by IANA],
indicating that an STP header follows.  The Destination Address
field is set to the Link-scoped STP Multicast Group [TBA by IANA].
All proxies operating on non-IEEE 802 media join this group so
they will receive STP packets.  STP packets are never forwarded or
proxied.

==> which format is used for encapsulation of STP?  Directly afterwards?  It
is a "terminal header", correct, so no TLV encoding or similar need be done?

==> Are ND proxies acting as decapsulators/encapsulators for these STP
packets between the links?  If nothing is done based on these, how do they
help in the first place?

10.  Appendix A: Comparison with other approaches

==> this section should be reworded to be refer to RA-proxy only, or add
some other approaches (probably preferable!) such as IPv4 Proxy ARP (the
differences are probably rather interesting..)

editorial
---------

o    Support Neighbor Discovery, Router Discovery, or DHCPv4
     packets using encryption with an ESP header.  We also note
     that the current methods for securing these protocols do not
     use an ESP header.  Where encryption is required, link-layer
     encryption can be used on each segment.

==> s/ESP/IPsec Encapsulation Security Payload (ESP)/
==> s/Where encryption/Where the encryption of these, typically on-link, 
neighbor discovery communications/

interface on which it arrived; such a packet is instead silently
dropped.

==> s/dropped/discarded/

ocally but no ARP REPLY is generated immediately.  Instead, the
ARP REQUEST is proxied (as described above) and the ARP REPLY will

==> use a proper pointer to sect 4.1 instead of "above". (similar
elsewhere..)

B receives this NS, processing it as usual.  Hence it creates a
neighbor entry for A mapping it to the link-layer address p2.  It
responds with a Neighbor Advertisement (NA) sent to A containing
B's link-layer address b.  The NA is sent using A's neighbor
entry, i.e. to the link-layer address p2.

==> s/with a/with a unicast/

example, propritery protocols). This section prescribes guidelines

==> s/propritery/proprietary/

From=20an IPv6 perspective, RFC 2461 [ND] already defines the

==> some scrap here, "=20".

-- 
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: "Dave Thaler" <[email-masked]>
Date: Tue, 11 Nov 2003 11:58:38 -0800

Thanks for the comments, Pekka!

> appears to be identifying the which features we need (considering the

Oh but we want implementors to have fun, otherwise they'll be
implementing
boring things like NATs :-)

Comments on your specific examples below.

> example as in scenario 1:

I have no strong opinion either way on this.  
Any other opinions?

> (e.g., v6ops solutions documents..)).

The draft currently states
"It is expected that whenever possible links will be
bridged at the link layer using classic bridge technology [BRIDGE]
as opposed to using the mechanisms herein."

As you mention it's a bit out of scope to go farther.
Any other opinions?

> effort than we realize at first (difficult to say at this phase).

Since you have no resistance immediately, I'm not treating this as an 
official issue to be tracked at this point.  We should keep this in 
mind going forward though.

> appendix or removing it..)

There have been arguments both ways on this in the past.
At the moment the status in the draft is that it is optional
(not required), with some guidance as to when it's useful and 
when it's not useful.

> acts as some form of authorized intermediary?

It's not hostile, since the proxy can still remove the original AH.
It can't do the same with ESP encryption.

> but then L2 encryption will fail, right? 

Why would it fail?  The proxy always uses its own L2 address, not
someone
else's.  Can you give a more specific example?

> the neighbor entry was created?

I didn't follow.  Which node?  The redirected host?  Or the target
address?

If the redirected host moves away, the redirect will just be dropped
since there will be no one at the destinaion link-layer address.

> there will be no indication where it has gone. Right?

Offhand, I think that's right.  If the host always does DAD after
moving, for example, then (2) would be the case, with (1) applying
otherwise.  Both of these are not specific to this spec - indeed
essentially the same thing would happen with a classic bridge or
switch.

As a result, I don't see anything wrong with the current draft in this
regard.  It appears to meet the requirement just as well as a classic
bridge or switch does.

> owner of a specific address.

It's unclear (to me at least) at this point.
I'm not sure there's any other solution than to disable security for
RAs.
Hence the current position to state the issue and leave it up to
the implementor to decide and the SEND WG to consider.

If you have a specific proposal, send text :)

> 8) An IPR section is required. Is there known IPR on this?

Not that I've heard so far.
ARP proxy implementations are pretty old.

> changed.  Could be worth pointing out.

True (i.e. I agree it's less of an issue than one might otherwise
think).

> course very theoretical, but probably needs to be mentioned
explicitly!

Agree.

> semi-editorial

You don't need to enable any special mode to get all broadcast, 
so in my opinion "all broadcast" should go without saying.

>  a) which are not supported by this spec, or

None that I know of offhand.

> whether they need be), e.g. DHCPv6?

Right, we could say DHCPv6 needs no special support.

> ==> as noted above, these are a bit underspecified.. ("where in the

I guess we were hoping it would be obvious to an implementor, but
yes the text could be more specific.  

> is a "terminal header", correct, so no TLV encoding or similar need be
done?

Correct.

> packets between the links?  If nothing is done based on these, how do
they

This is how a proxy that chose to implement loop prevention would send 
its _own_ STP messages to a neighboring STP speaker, and receive STP 
messages from the neighbor.  That's the point about "never forwarded 
or proxied".  A proxy that chose to implement loop prevention would
act on the packets by running the spanning tree algorithm specified
in [BRIDGE] to decide whether to ignore an interface or not.

> differences are probably rather interesting..)

Proposed text would be gratefully accepted.

At least one IPv4 Proxy ARP implementation is pretty much the same
as what's documented, but it would be nice to hear from any different
ones.

Another option would be to just remove Appendix A.

-Dave