Re: Last Call: 'PANA Framework' to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 18 Mar 2006, The IESG wrote:
The IESG has received a request from the Protocol for carrying Authentication
for Network Access WG to consider the following document:

- 'PANA Framework '
  <draft-ietf-pana-framework-06.txt> as an Informational RFC

I read the PANA framework document on the plane.

I think there are a number of serious issues in there which may also reflect
the protocol document (which I didn't look at).

substantial
-----------

1) the document makes a big deal about spoofing and eavesdropping
protection, but doesn't say a word about local DoS attacks (e.g., which
could prevent getting an address in the first place, getting a duplicate
address, etc. -- see the SEND documents for more on this).  These should be
discussed somewhere.

2) deployment assumptions (e.g., where protocol needs to be supported, and
what exactly needs to be supported) needs to be spelled out better.

      An EP must be located strategically in a local area network to
      minimize the access of unauthorized clients to the network.  For
      example, the EP can be hosted on the switch that is directly
      connected to the clients in a wired network.  That way the EP can
      drop unauthorized packets before they reach any other client node
      or beyond the local area network.

(also section 4.b, 2nd paragraph)

and also:

To achieve this, each PAA/EP device on an
   link-layer switch or access point MUST NOT forward multicast PANA
   discovery message sent by PaCs attached to it to other devices.  This
   model is suitable for an access network with a small number of EPs.

==> it's not clear what your deployment assumptions are.  Is it required
that the first L2 device port supports PANA? What support does that mean? Are the users required to do forklift upgrades? What kind of support are you
exactly requiring?  Do you require EAP?

3) DSL scenario's security assumptions are not spelled out.

       One example is a DSL network where the lower-layer security is
      provided by physical means (a.1).  Physical protection of the
      network wiring ensures that practically there is only one client
      that can send and receive IP packets on the link.

==> depends on the definion of the 'client'.  Multiple PCs sitting at home
behind such a DSL box can see each other just fine (especially if you don't
run stuff like PPPoE), and I don't think PANA helps here unless the first-hop
devices are also doing PANA.  Hence, you're making assumptions about what
PANA needs to protect in the scenario you describe, but these assumptions
should be spelled out loud and clear.

4) v4 link-local addresses should not be assumed

      In case there is no running DHCP server on the link, the client
      would fall back to configuring a PRPA via zeroconfiguration
      technique [RFC3927].

==> are you assumoing that the clients will use RFC3927 v4 link-local
addressing  (which would be IMHO inappropriate) or did you mean s/would/might/?

Other than that, I think the document's emphasis on RFC3927 link-local
addresses should be reduced to almost zero.  If you can't assume they exist,
you will need to deploy DHCPv4 or some other means of getting addresses, and
hence v4 link-locals don't bring you anything useful (except in cases where
the DHCP server could be down).

Hence, I don't think v4 link-locals should be mentioned except as an odd
curiousity.

5) how do you deal with link-local address -only scenarios?

   2. If the network uses IPsec for protecting the traffic on the link
      subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
      would use the PRPA as the outer address of IPsec tunnel mode SA
      (IPsec-TOA).  The PaC also needs to configure an inner address
      (IPsec-TIA).  There are different ways to configure an IPsec-TIA
      which are indicated in a PANA-Bind-Request message.

==> are you assuming that you will be able to pass v6 link-local addresses
e.g., in IKE?  Note that the address is going to be ambigous outside of the
link, and even inside the link, you'll need a link identifier or certain
other hacks.

Hence, it seems that if you need to use IKE, IPsec or whatever, you just
you WILL need to deploy non-link-local addresses as well -- the v6
link-locals just aren't enough in that scenario.

6) does the framework assume that it's always PAA that detects new PaC?  Can
a PaC start a PANA exchange voluntarily?

7.2.  Notification of PaC Presence

   When PAA and EP are separated and PAA is configured to be the
   initiator of the discovery and initial handshake phase of PANA, EP
   has the responsibility to detect presence of a new PaC and notifies
   the PAA(s) of the presence [RFC4058].  Such a presence notification
   is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp].

7) the doc only refers to Diameter AVPs.  What about RADIUS or LDAP, or
should folks just use proprietary extensions?   The doc also doesn't seem to
specify a mandatory-to-implement minimum subset of PANA.  Hopefully the
protocol specification at least does, so that different implementations of
PANA components can be compliant!

 In addition to the device
   identifier and keying material, other filter rules, such as the IP
   filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
   EAP application [RFC4072] may be installed on EP.  When IPsec is used
   the filter rules are applied to IP packets carried inside the IPsec
   tunnel, otherwise, the filter rules are applied to IP packets that
   are not protected with IPsec.



semi-editorial
--------------

   Finally, filters that are installed at the EP allow general purpose
   data traffic to flow between the PaC and the intranet/Internet.

==> what you don't mention at all is how you clean up the unused and no
longer necessary filters?

   1. If the network relies on physical or link layer security, the PaC
      can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6
      stateless auto-configuration [RFC2461].  An IPv4 PRPA SHOULD be
      unconfigured when the POPA is configured to prevent IPv4 address
      selection problem [RFC3927].  If IPv6 is used, the link-local PRPA
      SHOULD NOT be unconfigured [RFC3484].

==> s/SHOULD NOT/MUST NOT/, each interface is required to have a link-local
address

11.  Security Considerations

   Security is discussed throughout this document.  For protocol-
   specific security considerations, refer to [I-D.ietf-pana-pana].

==> however, this discussion is insufficient; e.g., DoS attacks are not
properly discussed, and the remainder threats are not enumerated.  This
probably needs to be extended.

   [I-D.ietf-eap-netsel-problem]
              Arkko, J. and B. Aboba, "Network Discovery and Selection
              Problem", draft-ietf-eap-netsel-problem-03 (work in
              progress), October 2005.

==> this seems rather important issue for the draft; should this be a
normative reference?

editorial
---------


                           PANA Framework
                      draft-ietf-pana-framework-06

==> spell out PANA.

   3. In IPv6, clients automatically configure a link-local address
      [RFC2462] when they initialize an interface.  Additionally, they
      may also configure global address(es) when DHCP or router
      advertisements with global prefixes are made available to the
      them.

==> "global" is tricky with v6, because it might not include Unique Local
Addresses (ULAs) for example, depending on how you defined "local".  Easiest
fix is to say "non-link-local" if that doesn't sound too bad.

In addition to the fresh and unique session key derived
   from the EAP method, IPsec also needs both traffic selectors and
   other IPsec SA parameters are missing.

==> I'm having trouble parsing the latter part of the sentence...

The DSL Modem/RG may also use NAPT
   (Network Address Port Translation).

==> this seems irrelevant and should probably be removed.

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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]