Subject: Re: [Pana] review of the framework draft

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 01 Jun 2005 14:41:17 -0400

Hi Jari,

Thank you very much for the review.  Please see my comments in line.

On Mon, May 30, 2005 at 06:13:01AM +0300, Jari Arkko wrote:
> I have reviewed draft-ietf-pana-framework-04.txt. Here are
> my comments:
> 
> Technical:
> 
> >      The PAA consults an authentication server in order to verify the
> >      credentials and rights of a PaC.  If the authentication server
> >      resides on the same node as the PAA, an API is sufficient for this
> >      interaction.  When they are separated (a much more common case in
> >      public access networks), a protocol needs to run between the two.
> >      LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and
> >      Diameter [RFC3588] are commonly used for this purpose.
> 
> LDAP is indeed often used like this, but I'm not sure it is
> appropriate to refer to it in this context. I believe you are
> trying to describe how PANA works, and I don't think EAP
> works through LDAP. (But I have often been surprised.)

I think we can simply remove "LDAP [RFC3377] and ".

> 
> >   The secure
> >   association protocol exchange produces the required security
> >   associations between the PaC and the EP to enable cryptographic data
> >   traffic protection.  Per-packet cryptographic data traffic protection
> >   introduces additional per-packet overhead but the overhead exists
> >   only between the PaC and EP and will not affect communications beyond
> >   the EP.  In this sense it is important to place the EP as close to
> >   the edge of the network as possible.
> 
> I would suggest deleting the last sentence. Bandwidth bottlenecks are
> often in the last (wireless) hop, so moving the EP closer to the edge may
> not help. And for security reasons it might often make sense to have an
> EP further towards the center of the network than at the edge.

In which case it would make sense for security reasons to have EP
further towards the center of the network?

> 
> >      IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6
> >      IPsec-TIA for the same IPsec tunnel mode SA.  Therefore, IKEv2 is
> >      recommended for handling dual-stacked PaCs where single execution
> >      of PANA and IKE is desired.
> 
> I understand this, but I started to wonder whether you have described
> all possible combinations somewhere. What is the order of events when
> you start to see both v4 and v6 pre-pana connectivity? And how does a
> client know it needs to do IKEv2 and a single PANA run?

I agree that we need to describe all possible combinations when the
PaC starts from having both v4 and v6 PRPAs.  I think it is better to
create a new issue on this.

> 
> >   Network-layer protection, i.e., IPsec, can be used when data traffic
> >   protection is required but link-layer protection is not available.
> >   Note that the keying material generated by an EAP method is not
> >   readily usable by IPsec AH/ESP or most link layer mechanisms.  A
> >   fresh and unique session key derived from the EAP method is still
> >   insufficient to produce an IPsec SA since both traffic selectors and
> >   other IPsec SA parameters are missing.  The shared secret can be used
> 
> Maybe s/is not readily usable/is insufficient to be used alone/ and
> s/A fresh and unique session key derived from the EAP method is still
> insufficient to produce an IPsec SA since both traffic selectors and
> other IPsec SA parameters are missing/In addition to the fresh
> and unique session key derived from the EAP method, IPsec also
> needs both traffic selectors and .../

I agree.

> 
> >   When a PaC is authenticated and authorized, the PAA should notify
> >   EP(s) and ask for installing filtering rules to allow the PaC to send
> >   and receive data traffic.  SNMP is used between PAA and EP(s) for
> >   this purpose when these entities are not co-located [I-D.ietf-pana-
> >   snmp].
> 
> It worries me a bit that determining the exact filters to be used is
> not easy, given v4/v6, features like RFC 3041, the need to allow
> PANA traffic to go through to PAA, the flexibility in the PANA
> framework e.g. to allow both no/L2/L3 protection, and error cases.
> I'm reviewing all the documents now -- is the set of filters
> to be used specified somewhere?

draft-ietf-pana-snmp specifies filters, but the draft does not specify
which specific filters should be used for each of the above scenarios.
However, I think such detailed choice of filters is better to be left
open to implementations.

> 
> >   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 [I-D.ietf-aaa-eap] may be installed on EP.
> 
> Presumably the AAA filter rules are applied for inner packets,
> whereas PANA filters are applied on the outer packet, if IPsec
> is used. Perhaps this should be stated. 

I agree.  

> What if IPsec is not used,
> what is the relationship then?

When IPsec is not used, the filters are applied to the non-protected
IP data packets.

> 
> >   The authentication method choice is a function of the underlying
> >   security of the network (e.g., physically secured, shared link,
> >   etc.).  It is the responsibility of the user and the network operator
> >   to pick the right method for authentication.  PANA carries EAP
> 
> 
> I agree that individual methods should not be specified in PANA.
> But you might still want to describe requirements, as in RFC 4017
> for IEEE 802.11 networks. It may well be that you want to describe
> two scenarios -- physical security per line, then maybe mutual auth
> is enough, in other scenarios you need key-deriving eap methods.

I think describing the generic EAP method choices for the two
scenarios is a good idea.

> 
> > There are some EAP-
> >   based approaches to achieve this goal (see [I-D.josefsson-pppext-eap-
> >   tls-eap],[I-D.ietf-pppext-eap-ttls]
> >   ,[I-D.tschofenig-eap-ikev2]).  PANA can carry these EAP encapsulating
> >   methods but it does not concern itself with how they achieve
> >   protection for the weak methods (i.e., their EAP method payloads).
> 
> I would delete this. There's much more to say about specific methods
> if you want to start talking about. I don't recommend starting...

I agree.

> 
> Editorial:
> 
> >   are not distinguishable until the PaC associates with the AP, get an
> 
> 
> s/get/gets/

OK.

Yoshihiro Ohba

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

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jun 2005 09:12:10 +0300

>I think we can simply remove "LDAP [RFC3377] and ".
Ok.

>further towards the center of the network?
In a network where even the hops beyond the first one are vulnerable.

>create a new issue on this.
Ok.

>However, I think such detailed choice of filters is better to be left
We have an ongoing discussion about the IPsec-level filter in the ipsec
document.
I agree that implementations should have some freedom (e.g. add any specific
filtering they want), but creating such filter sets that work well is
not trivial,
and I would at least like to be convinced that we can create those sets.
There
are plenty of examples where specifications said just filter something,
but it
turned out to be impossible in practise. So I would suggest that we specify
this.

>When IPsec is not used, the filters are applied to the non-protected
Ok.

>scenarios is a good idea.
Ok.

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 02 Jun 2005 11:47:56 -0700

Hi Jari,

Let me chime in on two of your review comments.

> turned out to be impossible in practise. So I would suggest that we

PANA-IPSEC document is already doing that for the IPsec-based
deployments. Is your recommendation to specify filters for DSL and
WAP/11i deployments in the PANA-FWK I-D?

> >scenarios is a good idea.

I think the EAP method requirements are dependent on the characteristics
of the deployment environment (open wireless, physically secured, etc.),
as opposed to the EAP transport (1X, 11i, PANA, PKMv2, etc.). If you
agree, then we should document the requirements centered around the
former criteria, not the latter. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Jun 2005 16:07:06 -0400

Hi Jari,

> In a network where even the hops beyond the first one are vulnerable.

One issue is that the revised text for new PANA charter is based on
the fact that EP is in the edge network in the case of bootstrapping
IPsec (and it is obvious that EP must be in the edge network in the
case of bootstrapping L2 ciphers):

"
Network access authentication enables the client to be authorized for
packet data service. However it is possible that the underlying link
itself is insecure, i.e the packets being sent to and received on the
link between the client (PaC) and the 1st hop access router (EP) in the
network are not protected by any physical or cryptographic
means. In such cases, PANA will enable the establishment of an IPsec
SA between the client and the 1st hop access router to secure the
packets on the link.
"

So I think this is a charter issue.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jun 2005 23:36:32 +0300

>WAP/11i deployments in the PANA-FWK I-D?
That would be an option, but I would personally be OK
with having one complete specification of the filtering,
say for the IPsec case.

>former criteria, not the latter. 
Yes, that makes sense.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jun 2005 23:42:02 +0300

>So I think this is a charter issue.
I see.

Ok, but what I suggested was deleting the sentence that
argues why the close-to-edge placement is a good thing. This
deletion does not appear to be problematic even with the new
charter. OTOH, do we have a real technical limitation in the
protocol that it MUST be the first hop? If yes, just state this
(but without arguments).

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Jun 2005 17:58:59 -0400

On Thu, Jun 02, 2005 at 11:42:02PM +0300, Jari Arkko wrote:
> argues why the close-to-edge placement is a good thing. 
> This deletion does not appear to be problematic even with the new
> charter. 

I see your point.  I am fine with removing the sentence.

> OTOH, do we have a real technical limitation in the

I don't think there is a technical limitation in the PANA protocol
even when EP is multiple hops away from the PaC.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 2 Jun 2005 16:54:26 -0700

Jari,

> In a network where even the hops beyond the first one are vulnerable.
I don't understand how moving EP to the center improves the security ?
Doesn't moving EP to the center means that we have more
of the network vulnerable to the attackers ? Previously, the malicious packets
were dropped at the edge. If you move EP to the center, the packets
are traversing more network elements and potentially cause more damage ?
I thought filtering at the edge is more secure. 

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Jun 2005 08:09:59 +0300

>even when EP is multiple hops away from the PaC.
Ok

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Jun 2005 08:14:04 +0300

>I thought filtering at the edge is more secure. 
These are fair questions. I guess we can conclude that there are different
viewpoints that you can look at. For instance, if you are mostly concerned
that no unauthenticated client traffic gets to the Internet, then placing
the EP closer to the center of the access network is better, at least when
you have wireless intermediate hops. OTOH, if you are concerned with
resource usage within the network, or want to prevent two clients
from talking to each other, then placing the EP closer to the edge makes
more sense.

--Jari