Re: comments on thaler-ndproxy-01

[Pekka Savola <pekkas@netcore.fi>]

Sorry for the delay in responding..

On Tue, 11 Nov 2003, Chirayu Patel wrote:
[snip scenarios]
> 

Yep, that's pretty much what I had in mind.  The point is that NDproxies 
in these cases can be often replaced by normal, bridging devices.  
However, the user probably wants to do stuff like firewalling on the box 
as well.. which was the reason to at least include this case in the 
introduction, even if ND-proxies are not necessarily a requirement.

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

What I meant is e.g. if in your scenario 2 above the ISP <-> user link is
also Ethernet, ND-proxy is not required.  I.e., summarize the few 
scenarios where bridging would also be useful and could be used instead of 
a NAT box.

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

I have no objection to removing 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?

It would seem to imply that ND-proxies would be deployed in scenarios 
where the topology is very complex.  That would be out of the scope of the 
simple model we're aiming towards -- remember, we're not trying to 
supplant routed networks, we're just providing a nice way to extend the 
network transparently in the case adding a router would not be a good 
idea.

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

Not really.  What I'm saying is that if a loop occurs, the failure mode 
should be apparent (i.e., the communications fail).

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

Ok, there's two levels of hostility which need to be spelled out better:

 1) "doesn't work when the router or a host uses it", or
 2) "works by modifying packets, resulting in a different security 
properties"

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

I mean a deployment where a host and a router would use L2 encryption, and 
the transparent bridge would not even be able to decipher L2 frames much 
less L3 packets?

So, if you can't use IPsec ESP, you may be able to use L2 encryption, but 
only encryption where the bridge can be "on the loop" somehow?

> >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?
>
> [Dave:]
>
> 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.

Sorry for ambiguity.  I meant the target address, because that includes 
the lladdr from the cache..

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

and:

[Dave]
> 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.

Do you know what kind of timeout ballpark figures bridges/switches have
compared to ND? (I have never noticed problems moving hosts between switch
ports.)

I don't think the current ND specs say anything about sending a packet or 
two after they get L2 trigger that link comes up, even though this might 
be useful for updating the cache, right?
 
> 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.

FWIW, requiring IP address is OK by me.

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

I'm not necessarily against disabling security.  I'd just want to spell 
out the issues here.  The text needs beefing up a bit.

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

Yep, the point was to just add examples of already supported protocols 
(without modifications, e.g. DHCPv6 because DHCPv4 requires special 
stuff), and protocols which are *NOT* supported, but could be, with 
extenstions.

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

Didn't respond.. 

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

Right; the comment was not applicable because of that.
 
> > ==> 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?

[Dave:]
> 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.

Ok, I guess Dave's explanation answers this point; not having looked into 
the details of STP, I hope it propagates the information of the neighbors 
in the payload, otherwise it would be useless :-)

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

[Dave:]

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

I don't have ones in mind, but I'd think that there are typically changes 
especially in the ND/ARP behaviour on the ND bridge.

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