Subject: [Pana] IETF LC and discussion: Next steps

From: "Alper Yegin" <[email-masked]>
Date: Tue, 6 Jun 2006 08:36:17 -0700

Following the IETF last call and IETF mailing list discussions, we had a
tele-chat with the ADs and identified a list of technical considerations for
the PANA WG to discuss.

The issues are mostly driven by the document readability and protocol
complexity. We are asked to consider the following questions and make a
decision. The decisions will be reflected on the documents before they
proceed to the IESG review.

We'll conclude the relevant discussions "before" the next IETF. For that,
please participate in the discussions. Act now -- last minute surprises or
late-comers are not welcome!

Each point should be discussed under a separate thread. If you are the first
one to tackle a question, start a new thread.

With that in mind:

[1] Can we remove the discovery part of the base specification? Can we
mandate the DHCP-based discovery as specified in a separate document?

[2] Do we really need to acknowledge PAA and EP separation and reflect it on
the protocol design?

[3] Do we need to specify PAA-to-EP protocol? Can't we mark it as out of
scope and not specify anything? Some people have concerns about using SNMP
for configuration.

[4] Can we drop PANA-IPsec? Can't we only consider cases where the
lower-layer is already secured?

[5] Can we drop the enabling L2 security from the specs? People can still do
that, but we'd avoid its discussion in the specs (which has raised many
concerns, e.g., IEEE 802.11)

[6] Can we remove the NAP-ISP separation support from the base spec?

[7] Can we refocus and simplify the PANA framework document? For example, we
can highlight the network access authentication aspect, and dim others (such
as network selection, secure association, etc.). Also, we can remove section
10 (DSL and WiFi deployments). 

Chairs

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

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 6 Jun 2006 17:08:24 -0700 (PDT)

> lower-layer is already secured?
I am sort of neutral on this. There is a separate
question about L2 security. If we drop that too,
then PANA applies to only the physically secured
link case which is very limiting.

We were targeting informational for Pana-ipsec.
If we are not really concerned about inter-op,
then perhaps folks can figure out how to use IPsec
without needing to read an RFC.

I feel that L2 security makes more sense and probably
we should keep that.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Jun 2006 09:07:40 -0400

> [6] Can we remove the NAP-ISP separation support from the base spec?

I think we can remove NAP and ISP separate authentication from the
base spec.  Perhaps we can design the feature in more a generic way
(e.g., allowing more than two EAP runs in parallel) in a separate
document.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 7 Jun 2006 16:46:59 +0200

Hi all,

> without needing to read an RFC.

 what's exactly the problem with keeping pana-ipsec ?

> I feel that L2 security makes more sense and probably

 I think we also need that but don't yet have WG document.

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 07 Jun 2006 19:32:33 +0300

Inline:

>  what's exactly the problem with keeping pana-ipsec ?

The intent here is to simplify the PANA protocol. Does PANA without the
IPsec part become hobbled or unusable? I don't think so. Without the IPsec
part, PANA provides security that is equivalent to the http based logins at
hotspots. For most scenarios, that may be sufficient.
Additionally how realistic is it that a  host will do IKE and setup an IPsec
SA with the access network just for securing the user data traffic? If user
data is critical, then the user will have VPNs or TLS to the server. So the
use of IPsec is primarily for access control only. And since IPsec is
optional we can possibly live without the specification being a core aspect
of the PANA protocol.

>  I think we also need that but don't yet have WG document.

We are trying to simplify the protocol by stripping out features that "MAY"
be non-essential. So lets not add more now.

-Raj

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 07 Jun 2006 14:07:05 -0400

Hi Raj,

Currently PANA is supporting:

a. Networks where a secure channel is already available prior to
   running PANA

b. Networks where a secure channel is created after running PANA

The general question would be whether we want PANA supporting both cases 
or not.

To understand, are you saying PANA should not support b) in the base-spec?

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Jun 2006 15:33:25 -0400

Also, there is Mark's comment in another thread:
> There is precedent in other groups for advancing discovery
> separately from a base protocol (L2VPN/PWE3 and softwires, for
> example). Given that there are already multiple ways to do PANA
> discovery, I would consider pulling this out of the base
> specification as well, allowing it to advance as its own document.

Initially I thought discovery should be integral part of base
specification.  But going through comments in IETF mailing list (some
person raised an issue on administrative scoped multicast in multi-hop
environment and some person indicated anycast) and private discussion,
now I have an impression that it might be good to define discovery in
separate document(s).  We can even define default preference among
multiple discovery methods in a separate document.

Yoshihiro Ohba

---

From: selina <[email-masked]>
Date: Thu, 08 Jun 2006 15:44:09 +0800

Hi, everyone:

> 
> [3] Do we need to specify PAA-to-EP protocol? Can't we mark 
> it as out of scope and not specify anything? Some people have 
> concerns about using SNMP for configuration.
> 

I want to know the reason that SNMP is selected to act as PAA-to-EP
protocol.
And why the other protocols such as Radius/Diameter or COPS are not
appropriate.

Selina
Thanks

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 08 Jun 2006 10:54:27 +0300

Hi Rafa,

Inline:

> a. Networks where a secure channel is already available prior to

Raj> No need for a PANA-IPsec setup in this case.

> b. Networks where a secure channel is created after running PANA

Raj> The need for establishing a secure channel depends on the use
case/scenario. Does PANA need to understand the underlying capability of the
link (i.e in this case it is not secured)? Or does PANA basically enable
network access and let the security for the user data be of no concern to
PANA but to some other protocol?
If a user needs to secure the data traffic, then its up to the user to
establish a VPN or some other form of securing the traffic. What we should
be more concerned about is if PANA authentication/authorization for network
access is insufficient to prevent session hijacking and/or limit the ability
to do access control.

-Raj
 
> To understand, are you saying PANA should not support b) in the base-spec?

What I am saying is that support for "b" is not a core aspect of PANA and
hence need not be part of the base-spec.

-Raj

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 8 Jun 2006 11:57:40 +0200

Hi all,

> hotspots. For most scenarios, that may be sufficient.

 agree.

> optional we can possibly live without the specification being a core aspect

 I didn't see pana-ipsec as a core aspect of the PANA protocol. 
 We say that if you want to secure user data
 traffic between MN and the EP by IPsec, PANA can help you but you don't
 have to. Maybe I miss something ?

 Julien

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 08 Jun 2006 13:12:30 +0300

>  have to. Maybe I miss something ?

I don't think you missed anything. It is true that currently the
establishment of the IPsec SA between the PaC and the EP is optional and
hence not a core aspect of the protocol. But within the context of PANA we
have an I-D that explains how the SA is setup and the base spec/framework
refers to this capability as well.
If we were to say simply that securing user data is outside the scope of
PANA, does it make the protocol any less useful? It is possible to have a
document that explains how user-data is secured using IKE/IPsec with PANA as
the authentication protocol as an Informational RFC but essentially not make
PANA dependent on the existence of such a specification.

-Raj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 8 Jun 2006 11:38:46 -0400

> access is insufficient to prevent session hijacking and/or limit the ability

Protected PANA-Ping exchange would be effective to detect session
hijacking.  However, if users also care integrity and confidentiality
of data packets and no VPN is used, the functionality to bootstrap
per-packet ciphering is needed.  As far as I understand, PANA proposal
in 3GPP2 relied on this functionality.  An issue here would be whether
this general functionality (i.e., use of Protection-Capability AVP and
PaC-EP-Master-Key) should be described in the base specification, or
in a separate document in which case document structure (in terms of
bootstrapping) could be:

1. Base specification draft

2. General bootstrapping per-pacet ciphering draft (defining Protection-Capability AVP and
   PaC-EP-Master-Key)

3. Lower-layer specific bootstrapping drafts (pana-ipsec, pana-ieee80211doti)

Note that 2) is a small piece compared to other optional feature such
as NAP and ISP separate authentication.

Yoshihiro Ohba

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 08 Jun 2006 18:53:11 +0300

Hi Yoshi,

On 6/8/06 6:38 PM, "ext Yoshihiro Ohba" <[email-masked]> wrote:

> hijacking.  

I think this is what we really need to ensure is specified as part of core
PANA protocol.

> However, if users also care integrity and confidentiality
> per-packet ciphering is needed.

This is optional as we have been said so in the past as well. And we need to
de-couple this from the core PANA protocol.

> As far as I understand, PANA proposal in 3GPP2 relied on this functionality.

In the case of PP2 there is already capability to cipher traffic at the
lower layer. So there is no reason to establish an IPsec SA for user
traffic. But anyway, the PP2 discussion is irrelevant here and I don't want
to go off on a tangent.

> An issue here would be whether

My view is that PANA should not be concerned at all about the user data
protection (i.e using IPsec between the PaC and EP).

> 1. Base specification draft

This I-D along with the capability that deals with sesssion hijacking (i.e
protected PANA ping).

> Protection-Capability AVP and

I don't think this is needed. Per-packet ciphering and how this is enabled
by PANA is not something that we want to get into. Not at this stage at
least.

> 3. Lower-layer specific bootstrapping drafts (pana-ipsec, pana-ieee80211doti)

These are informational and need not form a core aspect of what the WG
should deliver.

> as NAP and ISP separate authentication.

Cheers,
-Raj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jun 2006 16:37:24 -0400

Hi Basavaraj,

I have one comment.  Please see below.

> These are informational and need not form a core aspect of what the WG

3) is dependent on 2).  So 3) cannot exist without 2).

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jun 2006 19:38:52 -0400

> [2] Do we really need to acknowledge PAA and EP separation and reflect it on

IMO, this is an important functionality we should keep, considering
modern wireless technologies that allows access points/base stations
and their controllers to be separate entities.  

Yoshihiro Ohba

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 8 Jun 2006 16:42:28 -0700 (PDT)

HI,

I cannot see PANA used in a CAPWAP environment.

> and their controllers to be separate entities.  

Regards,
/david t. perkins

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jun 2006 20:02:31 -0400

There is no intention to use PANA in a CAPWAP environment where
link-layer EAP transport is typically used.  My point is that it is
better to place enforcement points on edge devices while
authentication agent does not have to be placed on the edge devices.

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 8 Jun 2006 17:51:10 -0700 (PDT)

Hi,

You need per-packet ciphering at L2 or L3 if
the link-layer is not physically secured. Please
see the threats document on why you need this.

> specified as part of core
I don't know how this would work. How often you
ping ? How does it work in PAA and EP separation
case ?

> de-couple this from the core PANA protocol.
How do you enforce that some malicious node is
not getting free service without ciphering at
L2 or L3 ?

-mohan

> > 2. General bootstrapping per-pacet ciphering draft
> (defining
> > Protection-Capability AVP and
> >    PaC-EP-Master-Key)
> 
> >>>> Additionally how realistic is it that a  host
> will do IKE and setup an
> >>>> IPsec
=== message truncated ===

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Jun 2006 10:28:05 +0300

Hi Mohan,

> see the threats document on why you need this.

No question about the vulnerabilities and threats that are exposed as a
result of not ensuring security at the lower layers. But the point is if
PANA needs to ensure that. PANA may enable it. But PANA need not be coupled
tightly with the need for securing the user traffic.

> ping ? How does it work in PAA and EP separation

Not clear about it. This was a proposal from Yoshi.

> not getting free service without ciphering at

You either rely on the existence of a L2 mechanism that is inherent to the
link or you figure out some other means of enforcing access control which
keeps malicious nodes from getting free service.
So the question is:
- Does PANA need to ensure that unsecured links have the ability to do
access control? How would PANA be able to determine if a link is secure or
not? Is there a way to figure that out? I don't think this can be easily
accomplished. Because even if a link layer has the capability to cipher, it
does not imply that it is enabled.

-Raj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Jun 2006 10:23:23 -0400

> Not clear about it. This was a proposal from Yoshi.

How often or in which case PANA-Ping is performed is an implementation
issue which we would not get into.

PANA-Ping must work transparently to EPs just like other PANA
messages do.

> does not imply that it is enabled.

There is no automatic way of knowing the security characteristics of
the link.  However, in the current PANA design, it is the PAA that
determines (based on configuration) if a link is secure or not.  The
administrator that configures the PAA must have knowledge about the
security characteristics of the link.  PaCs need to follow the PAA's
decision to use link layer ciphering determination or it will not get
access.  I don't think there is an issue in this design.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Jun 2006 10:56:00 -0400

Hi Selina,

As far as I remember, the decision is based on the evaluation made for 
MIDCOM protocol.  The evaluation is published as RFC 4097.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 9 Jun 2006 17:41:26 +0200

Hi selina,

 you may also read:
 http://www.watersprings.org/pub/id/draft-yacine-pana-paa2ep-prot-eval-00.txt

 My 2 cents,

 Julien

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 9 Jun 2006 09:42:04 -0700 (PDT)

> PANA-Ping must work transparently to EPs just like
I guess we should take this in a separate
thread or offline..(Are you proposing this as an
alterntive to L2 or L3 ciphering).

> > >> This is optional as we have been said so in the
> past
> > >> as well. And we need to
Yes, i agree that this is perfectly fine. 

-mohan

> > >> In the case of PP2 there is already capability
> to
> > >> cipher traffic at the
> > >> lower layer. So there is no reason to establish
> an
> > >> IPsec SA for user
> > >>> PaC-EP-Master-Key) should be described in the
> base
> > >> specification, or
> > >> My view is that PANA should not be concerned at
> all
> > >> about the user data
> > >> This I-D along with the capability that deals
> with
> > >> sesssion hijacking (i.e
> > >> protected PANA ping).
> > >> 
> > >>> 
> > >> I don't think this is needed. Per-packet
> ciphering
> > >> and how this is enabled
> > >> by PANA is not something that we want to get
> into.
> > >> Not at this stage at
> > >> least.
> > >> 
> > >>> 
> > >> These are informational and need not form a
> core
> > >> aspect of what the WG
> > >> should deliver.
> > >> 
> > >>> 
> > >>> Note that 2) is a small piece compared to
> other
> > >> optional feature such
> > >>>>> The general question would be whether we
> want
> > >> PANA supporting both cases
> > >>>>> or not.
> > >>>>> 
> > >>>>> To understand, are you saying PANA should
> not
> > >> support b) in the base-spec?
> > >>>> 
> > >>>> What I am saying is that support for "b" is
> not a
> > >> core aspect of PANA and
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 9 Jun 2006 15:19:51 -0700

We know that client authentication is not sufficient to fully secure the
network access. Per-packet integrity and origin authentication needs to be
enabled.

If we only consider the cases where such protection is enabled prior to
PANA, that limits the deployment scenarios considerably.

Besides, covering both types of cases has very limited impact on the base
PANA protocol (a key derivation, and a capability exchange). 

For that, I don't think it makes sense to drop supporting the deployment
case where aforementioned protection is enabled after successful PANA
authentication. 

As for the use of IPsec, there is nothing specific to IPsec in the base
protocol, aside from indicating its use via capability exchange. 

Whether PANA-IPsec I-D (draft-ietf-pana-ipsec-07.txt) is there or not is not
going to make an impact on the base protocol specification.

I think we need the PANA-IPsec I-D to ensure interoperability.

My 0.02 cents.

Alper

> -----Original Message-----
> From: Mohan Parthasarathy [mailto:[email-masked]]
> Sent: Friday, June 09, 2006 9:42 AM
> To: Yoshihiro Ohba; Basavaraj Patil
> Cc: ext Julien Bournelle; ext Yoshihiro Ohba; [email-masked]; ext Mohan
> Parthasarathy; 'Jari Arkko'; ext Rafa Marin Lopez; 'Mark Townsley'
> Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next
> steps)
> 
> 
> 
> > >

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 9 Jun 2006 15:31:41 -0700

If the separate document is going to say what we already have in the base
specification, I don't see why we should spin it off. Especially given that
the base document would have a dependency on the discovery document, which
is likely to take a lot of time and unnecessarily delay the PANA
standardization.

Alper

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2006 12:33 PM
> To: Alper Yegin
> Cc: [email-masked]; 'Mark Townsley'; 'Jari Arkko'
> Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next steps]
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 20 Jun 2006 22:14:49 -0400

Hi Alper, sorry for the delayed answer.

I agree with your comments.

Personally, I would prefer PANA base spec "had in mind" when link is
unsecured and some kind of security association needs to be bootstrapped.
Mohan gave also some reasons for that ("per-packet ciphering at L2 or L3 if
the link-layer is not physically secured")

Certainly PANA base spec does not need to be very specific on this
(others I-D will do that), but at least maintaining certain kind of
hooks like Protection-Capability AVP or PaC-EP-Master-Key generation
would be needed.(though i have doubts if this PaC-EP-Master-Key generation
should be specified in specific I-Ds explaining PANA-IPsec or 
PANA-ieee802.11i
instead of pana-base spec).

Also my 0.01 cents.

Alper Yegin wrote:

>>>>Not clear about it. This was a proposal from
>>>>        
>>>>
>>>Yoshi.
>>>
>>>>>>>However, if users also care integrity and
>>>>>>>              
>>>>>>>
>>>>>>confidentiality
>>>>>>            
>>>>>>
>>>>>>>of data packets and no VPN is used, the
>>>>>>>              
>>>>>>>
>>>>>>functionality to bootstrap
>>>>>>            
>>>>>>
>>>>You either rely on the existence of a L2 mechanism
>>>>        
>>>>
>>>that is inherent to the
>>>      
>>>
>>>>link or you figure out some other means of
>>>>        
>>>>
>>>enforcing access control which
>>>      
>>>
>>>>- Does PANA need to ensure that unsecured links
>>>>        
>>>>
>>>have the ability to do
>>>      
>>>
>>>>access control? How would PANA be able to
>>>>        
>>>>
>>>determine if a link is secure or
>>>      
>>>
>>>>not? Is there a way to figure that out? I don't
>>>>        
>>>>
>>>think this can be easily
>>>      
>>>
>>>>accomplished. Because even if a link layer has the
>>>>        
>>>>
>>>capability to cipher, it
>>>      
>>>
>>>>>>>As far as I understand, PANA proposal in 3GPP2
>>>>>>>              
>>>>>>>
>>>>>>relied on this functionality.
>>>>>>
>>>>>>>this general functionality (i.e., use of
>>>>>>>              
>>>>>>>
>>>>>>>in a separate document in which case document
>>>>>>>              
>>>>>>>
>>>>>>structure (in terms of
>>>>>>            
>>>>>>
>>>>>>>bootstrapping) could be:
>>>>>>>              
>>>>>>>
>>>>>>protection (i.e using IPsec between the PaC and
>>>>>>            
>>>>>>
>>>EP).
>>>      
>>>
>>>>>>>2. General bootstrapping per-pacet ciphering
>>>>>>>              
>>>>>>>
>>>draft
>>>      
>>>
>>>>>>(defining
>>>>>>            
>>>>>>
>>>>>>>3. Lower-layer specific bootstrapping drafts
>>>>>>>              
>>>>>>>
>>>>>>(pana-ipsec, pana-ieee80211doti)
>>>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 24 Jun 2006 10:30:33 -0400

> is likely to take a lot of time and unnecessarily delay the PANA

As long as we can add other discovery mechanisms in separate documents
when needed in a future, it is ok for me.  From this perspective, let
me analyse Section 4.3 of the PANA specification:

"
   When the PaC knows the IP address of the PAA, it can send a unicast
   PANA-PAA-Discover message and initiate the PANA exchange.  In other
   cases, the PaC MUST rely on dynamic discovery methods, such as
   multicast-based and a traffic-driven discovery.
"

For example, if we have a plan to define an anycast-based discovery
mechansim, then we can define the mechanism as a case where the PaC
knows the IP address of the PAA.  So once the mechanism is defined and
implmented, then we do not have to rely on the multicast-based
discovery.  The same discussion applies to DHCP-based discovery
mechanism.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 24 Jun 2006 10:49:55 -0400

Going back to the original question, if someone has concerns about
using SNMP for configuration (I don't know why), then what we can do
is to specify a PAA-to-EP protocol using SNMP but without mandating to
implement one.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sat, 24 Jun 2006 23:48:05 -0400

Hi Yoshi...

>is to specify a PAA-to-EP protocol using SNMP but without mandating to
I agree in this point. I do not see any specific concern about using
SNMP. I would also say that SNMP is generally used in current devices.
As it has been also pointed by Julien, some previous study
http://www.watersprings.org/pub/id/draft-yacine-pana-paa2ep-prot-eval-00.txt

explain reasons to use SNMP.

In any case, as you say maybe no mandating to implement one might be a
good option to avoid people concerns (if any).

My 0.01 cents.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 28 Jun 2006 17:26:44 -0700

That makes sense to me.

Alper

> Sent: Saturday, June 24, 2006 7:31 AM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; 'Jari Arkko'; [email-masked]
> Subject: Re: Discovery [was Re: [Pana] IETF LC and discussion: Next steps]
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Jun 2006 10:26:57 -0400

> instead of pana-base spec).

I agree, and this answers to issue [5] as well.

"

Yoshihiro Ohba