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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
