[Pana] AD review resolutions

["Alper Yegin" <alper.yegin at yegin.org>]

Please see below for a compilation of AD review comments and their
resolutions. Additions and corrections welcome. 

As some of the resolutions were not spelled out on the list, they are more
of my own reading of the threads. Mark and others, please let us know if we
are all on the same page.






[1] Rate limiting requires refinement.


Resolution: Provide stronger requirement on rate limiting of PCI processing.
Issue explicit warning about the interaction between possible rate limiting
and use of Pings for dead-peer detection. 


	The PAA SHOULD limit the rate it processes incoming PANA-Client-
	Initiation messages in order not to subject itself to denial-of 
	service attacks. Details of rate limiting are outside the scope of 
	this specification.

	...

	It should be noted that if a PAA or PaC which considers its 
	connectivity lost after a relatively small number of unresponsive 
	pings is coupled with a peer that is aggressively rate-limiting
	the PANA-Ping messages, false-positives could result. Care should be

	taken when rate-limiting PANA-Ping messages to periodically respond,
	and a PAA or PaC should not rely on PANA-Ping messages to quickly 
	determine loss of connectivity.

	...

	Unless dropped due to rate limiting, the PaC and PAA MUST process
all
	duplicate request messages received.



[2] Do we need a reliable transport for EAP?

PANA must have a reliable transport option for some set of messages, but not
for carrying EAP.

EAP can be carried over reliable transports by setting the EAP
retransmissions to infinity (e.g., IKEv2).

Supporting both reliable and unreliable message delivery in PANA increases
complexity.

Resolution: Keep the design as-is.


[3] Can we reduce message types?

[3.a] Do we need to have distinct phases in PANA, or can it simply just
carry EAP?

Resolution: Just like any other "EAP lower layer" (e.g., IEEE 802.1X, IEEE
802.16e PKMv2), PANA has a state machine and the associated states/phases.


[3.b] Can we eliminate PANA error messages?

We could eliminate standalone the error messages and instead use error AVPs
in the responses to an erroneous requests, and drop erroneous responses
silently.

Resolution: Keep the error messages as they are useful for debugging.

[3.c] Can we eliminate PCI?

Resolution: No, as this is the only way PaC can trigger PANA.

[3.d] Can we eliminate PUR?

We could rely on "any" PANA message updating the PaC address info on the
PAA.

Resolution: Implicit signaling may have undesirable side effects. An
explicit PUR message is better.

[3.e] Shall we push the message type off the PANA header?

Resolution: Not worth it.


[4] Explicitly clarify that anything optional in the spec is "optional to
use", not "optional to implement."

[5] Can we separate Ping messages from others in terms of squencing and
retransmissions, so that they don't block progress?

Resolution: Consider doing that if we end up redesigning the transport.

[6] How do the peers identify each other?

Resolution: By looking at the IP address and port number. Make sure to
document that.

[7] Do we need to send an error message when the EAP authentication fails at
a pass-through authenticator without sending an EAP Failure message
[RFC4137]?

Resolution: Do not send an error message and simply rely on the timeouts on
the Pac.

[8] Should we remove piggybacking EAP on the PSR?

Resolution: Keep it.




_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana