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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf