Re: comments on thaler-ndproxy-01

["Chirayu Patel" <chirayu@chirayu.org>]

Hi Pekka,

Thanks for the detailed comments.  See below...

CP

On Sun, 9 Nov 2003 16:02:50 +0200 (EET), "Pekka Savola"
<pekkas@netcore.fi> said:
> 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)

We are probably making the implementors life a bit less fun than what you
think. :-) The document does contain implementation details about:

  1. Maintenance of neighbor cache.
  2. Guidance for providing support for unspecified protocols.
  3. General philosophy for choosing the outgoing interface.

I do agree with your comment. Some of the topics which I am thinking of
adding are:

  1. Details about number of IP addresses (non-link-local) required by
     the proxy.

  2. Details about payload modification for each packet-type. (I have
     mentioned this one in response to one of your other comments below)

  3. High-level diagram showing where the proxy functions can be
     implemented in an IPv6 stack.

  4. Bringing all the implementation detail under a "Conceptual Model of
     a Bridge" 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.

Seems to be a plausible scenario.

Apart from this, I think ND proxy can also take over the function of the
NAT in home networks.

Scenario 1
----------

 (isp)<-|->(home)
        |             Ethernet             Wireless
[ISP]---|---[Router]-------+----[NDproxy]-)))    (((-[hosts]
        |                  |                 link
        |                  |
                       [hosts]

Scenario 2
----------

 (isp)<-|->(home)
        |             Ethernet             Wireless
[ISP]---|---[NDproxy]------+----[NDproxy]-)))    (((-[hosts]
        |                  |                 link
        |                  |
                       [hosts]


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

Maybe I was a bit ignorant, but when I had read about ND proxy for the
first time in the charter, the applicability was not at all obvious. I
think it should be useful to add the scenarios as long as the text does
not get out of hand. :-)

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

The various scenarios (ones in the documents, and the ones above)
should make it clear that ND proxy can be used instead of a NAT in an
IPv6 network.

About classic L2 bridging, IMHO, the document quite clearly states, when
it should be used, and its limitations. (Section 1). Is this enough? The
different scenarios in which L2 bridges are used (and they are the ones
in which ND proxy should not be used) are not described because they are
well known.

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

Actually, there is a bit of work involved for IPv4. It does not come for
free. :-) For example, implementation details have to be specified for
both IPv4, and IPv6. Currently, most of the implementation detail is
specific to IPv6. The neighbor cache structure, its state transition
table cannot be applied to IPv4. Minor editorial nits (usage of broadcast
and multicast) also have to be taken care of. I am sure there are more of
such "non-free" areas.

IPv4 ARP proxy has been around for a while now, and IMHO there is not
much gain by documenting it now. We should probably remove it.

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

Don't understand completely.

1. Why do you want the loop-prevention features to be non-requirements?
   Isn't the current form (of an optional requirement) sufficient?

2. Are you implying that there should be some sort of loop detection
   mechanism instead?

> 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'll leave this one, and all other security related questions for Dave.
:-)

> ==> 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?

Seems right to me.

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

Dave?

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

Right. Though, in most cases the host will not be silent (it will get a
trigger from L2 about movement), and will attempt to do Router Discovery.

Seamless movement between bridged segments is not supported. We did
discuss a solution that involved 1) getting a trigger from L2 that the
host has moved, and 2) doing a broadcast of any unicast packet for the
moved host on all the proxy ports. This way the unicast packet (NA in
this case) would reach the destination. The broadcast would continue till
the host sends a packet, and updates the cache.

You can refer to the past discussions on this issue at
http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%206

Another thing that may have not caught your eye is the assumption that ND
proxies always have an IP address. Unlike classic L2 bridges, ND proxies
require an IP address. IMHO this is debatable...and I am planning to send
out a mail regarding this to the WG. If it is accepted that the ND
proxies always have an IP address, another scheme wherein the proxy
(after detecting host movement) sends an NS to determine the new location
of the moved host (the NA from host would populate the cache of other
proxies in the path). Messages received for the moved host, before the NA
is received, can either be queued or broadcasted.

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

Dave?

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

I am not aware of anything. Dave?

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

Agreed. The perils of these borderline cases have to be mentioned
explicitly.

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

Agreed.

> Expires December 2003                                     [Page 1]
> =0C
>
> ==> something is wrong with the page breaks

Yup.

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

Broadcast packets are received up by default. Hence, no need to mention
it. Also, "broadcast mode" seems to be non standard terminology.

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

DHCPv6 is supposed to be supported. We did discuss it. :-) All other
protocols that are not mentioned are not supported. The document has a
guideline section (section 7) to help implementors in supporting other
protocols.

> 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"?)

Agree. The quoted text is supposed to be the general philosophy of
substitution. Specific substitution details for a message should be
mentioned in the sub-section corresponding to the message.

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

Dave? :-)

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

Yes.

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

They should be supported.

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

Yes.

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

Ok.

> 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?? :-))

:-) [BRIDGE] specifies STP in great detail, and since there is no
interaction of STP with other functions (described in this document), I
don't think there is much we can add beyond this sentence.

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

Don't understand "format", and "Directly afterwards" in your question.
STP header is the terminal header in the IPv6 packet.

> ==> 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?

ND proxies will have a complete implementation of STP, and will process
STP packets received on both non-802, and 802 interfaces as per the
[BRIDGE] specification. Does this answer your question?

> 10.  Appendix A: Comparison with other approaches
>
> ==> this section should be reworded to be refer to RA-proxy only,

Agree.

> ==> or add some other approaches (probably preferable!) such as IPv4
> Proxy ARP (the differences are probably rather interesting..)

Will have to think about this one. Do you have any alternate
approaches in mind?

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

Agree with all editorial comments.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------