Proxying SEND messages

1
Proxying SEND messages

• Suresh Krishnan

2
ND proxies

• Defined in RFC4389
• Describes a method for bridging multiple link
  layer segments into a single segment.
• Accomplished by modifying L2 addresses on the
  wire in Neighbor discovery messages
• Incompatible to SEND
• SEND prevents a (wo)man in the middle
• NDProxy IS a (wo)man in the middle

3
SEND Assumptions

• SEND assumes the owner of the address is the
  person sending the message
• This assumption does not allow proxying of a CGA
  based address as the receiver requires that the
  advertiser possesses the public and private keys
  related to the address.
• This document explicitly separates the roles of
  ownership and advertiser.
• SEND certificates can be used for ALL purposes

4
Basis of the method

• In the proposed method the proxy becomes part of
  the trusted infrastructure just like a SEND
  router.
• The proxy is granted a certificate that specifies
  the range of addresses that it is allowed to
  proxy.
• Hosts can use the same process to discover the
  certification path between a proxy and one of the
  host's trust anchors as the one defined for
  routers in RFC3971

5
Operation

• Perform all the operations performed by the
  standard ND proxy
• Replace MAC addresses on the fly
• Sign the modified message with the authorized
  proxy's key.
• Include the original contents of the neighbor
  discovery options it replaced

6
SEND Proxy Behavior
Proxied Node
Proxy
Receiver
Receiver
Proxy
Proxied Node
Original MAC address(es)
Modified MAC address(es)
Original RSA signature
Proxy signature
7
Proxy ND Behavior
Proxied Node
Proxy
Receiver
Receiver
Proxy
Proxied Node
8
New options

• Proxy Signature Option (PSO)
• The signature of the neighbor discovery proxy
• The signature is performed over all the NDP
  options present in the message
• includes the RSA signature option from the
  original message
• The PSO is appended as the last option in the
  message.
• Original Link Layer Address Options (OLLAO)
• Contents of the original TLLAO and/or SLLAO
  before the proxy modified the packet

9
Fallback procedure

• If a receiving node does not trust a proxy it may
  elect to use the original contents of the
  received neighbor discovery message instead of
  the received contents.
• The original message can be derived as follows
• Replace the contents of the TLLA option, if any,
  with the contents of the OTLLA option while
  retaining the type field of the option
• Replace the contents of the SLLA option, if any,
  with the contents of the OSLLA option while
  retaining the type field of the option
• Reset the value of the P bit if the received
  message is a Router Advertisement
• Remove any proxy signature, OTLLA, and OSLLA
  options present in the message
• After obtaining the contents of the original
  message the receiving node can perform SEND
  verification as described in RFC3971

10
Backward Compatibility

• The options added by a SEND proxy, such as the
  PSO, will not be used by nodes implementing the
  original SEND specification and hence will not
  cause any interoperability problems.
• These legacy SEND nodes will check the RSA
  signature option and will consider it invalid.
  Based on the configuration of the host, the
  message MAY either be treated as insecure or be
  dropped.

11
Thanks

• Questions?