Subject: [Pana] Re: Last Call: 'PANA Framework' to Informational RFC

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 04 Apr 2006 10:00:40 -0400

Thank you for reviewing the pana-framework draft and sorry for delayed
response.  Please see my comments below.

On Mon, Mar 27, 2006 at 11:26:10AM +0300, Pekka Savola wrote:
> 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.

The DoS attacks are described in RFC 4016 (Protocol for Carrying
Authentication and Network Access (PANA) Threat Analysis and Security
Requirements), and we can add a reference to RFC 4016.

> 
> 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?

YO: When PAA and EP are co-located on a first L2 device, the L2 device
needs to implement both PAA and EP functinalities.  If a first L2
device is not acting as PAA but EP, it needs to implement EP
functionality but not PAA functinality.  If a first L2 device is not
acting as PAA or EP (this is possible in the case of IPsec ciphering),
then it does not needs to implement any functionality described in the
PANA framework.  Also, any implementation of the PAA functinality of
the PANA protocol requires implementation of authenticator
functionality of 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.

In this specific example of Section 4, it is assumed that the PANA
client is implemented on DSL model/Regidential Gateway.  We can have
explict text this assumption on this specific example.

> 
> 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/?

It should be 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.

We can reduce emphasis on RFC3927.

> 
> 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.

No, we don't assume carrying link-local address in IKE.

> 
> 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.

IPsec-TIA needs to be non-link-local.  But this does not mean that
IPsec-TOA should always be non-link-local as well.

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

Detection of PaC's presense is not always required.  A PaC can start
PANA exchange voluntarily, and this is actually mandatory supported
method for PAA discovery that is described in the protocol document in
detail.

> 
> 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.

There was a great amount of discussion on this issue and there is
following consensus in the PANA WG:

  - For PAA to EP protocol, SNMP MUST be implemented, while other
  protocols can be used when available.  (This is described in Section
  7).

  - For PAA to authentication server (AS) protocol, there is no
  mandatory protocol specified.  This is exactly what
  IEEE 802.11i and IKEv2 specifications do, i.e., they carry EAP but
  does not specify any mandatory supported protocol between EAP
  pass-through authenticator and AS.

> 
> 
> 
> 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?

I agree.  We can mention uninstalling 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

I agree.

> 
> 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.

DoS attacks and other threats are described in RFC 4016 and we can
refer to RFC 4016 in this section.

> 
>    [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?

We make the netsel draft informative because it provides background
information and does not require to implement the technology described
in pana-framework draft.

> 
> 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.

OK, we will expand it.

> 
> ==> "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.

I agree on replacing "global" with "non-link-local".

> 
> 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...

Removing "are missing" should work.

> 
> The DSL Modem/RG may also use NAPT
>    (Network Address Port Translation).
> 
> ==> this seems irrelevant and should probably be removed.

We will remove this sentense.

Thanks again,
Yoshihiro Ohba

> 
> -- 
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 05 Apr 2006 14:24:29 -0400

On Wed, Apr 05, 2006 at 01:40:59PM +0300, Pekka Savola wrote:
> Inline, just responding to a couple of substantial issues,
> 
> On Tue, 4 Apr 2006, Yoshihiro Ohba wrote:
> >Authentication and Network Access (PANA) Threat Analysis and 
> >Security Requirements), and we can add a reference to RFC 4016.
> 
> Good.  (Note that I didn't actually look at that RFC to analyze 
> whether the issues are sufficiently discussed, but I hope so...)

Just FYI, let me quote the related text in RFC 4016:

"
   T6.6.2: PaC acquires an IP address by using stateful or stateless
           mechanisms before PANA authentication begins [PANAREQ].  When
           the IP addresses are assigned before the client
           authentication, it opens up the possibility of DoS attacks in
           which unauthenticated malicious nodes can deplete the IP
           address space by acquiring multiple IP addresses or deny
           allocation to others by responding to every duplicate address
           detection (DAD) query.

           Depleting a /64 IPv6 link-local address space or a /8 RFC1918
           private address space requires a brute-force attack.  Such an
           attack is part of a DoS class that can equally target the
           link capacity or the CPU cycles on the target system by
           bombarding arbitrary packets.  Therefore, solely handling the
           IP address depletion attack is not going to improve the
           security, as a more general solution is needed to tackle the
           whole class of brute-force attacks.

           The DAD attack can be prevented by deploying secure address
           resolution that does not depend on the client authentication,
           such as [SEND].  The attack may also be prevented if the EP
           is placed between the PaCs to monitor the ND/ARP activity and
           to detect DAD attacks (excessive NA/ARP replies).  If none of
           these solutions are applicable to a deployment, the PaCs can
           send arbitrary packets to each other without going through
           the EP, which enables a class of attacks that are based on
           interfering with the PANA messaging (See T6.1.1).  Since
           there will always be a threat in this class (e.g., insecure
           discovery), it is not going to improve the overall security
           by addressing DAD.
"

> Each of these scenarios and the implications whould probably be 
> spelled out, maybe in separate subsections, to make each PANA 
> scenario and its implications clear to the reader.

OK.  We will add those scenarios and implications in the draft.

> 
> You didn't answer what "MUST NOT forward multicast PANA discovery 
> message sent by PaCs attached to it to other devices" meant.  Did you 
> mean that you require modifications in the data plane in switches and 
> access points under certain situations?  

Yes, this requires a specific filter for multicast PANA discovery
message on the EP implmementation in switches and acess points.

> Does this apply to only 
> PANA-implementing switches/APs or also to others?  This should be 
> spelled out loud and clear.

This (i.e., "MUST NOT forward multicast PANA discovery message...  to
other devices") applies to only switches/APs that act as both EP and
PAA.  We will revise the text for more clarification on this.

> But you do assume that if you use IPsec encryption, the decryption 
> must happen on the same link (e.g., by the router) unless non-link 
> local addresses are used, right?  

Yes.

> The current framework doesn't 
> describe the scenario where non-link local addresses are used for this 
> AFAIR.

We will add some text on the scenario where non-link local address is
used for IPsec TOA, i.e., the IPsec EP is not on the same link as PaC.

> 
> Note that I'm personally of the opinion that IPsec or IKE shouldn't 
> need to be run with link-local addresses as outer addresses either if 
> it can be avoided.
> 
> .. but not described in the framework AFAIR?

You are right.  We will have explicit text on this.

Thank you,
Yoshihiro Ohba