30% TANIEJ!

Thinking in Java. Edycja polska. Wydanie IV

67.90 zł   97.00 zł

RFC 4389                        ND Proxy                      April 2006


   2)   If the link-layer address in the payload of the protocol will
        never be used in any link-layer header, then the proxy should
        not substitute it with its own address.  No special actions
        are required for supporting these protocols.  For example,
        [DHCPv6] is in this category.

8.  IANA Considerations

   This document defines a new bit in the RA flags (the P bit).  There
   is currently no registration procedure for such bits, so IANA should
   not take any action.

9.  Security Considerations

   Unsecured Neighbor Discovery has a number of security issues, which
   are discussed in detail in [PSREQ].  RFC 3971 [SEND] defines security
   mechanisms that can protect Neighbor Discovery.

   Proxies are susceptible to the same kind of security issues that
   plague hosts using unsecured Neighbor Discovery.  These issues
   include hijacking traffic and denial-of-service within the subnet.
   Malicious nodes within the subnet can take advantage of this
   property, and hijack traffic.  In addition, a Neighbor Discovery
   proxy is essentially a legitimate man-in-the-middle, which implies
   that there is a need to distinguish proxies from unwanted man-in-
   the-middle attackers.

   This document does not introduce any new mechanisms for the
   protection of proxy Neighbor Discovery.  That is, it does not provide
   a mechanism from authorizing certain devices to act as proxies, and
   it does not provide extensions to SEND to make it possible to use
   both SEND and proxies at the same time.  We note that RFC 2461 [ND]
   already defines the ability to proxy Neighbor Advertisements, and
   extensions to SEND are already needed to cover that case, independent
   of this document.

   Note also that the use of proxy Neighbor Discovery may render it
   impossible to use SEND both on the leaf subnet and on the external
   subnet.  This is because the modifications performed by the proxy
   will invalidate the RSA Signature Option in a secured Neighbor
   Discovery message, and cause SEND-capable nodes to either discard the
   messages or treat them as unsecured.  The latter is the desired
   operation when SEND is used together with this specification, and it
   ensures that SEND nodes within this environment can selectively
   downgrade themselves to unsecure Neighbor Discovery when proxies are
   present.

Thaler, et al.                Experimental                     [Page 13]