Subject: Re: [Gen-art] RE: [Pana] Re: GenART review of draft-ietf-pana-fra mework-06.txt

From: Jari Arkko <[email-masked]>
Date: Sun, 14 May 2006 15:54:51 +0300

[email-masked] wrote:

>>>>I understand.  I agree on replacing all IKEv1 references with IKEv2
>>>>references.
>>>>        
>>>>
>>>Does that mean the specs will only support IKEv2, and IKEv1 is not
>>>supported? Do we really want to have such a limitation?
>>>      
>>>
>>There are definitely vendors who would be disturbed by such a restriction.
>>I don't know what the security area policy on this.
>>    
>>
>
>I believe the Security Area allows whatever makes sense.  I would have no
>problem with "IKEv2 [] referenced anywhere IKEv1 is" as was stated in the
>original review, and it would probably be possible to get the current
>IKEv1-only situation through the security area ADs if IKEv2 raised new
>issues around integration w/PANA that are not covered in the current
>PANA draft, but that would need to be explicitly stated in the draft.
>  
>
>From a theoretical perspective it would be interesting to know
whether there's any difference between using IKEv1 and IKEv2
for this purpose. But from an interoperability perspective it
would be very useful for implementors to know if they need
to support one or the other. PANA clients need to work
with PANA network infrastructure, and mandating both versions
would propably be an overkill.

I agree with David that IKEv2 should be the default assumption
in new specs unless we have a very good reason to say otherwise.

--Jari

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 May 2006 09:43:55 +0300

> in new specs unless we have a very good reason to say otherwise.

Jari,

Can you expand on this a bit more, so that we know what to do in the PANA
framework document. Given that both IKEv1 and IKEv2 can be used to create
the associated IPsec SAs after PANA authentication, and
draft-ietf-pana-ipsec-07.txt provides details (and differences when
present), what would be the appropriate language to capture what you are
saying above?

Thanks.

Alper

---

From: Mark Townsley <[email-masked]>
Date: Wed, 17 May 2006 09:52:26 +0200

> present), what would be the appropriate language to capture what you are
If you do allow both, then when someone advertises "I can do PANA" they 
have to qualify it with "IKEv1 or IKEv2?"

I think PANA is already challenged with multiple possible interfaces 
between the EP and PAA and the PAA and AS, now you will have the same 
between the PAC and EP. If each interface has multiple options, "PANA" 
won't mean much without a lot of qualifiers.

I still recommend at least one "MUST IMPLEMENT" for each interface, so 
that PANA will at work "out of the box" in at least one configuration no 
matter who your EP, PAA, AS, PAC, vendor is. Alternative protocols (or 
versions of protocols) can still be options if someone wants to improve 
on the base configuration or needs to provide backwards compatibility 
with some non-fully-compliant device.

- Mark

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 May 2006 11:01:46 +0300

>present), what would be the appropriate language to capture what you are
The basic question is that if my company wanted to implement
a PANA client, would it have to support IKEv1 or IKEv2 to be
interoperable with other people's PANA PAA/EPs?

Pana-ipsec-07 says that IKEv1 MUST be used. This is
fine from the interoperability perspective, because I
now know my company needs to do IKEv1.

But then we still have what David says above about IKEv2.
Unless there are strong technical or business reasons to
do otherwise, it would be good to reference the latest
specs. Given that ipsec-07 outlines the use of IKEv2 as well,
there does not seem to be a technical reason why IKEv2
would be inappropriate. But perhaps there are business
reasons, such as no one who wants to do PANA has
implemented IKEv2 yet. Are there? If yes, current text
is probably fine. If not, I would suggest pointing to IKEv2
and not IKEv1 in the first MUST of Section 6.0.

Hope this helps,

--Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 May 2006 22:49:43 +0300

Hi Mark,

I know we discussed this issue at length for the PAA-to-EP protocol choice.
As I said, I think the issue is not specific to PANA, it's bigger than that.
Even if we resolve it for PANA, I think the bigger issue is applicable to
many things we do at IETF.

For that, let me bring it up to the attention of IESG.

For various functionalities, we seem to have more than one alternative.
E.g.:

- RADIUS, Diameter
- IKEv1, IKEv2
- IPv4, IPv6,
- DHCP, PPP, stateless autoconfig (IP addresses configuration).
- etc. 

Let's take MIP6 as an example. 

For "protocol level interoperability", all we care is if both the "mobile
node" implementation and the "home agent" implementation are running RFC
3775. That level of interoperability is not affected by whether the
care-of-address is configured by DHCP or PPP or statelessly; or the node
running home agent is using RADIUS or Diameter with a AAA server, over IPv4
or IPv6. (IKE choice is not that cleanly separated from MIP6 protocol).

For "system level interoperability", all of the above becomes an issue. A
system is defined in terms of its role and the functionalities (a set of
protocols) it hosts. Only the system level interoperability can ensure a
system (box, node, et) using (or used for) MIP6 can interoperate with the
others. For example if we are talking about the "home agent system", that
means we need to decide which AAA protocol, IKE version, IP version running
on it.

I think we (as IETF) need to decide whether we'll write specifications only
for the former type, or both types of interoperability. Whatever the
decision is, we shall apply it across the board. If we need to make
exceptions, we shall decide on those as well.

Btw, "system level interoperability" is definitely in the scope of other
SDOs, such as 3GPP, 3GPP2, WiMAX, etc. They name "systems" such as a "base
station", "GGSR", "PDSN", etc; the set of mandatory "protocols" on each
system is documented; and one system from Vendor A is expected to
interoperate with another system from Vendor B.

Comments?

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, May 17, 2006 10:52 AM
> To: Alper Yegin
> Cc: 'Jari Arkko'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Gen-art] RE: [Pana] Re: GenART review of draft-ietf-pana-fra
> mework-06.txt
> 
> Alper Yegin wrote:

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 May 2006 13:02:35 +0200

Sam Hartman wrote:
>     Alper> I think we (as IETF) need to decide whether we'll write
>     Alper> specifications only for the former type, or both types of
>     Alper> interoperability. Whatever the decision is, we shall apply
>     Alper> it across the board. If we need to make exceptions, we
>     Alper> shall decide on those as well.
>
>
> I think we intend for the most part to write specifications that create some degree of system level interoperability.
>   
And I obviously agree on principle with Sam here. The big question boils 
down to where one draws the line between what is part of the system, and 
what is an external component to the system. The PANA WG defined several 
PANA nodes, as clearly described in its framework document. I think it 
is a reasonable goal to ask that at the very least the PANA-defined 
nodes themselves have one least common denominator in which all MUST 
work together. I don't think Sam and I are trying to be difficult for no 
reason, this is honestly to help encourage deployment of the PANA system 
as defined in the PANA WG.

If the system-level aspects of PANA are left up only to other SDOs to 
define, then perhaps the WG has simply tried to take on too much, and 
its scope and deliverables should have been pared down for its own sake. 
I believe I have been saying this for sometime, that PANA's biggest 
suffering has been its sheer bulk and grand expectations relative to the 
problem at hand.

- Mark

> I'm confused though why the MN cares what AAA protocol the MIP
> infrastructure is using.
>

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 May 2006 20:26:05 -0700

>     Alper> For "system level interoperability", all of the above
>     Alper> becomes an issue. A system is defined in terms of its role
>     Alper> and the functionalities (a set of protocols) it hosts. Only
>     Alper> the system level interoperability can ensure a system (box,
>     Alper> node, et) using (or used for) MIP6 can interoperate with
>     Alper> the others. For example if we are talking about the "home
>     Alper> agent system", that means we need to decide which AAA
>     Alper> protocol, IKE version, IP version running on it.
> 
> I think we intend for the most part to write specifications that create
> some degree of system level interoperability.
> 

MN does not care. HA (home agent) cares as it needs to interface with a AAA
server in order to authenticate/authorize the MN.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 May 2006 20:38:10 -0700

Hi Mark,

> what is an external component to the system. 

Even Sam's response suggests to me that we don't have a uniform approach to
this issue ("think/intend/most/some"). I am hoping we can get some clear
guidelines from the IESG, so that we know, for example when to mandate
RADIUS vs. Diameter, IKEv1 vs. IKEv2, IPv4 vs. IPv6, etc.

This issue is not specific to PANA as I gave an example from MIP6. I could
give few more from EAP and IKEv2. I'll respond to your other PANA-specific
comment in another thread (as I really want to see if there is a general
recommendation to system vs. protocol interoperability).

Alper

> The PANA WG defined several

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 May 2006 20:55:01 -0700

> work together. 

Only the PANA Client (PaC) and the PANA Authentication Agent (PAA) are the
new protocol elements. They reside on known nodes (such as end-hosts and the
NAS). The other elements, enforcement point (EP) and authentication server
(AS), are not our inventions. These are widely used in mobile and wireless
architectures.

PaC-to-PAA protocol is PANA. We ensure its interoperability.

PAA-to-AS protocol is RADIUS/Diameter.

PAA-to-EP protocols exist in various architectures today (R6 in WiMAX, Rp in
3GPP2, etc). But from the earlier days of the WG, we were asked by the AD
not to leave that part unspecified. Hence we designed PANA-SNMP. 

PaC-to-EP protocols exist too (802.11i 4-way handshake, 802.16 3-way
handshake, etc). We are just showing how IPsec can be used in PANA-IPsec
I-D.

In the PANA framework document, we are showing how all these pieces come
together. Something not too commonly done at IETF documents, imho. But this
document is not a system design document. It lacks whole lot of other
details needed to build exact nodes (the nodes that you can buy off the
shelf and expect it to interoperate in the field). Again, this level of
details is present in other SDOs' documents.

> I don't think Sam and I are trying to be difficult for no

I never thought differently. As I had shown with my earlier PANA-SNMP
agreement, we are going to follow whatever recommendations come from these
discussions. In general, I think there is some level of uncertainty and lack
of coordination on the level of interoperability we are aiming in IETF
documents. I thought this would be a good example to get this issue on the
table.

> suffering has been its sheer bulk and grand expectations relative to the

I hope my above classification of the interfaces and the relevant protocol
work clarifies the current picture.

Alper