Subject: [Pana] IETF72: PANA WG meeting minutes

From: Basavaraj Patil <[email-masked]>
Date: Sun, 07 Sep 2008 22:58:13 -0500

Minutes of:
Protocol for carrying Authentication for Network Access (pana)
At: IETF72 (Dublin)
MONDAY, July 28, 2008 from 0900-1130

Chairs: Basavaraj Patil <[email-masked]>
    Alper Yegin <[email-masked])

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
[email-masked]
https://www.ietf.org/mailman/listinfo/pana