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