[Pana] IETF72: PANA WG meeting minutes
Basavaraj Patil <basavaraj.patil@nokia.com> Mon, 08 September 2008 04:19 UTC
Return-Path: <pana-bounces@ietf.org>
X-Original-To: pana-archive@megatron.ietf.org
Delivered-To: ietfarch-pana-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BF83A6943; Sun, 7 Sep 2008 21:19:57 -0700 (PDT)
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894EB3A6943 for <pana@core3.amsl.com>; Sun, 7 Sep 2008 21:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.647
X-Spam-Level:
X-Spam-Status: No, score=-4.647 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ0x73QWYgLM for <pana@core3.amsl.com>; Sun, 7 Sep 2008 21:19:55 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AE9393A67BD for <pana@ietf.org>; Sun, 7 Sep 2008 21:19:53 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m884Jhhv021571 for <pana@ietf.org>; Sun, 7 Sep 2008 23:19:55 -0500
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 07:19:53 +0300
Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Sep 2008 23:19:51 -0500
Received: from 10.241.58.208 ([10.241.58.208]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Sep 2008 04:19:46 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Sun, 07 Sep 2008 22:58:13 -0500
From: Basavaraj Patil <basavaraj.patil@nokia.com>
To: pana@ietf.org
Message-ID: <C4EA0D05.18A81%basavaraj.patil@nokia.com>
Thread-Topic: IETF72: PANA WG meeting minutes
Thread-Index: AckRZx1wSxmfYCOhsU2MlcKLAdNFVw==
Mime-version: 1.0
X-OriginalArrivalTime: 08 Sep 2008 04:19:51.0821 (UTC) FILETIME=[239913D0:01C9116A]
X-Nokia-AV: Clean
Subject: [Pana] IETF72: PANA WG meeting minutes
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pana-bounces@ietf.org
Errors-To: pana-bounces@ietf.org
Minutes of:
Protocol for carrying Authentication for Network Access (pana)
At: IETF72 (Dublin)
MONDAY, July 28, 2008 from 0900-1130
Chairs: Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper.yegin@yegin.org)
Credit for these minutes:
1. Christian Bauer (Christian.Bauer at dlr.de)
2. Mohana Jeyatharan (Mohana.Jeyatharan at sg.panasonic.com)
==============================================================
WG Status, Agenda
- Pana base protocol published after 1 year's of WG last call and revisions.
- Pana framework published as information RFC.
- Several WG documents expired and will not be revised and few will be
chosen in the re-chartering of this WG.
I-D: Application of pana framework to DSL networks
Presenter: Lionel Morand
* Intention is to how to implement pana protocol over DSL networks
Moving from PPP to IP networks and thus some IP address is required
especially for multihop networks.
* Changes from from version 1 to version 2
using unspecified IP address in DSL networks.
* Proposal is to use unspecified IPv4 address before authentication.(IPv4)
Jari: I remember there was criticism related to the usage of
unspecified IP address (from Thomas Narten)
Alper: Yes, but at that time there was no strong justification for
unspecified address. There are problems, as many things don't work
(multi-hop, SAs)
Jari: Just as a reminder: slides do not completely represent the
discussion as it was.
Lionel: Idea was to authenticate user before aquiring an IP address ->
so we have a requirement.
Specification was not clear enough on the usage of unspecified
address. Now there should be enough justification.
Jari: This updates the base PANA protocol?
Alper: I-D describes how it can be implemented, without changing base-spec.
Jari: Nothing here should be in conflict with protocol spec.
Alper: There are no keywords, is is not normative.
Jari: If you change the code, you also change the PANA protocol.
Alper: Disagree. We have some liberty here.
Jari: We need furhter discussion. We should have the same
understanding when reading/having read the protocol.
Richard - Question 1: How does AAA server get port?
Alper: That's the option 82 question.
Jari: I guess DSLAM inserts some information.
Lionel: We only use DHCP to retrieve PAA address. Any information will
be received by option 82.
Alper: This problem and how to deal with it is described in the draft.
Jari: PANA client does not know port number.
Alper: For deployments that need port, we add another DHCP req-rsp
signalling just for discovering PAA. Then DSLAM inserts option 82.
Richard - Questions 2: How do you trigger dhcp discovery?
Lionel:
Basvaraj: Host is required to configure an address anyway. And the
authentication is required before that.
[so trigger is implicit]
Chairs Conclusions:
DHCP and MIPv4 already uses unspecified IP address. It is fine for
MIPv64and DHCPv4 and we beleive it will be fine for Pana.
Jari: What are the next steps?
Chairs/Lionel: That will be discussed later.
+++++++++++++++++++++++++++++++++++++
Rechartering of WG and relevant I-Ds
Presenter: Chairs
Primary objectives has been achieved.
- Proposal to take Pana working group in maintenance mode. Review
current drafts and consider the essential ones. Going into maintenance
mode and if there is a concrete cause and then the documents will be
reviewd based on the context of the working group.
Critical ones are:
*state machine document. part of the base protocol.useful for
implementation.
*Pana enabling IPsec based access control. should be considered as a
standards track.
*draft-ietf-aaa-interworking document will be dropped
*context transfer protocol for pana. the relevance is very low. This
should be consdiered in mipshop.
*pana MIB. This document is relevant and this is needed for
completeness. Victor can take over this document.
*master key between pana client and enforcement point. relevance is
high. already expired.
*network selection support should be dropped.
*pre-aunthentication support PANA. This is very useful and this will
be part of the revised charter and milestones.
Open questions from participants:
The pana applicability to DSL networks.
DSL is not too interested in PANA in DSL forum. Basavaraj says no harm
in looking at this. In a years time will try to close this working group.
Lionel is inetersted in taking up the pana enbaling IPsec base access
control.
Jari's take in the final conclusion
Alper: Use of unspecified IP address is also used in DHCPv4 and MIPv4,
because they do not care within their context.
We have a justification within PANA to deviate from standard IP
design. We loose features of IP, but we think thats fine for PANA.
Richard: Is there a clear interest from DSL forum?
Basvaraj: There is nothing formal. They have not said "we dont want to
use PANA".
Jari: I have no extra information. But I think they are interested.
Alper: Their statement is: "there are two different solutions, but we
have not yet decided on one."
Basvaraj: There is interest from people to work on it. Let's see what
impact it makes.
Lionel: We should complete the work for "IPsec based Access
Control". IMO we need it.
Jari: "Pre-authentication support" I-D expired, but relevance
high. There is a problem here. Lets complete the four documents, and
let it up to DSL forum if they use it.
Basvaraj: We will send you a revised charter.
Jari: I could also do AD sponsoring of documents if necessary. But
lets not commit to it now.
State machine, MIB, theoratical appliation of pana to DSL
optimization such as pre-authentication. No point working on expired
documents.
AD sponsoring the optimization documents.
Next steps, revise the charter.
Jari: Documents needs to be completed and then working group will be
suspended.
--
Chairs: Next Steps
Basvaraj: We go into maintenance mode.
Jari: Ok. Its more sleep mode though. I am inclined to terminate WG
ASAP. When PANA is applied somewhere, we need new WGs.
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
- [Pana] IETF72: PANA WG meeting minutes Basavaraj Patil