Subject: [Pana] AD review resolutions

From: "Alper Yegin" <[email-masked]>
Date: Tue, 6 Mar 2007 15:20:13 +0200

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Mar 2007 10:51:40 -0500

On Tue, Mar 06, 2007 at 03:20:13PM +0200, Alper Yegin wrote:
(snip)
> Resolution: By looking at the IP address and port number. Make sure to

I thought the comment was only for PCI.  For other messages,
Session-Id and IP address of PAA would be sufficient to identify the
peers of the session, otherwise, PANA-Update with chaning PaC's IP
address would not work.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Wed, 07 Mar 2007 17:13:17 +0100

> peers of the session, otherwise, PANA-Update with chaning PaC's IP
I believe Alper indicated that the session ID alone could be used.

There is, of course, an assumption here that the destination IP address
has to be one that will cause the packet to arrive on the PAA. The
subtlety is whether or not the PANA code is supposed to use the IP
address as part of its session context lookup. I think not, but the text
above makes me wonder if we agree.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Mar 2007 19:07:17 +0200

Backtracking the details of the issue:

------------8<----------

> >    It is possible that both the PAA and the PaC initiate the handshake
> >    procedure at the same time, i.e., the PAA sends a PANA-Start-Request
> >    message while the PaC sends a PANA-Client-Initiation message.  To
> >    resolve the race condition, the PAA SHOULD silently discard the
> >    PANA-Client-Initiation message received from the PaC after it has
> >    sent a PANA-Start-Request message.
> >
> What do you use to identify that the messages came from a "known" PAA 
> or PaC? Source IP address? Something in the PANA payload? EAP payload? 
> You need to be specific.

It's the IP address and port number of the peer. We shall state that.

-------------->8------------

So, apparently we were talking about the PCI and PSR crossing each other.
And the question boils down to "How can the PAA know that the PCI was sent
from the same PaC that PAA sent an unsolicited PSR to?" 

For that case, we cannot rely on Session-ID, as the PCI does not have one. 

We have to rely on the IP address. Now that I'm thinking, UDP port does not
help either, as the source port of PCI is an ephemeral port, whereas the
destination port of the PSR is the PANA port. 

...

Aside from identifying the source of the PCI, PAA can always rely on the
PANA Session-ID to identify the PaC. And PaC can rely on the PANA Session-ID
and the PAA IP address to identify the PAA. The asymmetry between the two
end points is due to the fact that the session-ID is assigned by the PAA. In
case PaC is talking to two different PAAs (e.g., on two different
interfaces), coincidentally both PAAs could have assigned the same
Session-ID and therefore the PAA IP address is also needed for positive
identification. 

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2007 6:13 PM
> To: Yoshihiro Ohba
> Cc: Alper Yegin; [email-masked]
> Subject: Re: [Pana] AD review resolutions
> 
> Yoshihiro Ohba wrote: