Subject: [Pana] Message type reduction

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 14:42:32 +0200

After some offline brainstorming, here is an attempt for reducing message
types in the protocol.

State				Message Type	
-----				------------	
Authentication and 	PCI, PAR/PAN	
Authorization					

	Notes:
	- PSR/PSA removed. A "start" flag indicates beginning of
	  new EAP authentication.
	- Initial PAR/PAN optionally carries EAP, in order 
	  to accommodate stateless reachability testing.
	- PBR/PBA removed. A "complete" flag indicates end of EAP	
	  authentication, along with the inclusion of appropriate 
	  AVPs.

Access			PNR/PNA (PANA-Notification-Request/Answer)

	Notes:
	- Replaces PUR/PUA, PER/PEA, PPR/PPA, PRR/PRA
	- Need flags to indicate which purpose PNR serves. 
	  "update", "error", "ping", "reauth".

Termination			PTR/PTA

	Notes:
	- Same as before.

This approach reduces the message types from 9 to 4.

Does this make sense?

Let's make sure we are capturing all the details of this reduction as I
tried with the "Notes".

Alper

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Mar 2007 14:53:53 +0200

> State				Message Type	

I think we have been through this before, but I don't
recall the reason why EAP identity request carried in
the start message implies state on the EAP server side...

> 	  authentication, along with the inclusion of appropriate 

Ok (but you could you have left this, too).
> 	  "update", "error", "ping", "reauth".
I would get rid of the update functionality in addition.

> 	- Same as before.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Mar 2007 09:08:03 -0400

> the start message implies state on the EAP server side...

This mostly came from RFC 4137, but some other implementation that is
not based on RFC 4137 may be able to carry EAP identity request
without creating state on the EAP server side.  On the other hand, an
EAP authentication method message (e.g., EAP-TLS) can also be the
first request when EAP identity is omitted.

> I would get rid of the update functionality in addition.

I believe update functionality is important for some DSL deployment
which used IPv4 and want to assign a global address depending on 
the identity of the peer after authentication.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 15:31:28 +0200

> first request when EAP identity is omitted.

If the first PSR carries EAP, then a retransmission timer has to be
maintained. If the PSR is triggered by a PCI, then a single PCI fired at the
PAA generates state (timer management) in the PAA.

Alper

---

From: Mark Townsley <[email-masked]>
Date: Mon, 12 Mar 2007 15:51:34 +0100

> PAA generates state (timer management) in the PAA.
If EAP was being carried over an unreliable transport, I suppose this 
wouldn't be true.

Aside of that and thinking aloud...

Is the client obliged to retransmit the PCI if no PSR is received? If 
so, the PAA might have to cache the EAP message, but it wouldn't 
necessarily have to setup a timer. Instead, it could always wait for the 
PCI to be retransmitted before retransmitting on its own. I'm sure there 
are vast repercussions to your design here though.

Also, I'm not so sure that setting up a timer on a PAA is necessarily 
all that evil in terms of state. If you have a common managed timer 
library across a box that is handling a lot of timer events anyway 
(which for, say, a truly large scale BRAS or VPN concentrator would be a 
necessity), adding one node to the tree isn't all that big of a deal.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 19:46:53 +0200

> If EAP was being carried over an unreliable transport, I suppose this

It'd still be true. If the EAP lower layer is unreliable, that means the
EAP-layer timers are still in effect and we need to rely on the EAP
retransmissions (performed by the PAA itself again). Either way, an entity
(EAP or PANA) on the PAA needs to re-transmit the EAP message.

> Is the client obliged to retransmit the PCI if no PSR is received? 

Yes.

> If
> PCI to be retransmitted before retransmitting on its own. 

We shouldn't be saying "before retransmitting on its own" if we are talking
about disabling the retransmission.

If I understand you right, you are saying if the triggering message (PCI)
has its own retransmission timers, we can safely disable retransmission of
the triggered message (the very first EAP/PAR). If so, that's what we have
in the current spec.

Assuming EAP must be retransmitted (either by the EAP itself, or the
lower-layer) totally disabling retransmissions and relying on the external
trigger for a EAP-carrying message did not seem right. That's why not
carrying EAP in such a message looks right to me.

> I'm sure there

For each incoming PCI, retransmission state includes
- IP address of the trigger
- next retransmission time
- count left before exhausting maximum retransmission attempts 
- time left before exhausting maximum retransmission duration
- and any data structure overhead to maintain this info

Not that a single PCI can exhaust a whole lot of resource, but given the
one-way nature of this message, blasting PCIs with varying source addresses
can drain resources on a PAA.

I'm under the impression that we shall protect the protocol against threats
of this nature. Isn't that so?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Mar 2007 13:46:51 -0400

> are vast repercussions to your design here though.

Yes, for PaC-initiated authentication, we already have text to
discourage retransmission of the first request from PAA, and let PaC
to retransmit PCI:

"
   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.  
"

> necessity), adding one node to the tree isn't all that big of a deal.

I agree that retransmisson timer management is not a problem.
Avoiding creation of state on EAP server/authenticator before making
sure that PaC is reachable from PAA is the feature we are trying to
optionally support here.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Mar 2007 17:41:07 +0200

Yoshihiro,

> first request when EAP identity is omitted.

Ah, yes, its all coming back to me now. Because server/authenticator side
is responsible for retransmission, if the response to the first message
got lost... no one would be retransmitting.

Ok. But can we remove the optimization or make it mandatory?
> the identity of the peer after authentication.

Hmm. Ok. But lets think about this for a second. In that environment, will
there be merely a "port based" authentication once at the beginning of a
session
or also some per-packet payload crypto? Do you have a call flow for this?
At which point does DHCP get invoked for the 2nd time? And why does
PANA need to know the new address?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Mar 2007 17:41:07 +0200

Yoshihiro,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Mar 2007 17:41:13 +0200

Mark,
> If EAP was being carried over an unreliable transport, I suppose this
No, what Yoshihiro said earlier applies to the EAP layer.

Jari

.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id CE9BB19871E;
	Wed, 14 Mar 2007 17:41:10 +0200 (EET)
Date: Wed, 14 Mar 2007 17:41:13 +0200
From: Jari Arkko <[email-masked]>
To: Mark Townsley <[email-masked]>
Subject: Re: [Pana] Message type reduction
Cc: 'Yoshihiro Ohba' <[email-masked]>, [email-masked]

Mark,
> If EAP was being carried over an unreliable transport, I suppose this
No, what Yoshihiro said earlier applies to the EAP layer.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Mar 2007 11:59:43 -0400

Hi Jari,

> PANA need to know the new address?

It's "port based" authentication.  Please refer to Figure 5 of
draft-morand-pana-panaoverdsl-00.txt for a call flow.  

PAA needs to know the new address to keep PANA session for PANA-Ping
and PANA-re-auth (this is not catured in the call flow, though).

Yoshihiro Ohba

---

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

> Ok. But can we remove the optimization or make it mandatory?

The current proposal is this:

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

Given the call flow:

PaC	PAA
---------> PCI
<--------- PAR
---------> PAN

If the PAA wants to stay stateless when responding to PCI, it must send the
first PAR without any EAP payload. Otherwise, it must include EAP payload in
it.

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

Not all deployments are vulnerable to blind DoS attacks. For that, the
decision can be a configuration parameter on the PAA. And that saves the
deployments which are not subject to such attacks one extra round-trip. I
think one extra round-trip is worth saving.

Are you suggesting we always perform the first round of PAR/PAN without
carrying EAP?

Alper

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Mar 2007 20:58:51 +0200

> draft-morand-pana-panaoverdsl-00.txt for a call flow.  

What you show here does not appear to really depend on update,
however. (As you note below.)

> and PANA-re-auth (this is not catured in the call flow, though).

I re-read the relevant parts of pana-pana, but I did not find an explanation
of how the client address is used in in the identification of the client;
presumably Session Identifier would be sufficient for PANA-Ping.

For PANA re-auth, there's a problem, however, if the PAA happens
to initiate it. It needs to know where to send the message.

Is there a particular reason why source address change could not
simply be detected and silently recorded for every (successfully
processed) PANA message?

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Mar 2007 15:25:01 -0400

> presumably Session Identifier would be sufficient for PANA-Ping.

Without updating the address, the session identifier is associated
with the old IP address of the PaC, and it's not possible for PAA to
send PANA-Ping message to PaC.  

> to initiate it. It needs to know where to send the message.

Yes, PAA-initiated re-auth should not be a problem because the same
mechanism used for PAA-initiated initial auth should be usable here.

> simply be detected and silently recorded for every (successfully

Yes, that is possible.  For example, the PaC can send PANA-ping to PAA
immediately after acquisition of the new IP address so that the PAA
can update the binding.  If this kind of operation is described in the
panaoverdsl draft, I am ok with removing PANA-Update from pana-pana.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Thu, 15 Mar 2007 09:51:21 +0100

> simply be detected and silently recorded for every (successfully
Jari, you and I have now come up with this same suggestion
independently, which probably lends some credence to the idea. I argued
that it could potentially help in some NAT situations as well
(particularly if there is a periodic PANA-ping in place anyway).

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 19 Mar 2007 19:24:34 +0100

> Jari, you and I have now come up with this same suggestion

I was going to say that :-)

My response to Mark's suggestion was, this "implicit" semantics (of any
message updating the PaC IP address info on the PAA) may get in the way of
some future feature that relies on PAA state not changing despite the PANA
messages coming from different sources. 

For that reason, my preference is an explicit indication rather than a
side-effect of any messaging. Just a flag indicating the IP address shall
change, so that we can be sure no other message can unintentionally cause
such an effect.

I admit I really don't have a concrete "future feature" :-) in my mind. But
saving one bit now did not seem worth the risk. 

Alper