Minutes of:
Protocol for carrying Authentication for Network Access (pana)
At: IETF67
November 6, 2006 (San Diego, USA)
Chairs: Basavaraj Patil <[EMAIL PROTECTED]>
Alper Yegin <[EMAIL PROTECTED]>
Credit for these minutes:
1. Victor Fajardo (vfajardo at tari dot toshiba dot com)
2. Also Wassim Haddad (wassim dot haddad at ericsson dot com)
############################################
1. PANA Spec WG Document Status
- AD review completed
- SECDIR review completed
- Ready for WG last call
- Revisions required before WG last call
2. PANA Protocol Revision (Issues and Resolution)
Speaker: Yoshihiro Ohba
- AD review after IETF last call
- PANA is getting more simplified
Comments:
Alper : Waiting for external review on language tag usage in
Notification AVP
Mark : Still waiting for input - will lookup
- Issues discussion
#1 Session-Id
* Globally unique session id is not needed
* Use 4-octed session-id field in the PANA header, remove session-id
avp
* Session-id is asssinged by PAA in the PSR/PSA exchange
* Therefore, UNKNOWN_SESSION_ID error can be removed
#2 Stateless handshake
* Simplification of the stateless handshake - Removal of L-bit ?
- Need to keep a minimum state to be maintained (cookie, initial
seq)
- Adding PSR retransmission to this state is not a big issue
* Solution:
- Remove distinction between stateless and stateful
- Remove cookie avp
- Remove L-flag
- PSR re-transmission may be turned off if PAA wants to be stateless
#3 Device-Id
* Do we need Device-Id ? Is IP address enough ?
* Solution:
- Remove text for Device-Id determination in the spec,
maybe define this scheme in other documents
- Remove text from Section 2 of the spec
- Remove Device-Id AVP
#4 Bootstrapping Lower-layer
* Bootstrapping functionality thould be removed
* Solution:
- Remove PCAP AVP
#5 Post-PANA Address Configuration
* PPAC should be removed from spec
* List discussion:
- IP address configuration is orthogonal and out of scope
- Each address configuration has its own re-config notification
* Solution:
- Remove PPAC AVP
- Remove appendix A
#6 Network Selection
* Can be better defined in separate ID
- Use RADIUS operator ID in place of SMI vendor id (needs
discussion)
* Solution:
- Remove network selection functionality
- Remove related network selection AVPs
#7 Nonce AVP
* Sometimes contained ins PAR/PAN or PSR/PSA, simplify
* Solution:
- Remove Nonce from PSR/PSA
- Specify that Nonce is carried only in the first PAR/PAN exchange
#8 Filtering excpetion
* Needs text for describing that EP needs to pass certain
IP packets that are exchange prior to PANA operation (i.e. DHCP)
* Solution:
- Added new text breifly mentioning this requirement
Comments:
Alper : We need to discuss with AD to clarify the proposed text
Mark : Filtering discussion began with Device-Id discussion.
Why do you need it ?
Because this is filtering (blocking certain traffic)
If you don't have Device-Id how do you know which traffic
to block. So either the spec needs to define one mode of
operation when the Device-Id is one form OR it is say that
filtering outside the scope of the doc.
EP may be multiples-hop away and not in the path where it
is capable of blocking traffic.
Jari : Propse text where EP is several hops away. Details what
this traffic type is. Its one way of avoiding this question
Raj : If EP is a bridge, it makes sense to allow DHCP and other
traffic to pass. Need to have clarification of where the EP
is located.
Jari : The current text is only for hand waving or warning. It will
not be easy to get all scenarios documented.
Raj : Why not use IP level filtering
Mark : I'm happy with document as it is including IP filtering mode.
But it has to be clear where the EP should be. Its
un-realistic
to define how it works in every case.
Alper : Even if the spec wants to concern itself with other cases,
it is up to the EP to implement enforcement.
Jari : But readers of the spec needs to understand how this works. EP
enforcement is outside of the protocol but still part of the
system
Alper : How about putting the text in the framework document
Mark : Framework document is informational. Suggest we pick one mode
or scenario that can be described OR declare the topic as out
of scope
Alper : I prefer the second option
Glen : Its not impossible to specify the scenario regardless of the
location of the EP but it is impossible to specify the traffic
that passing through it.
Raj : The current text does not mean anything from implementation
point of view.
Jari : Yes. One approach is to say that specific applicaitons of
pana has to specify how that scenario happens, i.e. PANA-IPsec
document
Raj : Do we make this out of scope ? Or spec should say something
Jari : At least one doc should say something. If its not in the spec
then it becomes completely open to different interpretation.
Subir : I agree with glen. If EP is 15 hops way, it will not be
able to filter. Depending on the architecture then just say
which traffic will be blocked.
Alper : It does not matter whether it is authorized or not, that kind
of traffic will have to go through the EP.
Mark : With this text how do you know which is authorized client ?
I'm happy if the spec says at least one model, say IP. It
makes
more sense because we have something implementors can act on.
Subir : We need to say what kind of message your blocking
Jari : But its not enough.
Subir : How do you know which traffic from the client your passing ?
Jari : This depends on where the EP is. I would really like to see
implementable text that needs to be blocked, i.e. protocol
number, types, icmp ranges etc.
Alper : I agree but the discussion goes back to the spec. It's best
not to discuss this at all.
Jari : Leave text but needs to be specified in other architecture
Alper : How much details do we need in the spec ?
Jari : Only application should specify these cases
Alper : Definition of un-authorized client and the allowed traffic
type can be found in other spec, just add ref to the those
spec
#9 EAP message duplication handling
* Do we still need to specify eap message duplication ?
* Soultion: It should be removed
#10 IP source/dest address
#11 UDP port number
* Why not always use well-know port number for destination port ?
* Discussion
- Use of an ephemeral port number contained in a request
- Makes firewall traversal for PANA more difficult
* Soultion:
- Response is same rule
#12 AVP message allocation policy
* Missing spec on how to allocate mandatory supported avp or
new message
- IANA namepsce would be needed
* Discussion
- Mandatory-to-support AVP or new message would require new a
new version of PANA specification
* Solution:
- Add "Standard actions"
#13 PANA-error-requiest
* PER needs to contain info on on what caused an error
* Add new new Failed-Message-Header AVP
#14 Condition to terminate request re-transmission
* Request re-transmission is terminated when protected PER
for the request is recieved
#15 Other changes
* Result-code AVP changes
* Protocol error result changes
* Include number of experimental message type from 2 to 16
Comments:
Alper : Once we converge these soultions and send it
back to Mark
Mark : Make a short IETF last call after compilation
of these changes
3. DHCP options for PAA (Lionel)
Speaker: Lionel
- Report on DHCP options for PAA
- Defintion of new DHCP option to local PAA in access network
- Status
- WG last call on *-03 issued in IETF66
- Prallel work in DHC WG and PANA WG
- Work Completely done Sept 1, 2006
- Output:
- Draft passed WGLC on both DHC and PANA WG
- AD Review:
- Jari, Thomas, Bernard
- Results provided on 10/10
#1 Resolution of DHCP option in the PANA framework
- Used only to discover PAA address ?
- Dynamic mechanism to inform DHCP client that PANA MUST be used
Comments:
Jari : Some warning on security issues is needed when
trying to use this method
#2 Behavior of the DHCP nodes and Pac
- Add text to clarify that
* PAC should request DHCP PAA Option
* DHCP server should send a client with the PAA option
#3 Security considerations
- If PANA is used for turning pana on/off
* implications for spoofed PAA address ?
* Risk of bidding down attacks
- Answer: related to issue #1
- There is no specific security issue if it clearly
states that the option is used only to discover the PAA
- Add some text in the scurity seciton to explain
the issues
Comments:
Jari : I'm happy with all of these once all these text will appear
Alper : Where not using this text as a mechanisms
Jari : This is just a warning when discovered PAA address is found
Alper : It is equivalient to unprotected discovery mechanism
Jari : Similar issues with other scheme and this is enough
Next steps:
- Provide revisions based on discussion
- Move the draft forward to IETF last call
4. PANA in DSL networks
- New draft which describes use of PANA in DSL networks
- Once the PANA framework document was simplified, the
PANA use cases for DSL an WLAN was removed
- Done in version 07
- This draft is a spin off from the framework draft
- Focus on DSL networks migration from traditional
PPP access model to pure IP base access environment
Use case
- Evolution of DSL architecture
- Two steps ATM to Gig and PPP to IP based
- IP session model introduced in DSL forum
- Currently, there is no built-in authentcaion
mechanism
Why use PANA ?
- Security requiremetns required in DSL forum
Location of PAA and EP
- PPP base where BRAS is in charge of CPE network access
- In IP-Session based enviroment
- Functionality may be provided by the PAA and EP
in the BRAS
- It is possible to have PAA and BRAS to be not collocated
Localion of Pac
- CPE can be an L2 bridge and the Pac should be implemented
in the host
- CPE can be an IPv6 router then PAC should be in the CPE
and host
Comments:
Yoshi : In IPv6 case, is the IP address is a global address ?
Lionel : IP address should be visible from the BRAS, can
be global or local depending on topology
Other contents
- Consideration for IP address configuration
Comments:
Yoshi : For post PANA address notification are you relying on
the IPv4 DHCP notificaiton scheme. What about IPv6 ?
Lionel : For PPAC notification, rely on what is existing
Voytek : IP is discarded in IPv4 after Auth. How do you propose
protecting this scarce resource in the pre-PANA address ?
Lionel : We can rely on private IP address post PANA address
Voytek : Even using private IP can still exhaust the address space
Alper : If we rely on private IP, IP address exhaustion attack
should be dtectable and since it is a brute force
Mark : Security considration should say this
Voytek : Always use a DHCP server ? Or are there other methods
specially for embedded devices ?
Mark : Are these address configuration assumptions need
to be documented ?
Alper : Who's assuming that DHCP server is external ?
Lionel : From the DSL forum, it should be external
Alper : Is the DHCP server on the BRAS
Mark : Is there an attack here where we can deplete the IP addresses
?
The class of DHCP server existing on the BRAS is not as
feature
filled.
Next steps:
- Collect inputs from the group
- What level of detail sufficient ?
- Should the draft be a WG document ?
5. PANA API draft
Comments:
Raj : Should this be a working group draft ?
API documents are not necessarily WG docs
Mark : Its not within the working group theme
Raj : Other groups have published APIs such as MIPv6
Recommend that the work be progressed. Chairs to find the opinion of
the WG via the ML.
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
