Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

[Alan DeKok <[e-mail]>]

Robert Cragie wrote:
>     * I agree with the notion of enforcing the relay to only process
>       valid PANA messages and only send valid PANA messages. The fact it
>       is a functionally-defined relay (as opposed to a generic IP
>       tunnel) means that we can do this. Therefore we need to add text
>       as you suggest.

  Thanks.

>     * I am less sure of the need for a token. As far as I can see, the
>       token would only protect the immutable information in the data
>       sent from PRE to PAA, i.e. the IP address and the port. This has
>       some benefit but would not necessarily prevent a rogue PAA sending
>       a bogus encapsulated frame.

  It would *authenticate* the data sent from the PAA to the PRE.  This
authentication would ensure that the PAA could only respond to packets
sent by the PRE.

  As I said earlier, this would ensure that a rogue PAA can only (a)
send PANA messages, to (b) the IP of the PaC, and (c) the port of the
PaC used to send PANA messages.  It would prevent a rogue PAA from
sending a non-PANA frame to arbitrary non-PANA IPs and ports.

>  Using DTLS between PRE and PAA would
>       provide protection for the whole packet, possibly including
>       encryption.

   It's not per-packet protection.  It's that the PRE will only accept
frames from the PAA that have been authenticated via TLS.

> Using a PANA SA would provide better protection than a
>       PRE-originated token. Using L2 security also provides a 'walled
>       garden' protection. It seems to me possible for a rogue node to
>       send any packet to any port on a node which is accessible at the
>       link layer provided one knows its address and assumes no L2
>       security therefore I don't again see this as an additional threat

  The document clearly states that the PRE is proxying packets because
the PAA can not otherwise route traffic to the PaC.  Security between
the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
to route traffic to the PaC.

  One view could be that the PaC is already vulnerable to rogue PAAs on
the local network.  That local network may, however, be limited in the
number of systems, and what they're allowed to do.  My presumption is
that the PRE to PAA network is a fully-connected network capable of
routing to arbitrary destinations.

  So adding a PRE opens the PaC to attacks from arbitrary sources on a
wide-area network, which would seem to be a violation of the PANA
assumptions.

  Alan DeKok.