Subject: [pcp] Loosely/tightly coupled auth/authz

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Oct 2012 10:02:37 +0300

Before I enter an in-depth discussion, let me say whether we decide to do it one way or the other does not have any impact on the PANA vs. EAP-o-PCP discussion.
PANA can support both.

Having said that, PCP WG still needs to decide which way to go, so let's discuss that below.

Margaret, the reason it took us so long to understand what you are trying to do is because of the terminology.
Your PPTs are referring to authentication and authorization. Not sure if you are aware but authentication of what and authorization of what are extremely important at this level of discussion. Let's be very specific.

EAP (in conjunction with its EAP lower layer) authenticates the identity of the end-point ("joe@domain", or more specifically "a device used by joe@domain")
Along with that there is an authorization of the requested service (PCP in this case). The final response from the AAA server to the NAS (PCP server in this case) not only says "yes, this is joe", but also says "joe is allowed to use PCP service"). In fact, it may not even say "yes, this is joe". That info may not matter to the NAS. And its disclosure to the NAS may even be prohibited due to privacy concerns. AAA server tells NAS "yes, this fellow is allowed to use PCP service".

This is what centralized authentication and authorization servers, AAA servers, do.
At that level, in a sense, authentication and authorization is coupled. 

Along with that authorization comes in a session lifetime, telling the NAS for who long this authorized service is good for.
AAA is saying "this fellow is allowed to use PCP service for 1 hour." It can say further things too: stop the service after 1 hour, or re-auth before the end-of 1 hour, etc.

This is how the current EAP and AAA-based architectures work.

Now, people said they'd like the PCP server (the NAS) set the session lifetime.
NAS can reduce the lifetime it received from the AAA server, but extending the lifetime w/o AAA server's involvement would be a problem. Because, the "centralized" authority sets the upper limit. This is the whole reason of using a centralized AAA server. Second A is for Authorization.

You sound like you want to use AAA server for Authentication, but not for Authorization. If this is what you want to do, please tell us why you want to do it that way. This is unusual.

Secondly, putting aside where the "PCP authorization lifetime" comes from, you folks want to decouple EAP session lifetime with the PCP lifetime.

What's the benefit of this de-coupling?

Why would you want to toss away your EAP session when the PCP state is still up? Tossing away would force you to re-run EAP from scratch if the client needs to process any other PCP packet meanwhile. Unnecessary overhead.

At the end of the day, here are the three lifetimes we could be talking about:

1- Authorized service lifetime AAA tells the NAS (PCP server).
2- Effective lifetime set on the state created for the authorized service. (mapping lifetime)
3- EAP session lifetime (MSK and its children's lifetime)

In current EAP and AAA practice, these are all the same values. 
If you want to deviate from that, we need to understand why. Because that deviation is going to complicate a simple system.

Alper

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Oct 2012 09:15:10 -0400

Le 18 octobre 2012, Alper Yegin a écrit :
> Before I enter an in-depth discussion, let me say whether we decide to do it
> one way or the other does not have any impact on the PANA vs. EAP-o-PCP
> discussion. PANA can support both.
> 
> Margaret, the reason it took us so long to understand what you are trying to
> do is because of the terminology. Your PPTs are referring to authentication
> and authorization. Not sure if you are aware but authentication of what and
> authorization of what are extremely important at this level of discussion.
> Let's be very specific.
> 
> 
> EAP (in conjunction with its EAP lower layer) authenticates the identity of
> the end-point ("joe@domain", or more specifically "a device used by
> joe@domain") Along with that there is an authorization of the requested
> service (PCP in this case). The final response from the AAA server to the
> NAS (PCP server in this case) not only says "yes, this is joe", but also
> says "joe is allowed to use PCP service"). In fact, it may not even say
> "yes, this is joe". That info may not matter to the NAS. And its disclosure
> to the NAS may even be prohibited due to privacy concerns. AAA server tells
> NAS "yes, this fellow is allowed to use PCP service".
> 
> This is what centralized authentication and authorization servers, AAA
> servers, do. At that level, in a sense, authentication and authorization is
> coupled.
> 
> Along with that authorization comes in a session lifetime, telling the NAS
> for who long this authorized service is good for. AAA is saying "this
> fellow is allowed to use PCP service for 1 hour." It can say further things
> too: stop the service after 1 hour, or re-auth before the end-of 1 hour,
> etc.
> 

I'm following you up to here.

> Now, people said they'd like the PCP server (the NAS) set the session

I don't think anyone said that. Auth lifetime is different from mapping 
lifetime. The AAA server is responsible for auth lifetime. The NAT is 
responsible for the mapping lifetime.

> NAS can reduce the lifetime it received from the AAA server, but
> extending the lifetime w/o AAA server's involvement would be a problem.
> Because, the "centralized" authority sets the upper limit. This is the
> whole reason of using a centralized AAA server. Second A is for
> Authorization.
> 
> 
> You sound like you want to use AAA server for Authentication, but not for
> Authorization. If this is what you want to do, please tell us why you want
> to do it that way. This is unusual.
> 
> 
> Secondly, putting aside where the "PCP authorization lifetime" comes from,
> you folks want to decouple EAP session lifetime with the PCP lifetime.
> 

Because PCP is just one way to manipulate NAT mappings. Others include:
- ordinary traffic using the mapping
- NAT administration interface
- other mapping control protocols that may be enabled simultaneously with PCP

> Why would you want to toss away your EAP session when the PCP state is still
> up?

There is no such "PCP state". There is only NAT state, which is independent 
from PCP.

> Tossing away would force you to re-run EAP from scratch if the client
> needs to process any other PCP packet meanwhile. Unnecessary overhead.
> 
> 
> 2- Effective lifetime set on the state created for the authorized service.
> (mapping lifetime) 3- EAP session lifetime (MSK and its children's
> lifetime)
> 
> 
> If you want to deviate from that, we need to understand why. Because that
> deviation is going to complicate a simple system.

IMHO it is technically impossible not to decouple mapping lifetime from the 
rest. Because that's how NAT works today, and you can't change that.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alper Yegin <[email-masked]>
Date: Wed, 24 Oct 2012 14:41:36 +0300

Simon,

Please see below.

> responsible for the mapping lifetime.

When the AAA server authenticates and authorizes "joe@domain", it's basically telling the following to the NAS (the PCP server):
- This fellow is authorized to use PCP with you,
- Next time he wants to send a PCP request to you, you can authenticate and authorize him by using the following session credentials (MSK, or an MSK child key + an id [session id]). You don't have to come back and ask me to authenticate and authorize.
- This session credential is good for duration of X. (this is the authorized lifetime of joe to be using PCP with the PCP server). After X has passed, throw the session credential away, it's useless. 
- Feel free to come back to me to re-auth and re-authorize anytime before X has passed. You'll get a new session credential, and a new lifetime.

Now, a mapping created by Joe using PCP can have a lifetime of Y.

It makes a lot of sense that X == Y.

It can also be that Y < X. PCP server can have a reason to require that.

And there may be cases where Y > X. 
We need to be talking about where this makes sense.
For example, in firewall configuration by an admin, this makse sense.
For a mobile subscriber accessing wireless network whose apps are creating NAP mappings, this does not make sense. Network resources are tightly controlled, and the PCP clients come and go.

> - other mapping control protocols that may be enabled simultaneously with PCP

Please see above. We  can talk about different uses of PCP and how it may impact the relationship between X and Y.

Let me expand on this:

> There is PCP state that we now have due to PCP SA (Security Association),
> And there is the network state created by PCP signaling (which can be NAT or firewall state).

Depending on the scenario,the two may be tightly coupled, or loosely coupled.

> rest. Because that's how NAT works today, and you can't change that.

We are going beyond today's NAT operation with the introduction of "authenticated signaling setting up and maintaining NAT tables". 

I think you are referring to the following in your above concern:
- PCP creates the NAT mapping
- Application traffic maintains the mapping
- So, even after PCP SA is expired, we cannot remove the mapping because now the mapping is in use and maintained by the app traffic.

Is that it, or something else? I'd appreciate if you can elaborate.

Alper

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Oct 2012 09:21:40 -0400

> It makes a lot of sense that X == Y.

In my previous email I tried to explain why X == Y does not make sense 
to me.

> For a mobile subscriber accessing wireless network whose apps are creating NAP mappings, this does not make sense. Network resources are tightly controlled, and the PCP clients come and go.

I would expect Y to have no link whatsoever with X, and would advise to 
design an auth protocol that has absolutely no expectation on Y.

> Please see above.

I'm sorry but I fail to see how your reply above addresses what I wrote.

> We  can talk about different uses of PCP and how it may impact the relationship between X and Y.

Why would there be any relationship at all? There can't be, because PCP 
is just one way to manipulate NAT mappings.

>> And there is the network state created by PCP signaling (which can be NAT or firewall state).

Right, this is a good precision. With this precision, my point is to be 
understood as meaning that the network state, in the NAT/firewall, has 
no PCP-specific component.

> Depending on the scenario,the two may be tightly coupled, or loosely coupled.

I'll reiterate my current position: so far it seems clear to me that we 
need loosely coupled, and I have seen no use case for tightly coupled.

> We are going beyond today's NAT operation with the introduction of "authenticated signaling setting up and maintaining NAT tables".

I'm not sure what you mean exactly by this, but I'm afraid that changing 
current NAT practice is going to be an uphill battle.

> Is that it, or something else? I'd appreciate if you can elaborate.

That's one use case for loosely-coupled. Others I've hinted at:

- Protocols other than PCP can be used to manipulate mappings. Even 
more: multiple protocols can be used to manipulate a single mapping.

- A NAT administrator may want to change mapping lifetimes. An 
administration script (cron job) could want to do this.

- NATs have complex behaviours and may decide to change a mapping's 
lifetime because of arbitrary traffic patterns, because of load 
conditions, because of the time of day, because of the weather, or just 
because it feels like it.

My point is basically that the NAT is authoritative for a mapping's 
lifetime. Practically, this authority can not be moved to a AAA server.

Simon

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 26 Oct 2012 08:45:58 +0000

Hi, Alper: 

I am a little confused about the following discussion. Do you imply that the loosely coupled auth/authz solution cannot support the cases where X==Y and X<Y? ^_^

> When the AAA server authenticates and authorizes "joe@domain", it's
> basically telling the following to the NAS (the PCP server):
> - Next time he wants to send a PCP request to you, you can authenticate and
> authorize him by using the following session credentials (MSK, or an MSK child
> key + an id [session id]). You don't have to come back and ask me to
> authenticate and authorize.
> - This session credential is good for duration of X. (this is the authorized lifetime
> of joe to be using PCP with the PCP server). After X has passed, throw the
> session credential away, it's useless.
> - Feel free to come back to me to re-auth and re-authorize anytime before X has
> passed. You'll get a new session credential, and a new lifetime.
> 
> 
> For a mobile subscriber accessing wireless network whose apps are creating
> NAP mappings, this does not make sense. Network resources are tightly
> controlled, and the PCP clients come and go.
>

---

From: Alper Yegin <[email-masked]>
Date: Sun, 28 Oct 2012 23:10:06 +0200

> - Protocols other than PCP can be used to manipulate mappings. Even more: multiple protocols can be used to manipulate a single mapping.
> 
> - A NAT administrator may want to change mapping lifetimes. An administration script (cron job) could want to do this.
> 
> - NATs have complex behaviours and may decide to change a mapping's lifetime because of arbitrary traffic patterns, because of load conditions, because of the time of day, because of the weather, or just because it feels like it.
> 

This is summarizing the issue.
Multiple factors can affect the lifetime of a mapping that was originally created by the PCP signal.
I understand that.

> My point is basically that the NAT is authoritative for a mapping's lifetime. Practically, this authority can not be moved to a AAA server.

This is where I fail to understand. What I'm saying is, there may exist at least one scenario where the mapping lifetime is centrally controlled by the AAA.
You seem to be saying this is impossible, there's no such a case.

Btw, when the PCP signal creates state on the PCP server, what value of lifetime is assigned to that state? I think you'd say the PCP server decides on its own.
A general PCP question: Should the PCP server indicate the associated lifetime to the PCP client at the time of state creation via PCP?
And if so, should the PCP server notify the PCP client when the lifetime changes (due to some of those external factors you listed above)?
Without this knowledge, the PCP client cannot properly "maintain" the state on the PCP server.

Alper

On Oct 24, 2012, at 4:21 PM, Simon Perreault wrote:

> In my previous email I tried to explain why X == Y does not make sense to me.
> 
> I would expect Y to have no link whatsoever with X, and would advise to design an auth protocol that has absolutely no expectation on Y.
> 
> Why would there be any relationship at all? There can't be, because PCP is just one way to manipulate NAT mappings.
> 
> Right, this is a good precision. With this precision, my point is to be understood as meaning that the network state, in the NAT/firewall, has no PCP-specific component.
> 
> I'll reiterate my current position: so far it seems clear to me that we need loosely coupled, and I have seen no use case for tightly coupled.
> 
> I'm not sure what you mean exactly by this, but I'm afraid that changing current NAT practice is going to be an uphill battle.
> 
> - Protocols other than PCP can be used to manipulate mappings. Even more: multiple protocols can be used to manipulate a single mapping.
> 
> - A NAT administrator may want to change mapping lifetimes. An administration script (cron job) could want to do this.
> 
> - NATs have complex behaviours and may decide to change a mapping's lifetime because of arbitrary traffic patterns, because of load conditions, because of the time of day, because of the weather, or just because it feels like it.
> 
> My point is basically that the NAT is authoritative for a mapping's lifetime. Practically, this authority can not be moved to a AAA server.
> 
> Simon
> --

---

From: Simon Perreault <[email-masked]>
Date: Sun, 28 Oct 2012 18:00:46 -0400

> This is where I fail to understand. What I'm saying is, there may exist at least one scenario where the mapping lifetime is centrally controlled by the AAA.

What is this scenario?

> You seem to be saying this is impossible, there's no such a case.

The important word is "practially". Given the current state of NAT 
affairs, I don't see how it would be practically possible to move 
authority over a NAT mapping's lifetime to a AAA server.

> Btw, when the PCP signal creates state on the PCP server, what value of lifetime is assigned to that state? I think you'd say the PCP server decides on its own.

Yes and no. The PCP server is most probably operated by the same entity 
that operates the NAT. So their configurations can be expected to agree 
with each other. But if their is disagreement, the NAT has the final say.

> A general PCP question: Should the PCP server indicate the associated lifetime to the PCP client at the time of state creation via PCP?

Unless I'm misunderstanding, it already does. A successful MAP response 
contains the created mapping's lifetime.

> Without this knowledge, the PCP client cannot properly "maintain" the state on the PCP server.

Everything about NAT is a hack.

Simon

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 29 Oct 2012 01:51:51 +0000

> >> My point is basically that the NAT is authoritative for a mapping's lifetime.
> Practically, this authority can not be moved to a AAA server.
> >
> > This is where I fail to understand. What I'm saying is, there may exist at least
> one scenario where the mapping lifetime is centrally controlled by the AAA.
> 
> What is this scenario?

Support that It should be the NAT itself to decide the life period of a mapping. In addition, the loosely coupled auth/authz solution can work well within the scenarios where X=Y (if there is any), right?

> > Btw, when the PCP signal creates state on the PCP server, what value of
> lifetime is assigned to that state? I think you'd say the PCP server decides on its
> own.
> 
> > A general PCP question: Should the PCP server indicate the associated
> lifetime to the PCP client at the time of state creation via PCP?
> 
> > And if so, should the PCP server notify the PCP client when the lifetime
> changes (due to some of those external factors you listed above)?

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 29 Oct 2012 07:43:29 +0000

On 10/28/12 2:10 PM, "Alper Yegin" <[email-masked]> wrote:

>This is where I fail to understand. What I'm saying is, there may exist
>at least one scenario where the mapping lifetime is centrally controlled
>by the AAA.

[Reinaldo] Hi Alper,

I'm not sure we are saying is impossible, certainly if we dig we can find
a scenario. But I believe we need to gauge if this scenario is practical
and will be used by people deploying PCP.

The authentication work was meant to meet security requirements spelled
out in pcp-base. 

>lifetime is assigned to that state? I think you'd say the PCP server
>decides on its own.

It is already part of the protocol.

>changes (due to some of those external factors you listed above)?

It is also part of the protocol. We have unsolicited notifications due to
mapping updates.

>>> - Next time he wants to send a PCP request to you, you can
>>>authenticate and authorize him by using the following session
>>>credentials (MSK, or an MSK child key + an id [session id]). You don't
>>>have to come back and ask me to authenticate and authorize.
>>> - This session credential is good for duration of X. (this is the
>>>authorized lifetime of joe to be using PCP with the PCP server). After
>>>X has passed, throw the session credential away, it's useless.
>>> - Feel free to come back to me to re-auth and re-authorize anytime
>>>before X has passed. You'll get a new session credential, and a new
>>>lifetime.
>> 
>>> For a mobile subscriber accessing wireless network whose apps are
>>>creating NAP mappings, this does not make sense. Network resources are
>>>tightly controlled, and the PCP clients come and go.
>> 
>>> We are going beyond today's NAT operation with the introduction of
>>>"authenticated signaling setting up and maintaining NAT tables".
>> 
>> I'm not sure what you mean exactly by this, but I'm afraid that
>>changing current NAT practice is going to be an uphill battle.
>> 
>>> - So, even after PCP SA is expired, we cannot remove the mapping
>>>because now the mapping is in use and maintained by the app traffic.
>>>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Oct 2012 12:44:59 +0200

>> This is where I fail to understand. What I'm saying is, there may exist at least one scenario where the mapping lifetime is centrally controlled by the AAA.

Here's the scenario:

Consider a mobile/wireless network (WiFi hotspots, 3G/4G, etc.).
Mobile host's network access session is AAA'ed by a AAA server and granted lifetime == A.
If and when the host uses PCP to set up NAT state or firewall state, it'll be AAA'ed by the same AAA server and granted lifetime == remainder of A.

Network access session,
PCP session (I mean, the state associated with PCP, which is PCP SA, etc.), and
the state created by the PCP (the NAT mapping, firewall rules) are all synchronized.

They all expire at the same time.

This is typically how sessions are managed in mobile/wireless network architectures and deployments.

> The important word is "practially". Given the current state of NAT affairs, I don't see how it would be practically possible to move authority over a NAT mapping's lifetime to a AAA server.
> 
> Yes and no. The PCP server is most probably operated by the same entity that operates the NAT. So their configurations can be expected to agree with each other. But if their is disagreement, the NAT has the final say.
> 
> Unless I'm misunderstanding, it already does. A successful MAP response contains the created mapping's lifetime.
> 

:-)

I'm seeing PCP bringing some determinism to this. PCP is setting up state on the NAT/Firewall, learning the granted lifetime, and even getting notified when that lifetime changes, etc. This is becoming more managed/manageable.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Oct 2012 12:52:28 +0200

Hi Simon,

> It is also part of the protocol. We have unsolicited notifications due to

This brings up an interesting issue.

Such notifications need to be secured as well. 
So, tossing away the PCP SA as soon as PCP signaling is done (like Sam was suggesting) cannot be done because the PCP Server may be sending such unsolicited notifications anytime.
Or, if you insist on tossing the PCP SA right away, we certainly need server-initiated EAP re-auth to cover for the case there is no PCP SA when the server needs to send an unsolicited notification.

Alper

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 29 Oct 2012 23:59:12 +0000

Some comments inline...

On 10/29/12 3:44 AM, "Alper Yegin" <[email-masked]> wrote:

>>> This is where I fail to understand. What I'm saying is, there may
>>>exist at least one scenario where the mapping lifetime is centrally
>>>controlled by the AAA.
>> 
>> What is this scenario?
>> 
>
>Here's the scenario:
>
>If and when the host uses PCP to set up NAT state or firewall state,
>it'll be AAA'ed by the same AAA server and granted lifetime == remainder
>of A.

[Reinaldo]

It seems we are going off track. The authentication work was meant to meet
certain set of requirements.

What would be the leanest solution that meets those requirements? Extra
functionality, albeit nice, needs further discussion.

Having said that, certainly we do not want mappings to survive (much)
longer than the Mobile
session. There is some text on PCP-base about it.

"To help clean PCP state, it is RECOMMENDED that devices which combine
   IP address assignment (e.g., DHCP server) with the PCP server
   function (e.g., such as a residential CPE) flush PCP state when an IP
   address is allocated to a new host, because the new host will be
   unable perform the functions described in the previous paragaph
   because the new host does not know the previous host's Mapping Nonce
   value.  It is good hygiene to also flush TCP and UDP flow state of
   NAT or fireall functions, although out of scope of this document."

In other words, when detecting that a Mobile host disconnects the address
allocation function can flush state by some other means.

>architectures and deployments.

[Reinaldo]

Today CGN is heavily deployed in wireless networks and in general NAT or
Firewall mappings survive after user disconnects. They go away due to idle
Timeouts. 

There are a few CGN implementations with subscriber awareness that on
receiving a Radius 
Stop flush all NAT state.

But I'm personally not aware of any implementation where the NAT mapping
time is the 
remainder of the Mobile Host session time.

>>> Btw, when the PCP signal creates state on the PCP server, what value
>>>of lifetime is assigned to that state? I think you'd say the PCP server
>>>decides on its own.
>> 
>>> And if so, should the PCP server notify the PCP client when the
>>>lifetime changes (due to some of those external factors you listed
>>>above)?
>I'm seeing PCP bringing some determinism to this. PCP is setting up state
>on the NAT/Firewall, learning the granted lifetime, and even getting
>notified when that lifetime changes, etc. This is becoming more
>managed/manageable.
>
>Alper
>
>
>
>
>
>> Simon
>> --

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Oct 2012 20:37:18 -0400

>>>>> "Reinaldo" == Reinaldo Penno (repenno) <[email-masked]> writes:

    Reinaldo> It seems we are going off track. The authentication work
    Reinaldo> was meant to meet certain set of requirements.

    Reinaldo> What would be the leanest solution that meets those
    Reinaldo> requirements? Extra functionality, albeit nice, needs
    Reinaldo> further discussion.

    Reinaldo> Having said that, certainly we do not want mappings to
    Reinaldo> survive (much) longer than the Mobile session. There is
    Reinaldo> some text on PCP-base about it.

    Reinaldo> "To help clean PCP state, it is RECOMMENDED that devices
    Reinaldo> which combine IP address assignment (e.g., DHCP server)
    Reinaldo> with the PCP server function (e.g., such as a residential
    Reinaldo> CPE) flush PCP state when an IP address is allocated to a
    Reinaldo> new host, because the new host will be unable perform the
    Reinaldo> functions described in the previous paragaph because the
    Reinaldo> new host does not know the previous host's Mapping Nonce
    Reinaldo> value.  It is good hygiene to also flush TCP and UDP flow
    Reinaldo> state of NAT or fireall functions, although out of scope
    Reinaldo> of this document."

    Reinaldo> In other words, when detecting that a Mobile host
    Reinaldo> disconnects the address allocation function can flush
    Reinaldo> state by some other means.

I think this is a really interesting point.

In the mobile/wireless use case, it doesn't make sense for the mapping
lifetime to come from PCP authentication; instead it needs to come from
the address allocation.
That may involve an EAP authentication or not.
The interesting thing here is that we want to tie the mapping lifetime
to the network access lifetime, not to the PCP authentication lifetime.

The NAT administrator wants to tie the mappings to the network access
lifetime even ifthe mappings are implicit, configured with  some
protocol other than PCP or configured with PCP.
Even if they are configured with PCP, some mappings may be configured
using unauthenticated PCP.

If authenticated PCP is involved in this use case, I find it strange
that we'd want to tie the mapping lifetime to the PCP authentication
lifetime.
I wouldn't find it strange if the PCP authentication lifetime happened
to be tied to session lifetime, but that's a policy for the AAA server
to implement or not.

Also, as several of us have mentioned, a PCP server can tie the two
lifetimes together if it likes.
I see no reason why the PCP authentication protocol need concern itself
with the mapping lifetime. 
--Sam

---

From: Alper Yegin <[email-masked]>
Date: Wed, 31 Oct 2012 11:36:40 +0200

> allocation function can flush state by some other means.

You are talking about something else. Cleaning state when the MS leaves.
I'm talking about setting the lifetime of state when it's created. 
I'm saying the network operator can assign lifetime to various states such that they are all aligned with the "mobile host's network access session".
This is how we typically design the cellular architectures (3GPP, 3GPP2, WiMAX, etc.) FYI.

> remainder of the Mobile Host session time.

Because, none of those "legacy" solutions involve host/subscriber authentication with AAA and explicit signaling with the host to maintain state.
So, I'd not be surprised if we are deviating from todays NAT state management. After all, this whole PCP thing is for that…..

Alper

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 31 Oct 2012 11:04:17 +0000

Hello,

Inline...

>I'm talking about setting the lifetime of state when it's created.

[Reinaldo] I'm assuming you want to do that so there is no state when
Mobile user disconnects. Otherwise could you explain what is the driver?

> 
>I'm saying the network operator can assign lifetime to various states
>such that they are all aligned with the "mobile host's network access
>session".
>Because, none of those "legacy" solutions involve host/subscriber
>authentication with AAA and explicit signaling with the host to maintain
>state.
>So, I'd not be surprised if we are deviating from todays NAT state
>management. After all, this whole PCP thing is for thatŠ..

[Reinaldo] Are you suggesting that 'legacy' mappings will go away and only
authenticated PCP mappings will be used? I would say that a FW or NAT will
have regular outbound mappings, port forwarding, non-authenticated PCP
PEER and MAP, authenticated PCP PEER and MAP. You can only control
lifetime through AAA for the latter two.