Protocol for carrying Authentication for Network Access (PANA) IETF 71 Meeting Minutes Wednesday, March 12, 2008 1510-1610 Afternoon Session II ======================================================== Note takers: Domagoj Premec, Shubranshu Singh Opening presentation by Alper --------------------------------------- Agenda approved without modificationws overview of document status: drft-ietf-pana-pana-18: in RFC editors que pana-framewrok: in RFC editors que pana-statemacine: ready for WGLC pana-ipsec: revision pending before IESG submission, editor needed pana-pre-auth: revised version available, in progress draft-pana-mib: Victor volunteered to work on this document RFC editor issue: There is a circular dependency between dhc-pana and pana-pana. But this is not a problem. But the text in the base pana-pana specification implies dependeny on the pana framework document, and pana-framework is not ready yet. RFC editors are now seeking for a guidance how to solve that. One option how to solve it is to remove the offending sentence from the base pana-pana spec. Chair asked if there would be any objection to removing the offending sentence? Lionel comments it may be better not to remove the sentence, but to downgrade to reference to the pana-framework document to informational. No other comments. This proposal will be verifed on the mailing list. Presentation: Pana in DSL networks presented by Lionel Morand ---------------------------------------------------------------------------------- Frank (Huawei): you are showing two possible solutions. EP on the BRAS and EP on the DSLAM. Are both of them applicable to DSL? The answer is in the call flows, will be explained later. Frank (Huawei): question related to step 5 in the call flow, which protocol is used there? Lionel will explain it later as there is a more detailed slide. Frank (Huawei): How to link DHCP_ACK message with PANA session ID in the DSLAM (EP). Alper responded that DHCP_ACK contains the MAC address and IP address, and that the MAC address is the glue and is used by DSLAM just to keep track. DHCP_ACK is a sign of successfull authentication. Wojchiech (Cisco): How does the DSLAM know before PANA authentication which packets the DSLAM should allow? There is a default filter which allows only PANA and DHCP. It may also enforce the link-local addresses only. Bill (Juniper): For how long is the hole on the DSLAM opened? That is, how is that hole removed when the PANA session is expired? PAA can send the PANA-termination message which contains MAC address. Or there could be a timer in the DSLAM (like DHCP lease time) after which it closes the port. Wojchiech (Cisco): How does the DHCP client know to send the DHCP discover? First there is DHCP_Inform, then PANA authentication, then the DHCP client sends DHCP discover to get an address? How is the DHCP client trigger. PANA client on the device will trigger the DHCP client. Steps 2 and 3 are just for discovering the PANA auth. agent. This scenario specifically relies on the DHCP. If this is not the case (if the hosts has a static IP), then this is a different call flow. Wojchiech pointed out that the presented solution requires integration of the DHCP client with PANA. Bill (Juniper): how is the port opened for static IP address assignment if the draft relies on the DHCP snooping. Response: there are different options. The draft is not completely finished yet, right now it describes only the case when DHCP is used for address configuration. If there is a need for an interface between BRAS and DSLAM, this will be handled elsewhere (somebody mentioned DSL Forum and ANCP WG) Presentation: PANA discusssion in DSL forum by Yoshihiro --------------------------------------------------------------------------- There was a DSL Forum meeting last week and Yoshihiro provided a summary presentation of a PANA related discussion. Lionel: Why is DSL forum not satisfied with the proposed solution that uses link-local addresses? The answer is that for this the DSLAM should be changed. Frank comments that BRAS uses the IP address to identify the host, and this is the limitation when the link-local addresses are used. Franks assumes that link-local addresses will collide. Proxy DAD on the BRAS side can be used to prevent collisions. Wojchiech comments that DSLAM vendors in the meeting last week were not willing to change their DSLAMs to snoop (or allow for) PANA. session adjurned Thursday, March 13, 2008 1510-1610 Afternoon Session II ======================================================= Note takers: Yoshihiro Ohba, Jean-Michel Combes IETF71 PANA meeting - II tentavie minutes Simplified PANA, Frank Xia -------------------------- Two problems: (i) unspecified IP address is excluded. (ii) Only support EAP authentication. Jari: I don't buy CHAP at all. DSL perspective, EAP-only solution is viable. Why CHAP is needed? Previous IETF meeting, CHAP is used only in dead standard bodies. I think it is just making a shopping list and it does not make much sense to me. We can run CHAP over EAP. But use of EAP-MD5 over AAA instead of CHAP will require changes to existing AAA infrastucture. Yoshi: Why AAA deployement needs to be changed if chap is carried in EAP? The PAA can terminate EAP-MD5 and carry the chap into exiting AAA container. Frank: That is true. Jari: Unspecified IP address is a mistake, use link-local address instead. Unspecified address does not support fragmentation. Frank: There are discussions in DSL forum meeting, and they think unspecified IP address is closest approach for DSL. It does not require IP reconfiguration for which DSL folks have been indicated issues. Jari: IP reconfiguration is not a problem because any solution requires changes to both end-points is not a problam. Changing the DSLAM is the problem. I don't buy an argument that router has to be changed. In any case, point-point link, some kind of port or IP adreess based transaction tracking has to be going on, until client has an IP session address. Frank: There is no dynamic authorization integrated with authentication. These two need to be atomic. Use of link-local IP address does not make the two atomic. Jari: Do you have some paper that describes the difficulty with using link-local address? Alper: In the previous IETF discussion, it is clear that DSL forum requires authentication before IP address configuration happens. Jari: Not necessarily. IETF takes other SDO's statement, but we can always ask clarification on or correct the statement. I would like to actual technical problems why link-local cannot do the work. Only question is packet needs to go through DSLAM before authentication. Router has to know who is being authenticated. We can use several identifiers for that purpose. Frank: Provide transitions. If we can make PANA deployed industry, it would be good other than not being used at all by anyone. Jari: The solution seems to imply some level of pain somewhere. This room is assuming there is more pain with link-local address. We are not at the point to determine to go with unspecified address. We know pains with unspecified address through DHCP-EAP discussion. What implies to routers and DSLAMs and other components need to be investigated. Alper: Exercise is to evaluate the pain, and do apple to apple comparison. My perception of this approach is doing the study of impact. Lionel: DSLAM part. It is not said that it is not possible to modify DSLAM. Both DHCP-auth and PANA will have some impact on the existing architecture. Alper: We need to look at the impact of unspecified address. Jari: We need to look at the impact of both unspecified address and link-local address. Unless it is done, we can't make a decision to accept unspecified address. Lionel: The panadsl draft will contain the impact of link-local address. Simple PANA PAA Discovery Protocol, Victor Fajardo -------------------------------------------------- Purpose is to provide a simple way of dynamically discoverying PAA IP address. The solution is based on link-local multicast. Lionel: The document describes how to use this mechanism, but some description on other discovery mechanism should be mentioned as well. Assessment of existing and potential work items, Chairs ------------------------------------------------------- Active: pana-sm, pana-preauth. No comment. IESG processing: pana-ipsec Jean Michael: If there is a need, I can work on it. Mark: You should be probably focusing on other important issue. I would suggest to remove it. Lionel: If people are working on it who are not here, then it may not be good to remove it. Jari: We can feel that it may be needed, but it's not very high-priority. Lionel: If physical layer is security is not enough, a solution like that is needed. Jean Michael: It might help pre-authentication security. Jari: It might be. Marc: What was the comment during secdir review? Alper: There was a manageable feedback. Marc: Are there enough people to review the document? 6 people raised to review the pana-ipsec. Expired draft: - pana-aaa. Avi: I am interested to work on it, but is it needed? Lionel: We can work on this. Alper: WG members including chairs were sucked into other discussion related to PANA these days. But It does not mean these documents were not needed. Avi: Why context transfer is needed for PANA? Jari: Pre-authentication has to be done. Maybe the borderline in the list is pana-ipsec. I recommend everything below pana-ipsec be removed. MIB Marc: MIB is always needed for completing protocol work. But I would not necessarily kick off MIB work. New I-Ds. Jari: "no" to all of them except for panaoverdsl, and pana-simplified for unspecified IP address. I am not sure about pana-pemk. Mark: In general, these drafts require rechartering. Next steps, Chairs ------------------ Alper: We will continue the discussion on the ML.