RE: comments on thaler-ndproxy-01

["Dave Thaler" <dthaler@windows.microsoft.com>]

Thanks for the comments, Pekka!

Pekka Savola writes:
> 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)

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

Comments on your specific examples below.

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

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

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

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

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.

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

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.

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

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

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

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

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

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.

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

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.

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

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.

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

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

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

Agree.

> semi-editorial
> --------------
> 
> ==> needs a ToC, as it's over 15 pages
> 
> ==> 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...)

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

> 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

None that I know of offhand.

>  b) which do not need to be supported by this spec (but one could
think
> whether they need be), e.g. DHCPv6?

Right, we could say DHCPv6 needs no special support.

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

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

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

Correct.

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

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.

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

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


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