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

From: Alper Yegin <[email-masked]>
Date: Fri, 2 Nov 2012 11:56:24 +0200

>>> 
>>> In other words, when detecting that a Mobile host disconnects the
>>> address
>>> 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.
> 
> [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?
> 

What you are describing is the "trigger to clean up state when the network detects MS has detached".
What I'm talking about is the "trigger to clean up state based on a timer".
Both are needed, and used.
The latter is primarily for covering the case when the network cannot detect detachment.
And it's also for the case the service is authorized for a fix amount of time and is not extensible.

>> 
>> 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.
>> 
>>> 
>>>> 
>>>> 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.
>>> 
>>> 
>>> [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.
>>> 
>> 
>> 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?

Nope, I'm not saying this at all.

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

We're circling now.

All I'm saying is (which btw, does not really have much affect on the discussion anymore), by using PCP, I can design an architecture where the state created by PCP can have lifetime set to the lifetime of the mobile host's network access session. For example, a firewall rule created by the host may have its lifetime set to current network access session (e.g., 24 hours).  

Alper

>> 
>> Alper
>> 
>> 
>> 
>> 
>> 
>>> 
>>>> 
>>>> 
>>>>>> 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.
>>>>> 
>>>>>> 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.
>>>>> 
>>>>> Everything about NAT is a hack.
>>>>> 
>>>> 
>>>> :-)
>>>> 
>>>> 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
>>>>> -- 
>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> pcp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pcp
>>> 
>> 
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 02 Nov 2012 12:08:51 +0100

Le 2012-11-02 10:56, Alper Yegin a écrit :
> All I'm saying is (which btw, does not really have much affect on the
> discussion anymore), by using PCP, I can design an architecture where
> the state created by PCP can have lifetime set to the lifetime of the
> mobile host's network access session.

This is true. However that doesn't make it tightly coupled. If the NAT 
can still change the mapping's lifetime without telling the AAA server, 
then it's still loosely coupled.

AAA server giving a "hint" to the NAT about a mapping's initial 
lifetime: fine. We're still in loosely coupled territory.

What happens after mapping creation is what matters.

Simon

---

From: Alper Yegin <[email-masked]>
Date: Sun, 4 Nov 2012 22:17:31 +0200

On Nov 2, 2012, at 1:08 PM, Simon Perreault wrote:

> This is true. However that doesn't make it tightly coupled. If the NAT can still change the mapping's lifetime without telling the AAA server, then it's still loosely coupled.
> 

I gotta tell you, the way these terms (loosely and tightly coupled) on Margaret's slides have issues.
I'd agree with your above statement if I can disregard the definitions on those slides.

> AAA server giving a "hint" to the NAT about a mapping's initial lifetime: fine. We're still in loosely coupled territory.
> 

1. In NAT case, there are multiple actors affecting the mappings, hence I understand the lifetime of mappings cannot be exclusively dictated by the AAA. 
We need to define how the lifetime is managed, and how the relevant parties get to know about it (and if they need to know about it).
For example, PCP client needs to know if the mapping lifetime changes, and it does know thru PCP.
How about the AAA server? Does it need to know, or not? It depends on what it meant by sending a lifetime value. Is it was just a hint, it does not care if the NAT did something else. If it was meant to be an authoritative value, then at least a change in the effective value needs to be notified to the AAA server, if not confirmed. Not sure if these are needed.

2. In firewall case, I think lifetime of the rule can be dictated by the AAA. Or at least, there exist some use cases where the AAA server would like to control the lifetime (as in my examples).

Alper

---

From: Simon Perreault <[email-masked]>
Date: Mon, 05 Nov 2012 08:06:37 -0500

> How about the AAA server? Does it need to know, or not? It depends on what it meant by sending a lifetime value. Is it was just a hint, it does not care if the NAT did something else. If it was mea…

Agreed. This is a good summary.

> 2. In firewall case, I think lifetime of the rule can be dictated by the AAA. Or at least, there exist some use cases where the AAA server would like to control the lifetime (as in my examples).

Possible. I'd like to see what others think of this.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Nov 2012 10:00:22 -0500

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

    >> 2. In firewall case, I think lifetime of the rule can be dictated
    >> by the AAA. Or at least, there exist some use cases where the AAA
    >> server would like to control the lifetime (as in my examples).

    Simon> Possible. I'd like to see what others think of this.

I don't expect I'd want this in the enterprise cases I'm familiar with.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 6 Nov 2012 04:20:01 +0000

Hello,

My review attached.

Thanks,

Reinaldo

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 6 Nov 2012 05:50:22 +0000

Hello,

My review of the attached draft.

Regards,

Reinaldo

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 26 Nov 2012 14:34:39 +0000

PCP

THU 1510-1710 =============

Welcome, Agenda bashing                                 (5, Chairs)

Francis Dupont: Adopt DS-Lite document as WG document?  Dave Thaler: Will
post
question on mailing list

    WGLC Results                                        (30)
    draft-ietf-pcp-base                                 (Dan Wing)

Paul Selkirk: The restrictions about delete-all should only apply to the
simple
threat model, not the advanced threat model

Dan Wing: We don't have the text for advanced threat model written yet

Paul Selkirk: But the document still describes delete-all, and then says it
doesn't work

Dave Thaler: Document can reference what's allowed under advanced threat
model,
without specifying how advanced threat model will work

Paul Selkirk: Disallowing delete-all is a loss of functionality compared to
NAT-PMP

Stuart Cheshire: But we decided that functionality was not a good idea

Margaret Wasserman: Document should limit making educated guesses about
what
advanced threat model allows before we know how advanced threat model
works.

Dave Thaler: Document should explicitly state this explicitly, e.g. "If
simple
threat model, then nonce must match; advanced threat model is yet to be
defined"

    draft-ietf-pcp-upnp-igd-internetworking

Paul Selkirk: I have some minor editorial nits with this document, but
overall
it is complete, and has no wacky ideas.

    draft-ietf-pcp-dhcp                               (Mohamed Boucadair)

Stuart: Why name rather than IP address?

Ralph: Use RFC 1035 encoding for forward compatibility with changes to
DNS, e.g.
internationalization.  Dave: RFC 1035 restricts us to DNS names.  Strings
are
not DNS names, pass string to name resolver, not specifically DNS resolver.

Stuart: We should make a decision, should not accept non-fully qualified
domain
names (including trailing '.').

Stuart Cheshire: Should fit in with existing DHC conventions Mohamed
Boucadair:
This issue is closed; this WG and DHC have already approved this

Ralph Droms: Really? DHC discussed this only this morning.

Stuart Cheshire: Whatever it says, the document needs to be unambiguous

Pete Resnick: Is what the DHCP server hands out protocol, or is it
presentation
layer that gets translated into protocol? If it's protocol, define it
tightly.
If it's presentation layer, you have to deal with all kinds of translation
issues.

Dave: It's protocol.

Stuart: If we require the client to validate the name, we have to say how,
but
it's okay to remove the restriction in the first place.

Stuart: Happy to defer to DHC WG about how to convey multiple strings.
(e.g.
single option with null separators or space separators.)

Dan: Embedded nulls make me nervous, because poorly-written clients pass
strings
to things like strcpy().

Ralph: Multiple options or multiple sub-options are the norm in DHCP
(including
v6).

Dave Thaler: In DHCPv4, multiple options are concatenated, so even with
multiple
options a separator or length prefix is still necessary

Med to consult with Ted Lemon. If no objection, adopt Stuart's proposal for
length byte followed by string, optionally followed by more counted
strings?

Optimizing NAT and Firewall Keepalives Using PCP      (10, Markus Isomaki)
draft-reddy-pcp-optimize-keepalives

Keepalive Incentive Issues                            (10, Dave Thaler)
(draft-ietf-pcp-base, draft-reddy-pcp-optimize-keepalives)

Dave: Should we recommend that middleboxes give longer mapping timeout as a
result of using PCP than for connections without PCP?  If so, in which
doc?  If
not, what's the point of mentioning it in the spec?

Gang: Reducing keepalives beneficial not only to power, but to reducing
congestion on the air interface.

Stuart: Usefulness of timeout detection algorithms is unproven.  You're
assuming
the lifetime of two different mappings is the same.  You're assuming
there's a
stable lifetime in the first place.  PEER gives the client a defined,
committed
lifetime, so this gives you more reliability.

Markus: Timeout detection algorithms are known to fail. This may make them
more
reliable.

Reinaldo: This could give us a way to detect not just the first middlebox,
but
other on-path middleboxes as well.

Simon: We don't have any operational experience with this, so making a
recommendation may be premature.  Dave: There are documents in the IESG
that are
requiring use of PCP for power saving.

Q1: Should there be a statement in some document? Strong hum in favor, none
opposed.  

Q2: Should this statement be in pcp-base? Strong hum in favor, none
opposed.

Ask on list for objections.

Using PCP to control NAT and Firewalls in Multihoming (10, Tiru Reddy)
    draft-patil-pcp-multihoming-00

PCP Server Selection                                  (10, Mohamed
Boucadair)
    draft-boucadair-pcp-server-selection

Tiru Reddy: Propose merging the two documents

Dave: draft-boucadair-pcp-server-selection is a new non-WG document, but
all the
text is from a prior version of the dhcp document, which was accepted as a
WG
document, so the assumption is that this will be accepted as a WG document.

Dave: We could choose to combine these two documents, or say that server
selection stands on its own, and the multihoming draft just covers use
cases.
Prashanth: In favor of merging documents.

Will call on list for objection to adopting as WG document.

Retrieving the Capabilities of a PCP-controlled Device
draft-boucadair-pcp-capability                        (10, Tiru Reddy)

Dave Thaler: Yes, this is a valid problem. Clients may need to tailor
behavior
depending on whether server is NAT or Firewall

Margaret Wasserman: Question is not as simple as "NAT or Firewall?" Things
are
not strictly NATs or firewalls, and the lines can be blurred so much that
you
can't give a meaningful answer.  Very seldom in favor of any
capability-discovery mechanism because they cause unnecessary failures.

Stuart Cheshire: Problem is interesting, but we need to get some
operational
experience before we can say what is the right answer Dan Wing: Agree that
capability discovery is fragile. Taxonomy of NAT vs. Firewall is too
simplistic.

Learn NAT64 PREFIX64s using PCP                       (10, Mohamed
Boucadair)
    draft-boucadair-pcp-nat64-prefix64-option

Dave Thaler: BEHAVE WG has a heuristic for this, which may not work in all
cases

Dan Wing: Should we ask BEHAVE WG to reference this solution?

Dan Wing: Have you done a comparison of the BEHAVE heuristic compared to
the PCP
message?

Mohamed Boucadair: Haven't done a detailed comparison with heuristic.
People
agree PCP is better

Dave Thaler: If DHCP and PCP answers differ, then trust the PCP server --
it
ought to know

Tiru Reddy: PCP version also gives you the lifetime

Dave Thaler: Call for adoption: strong hums in favor, none against.

Analysis of PCP in Mobile Networks draft-chen-pcp-mobile-deployment
(10, Mohamed Boucadair)

Margaret Wasserman: Why would we run PCP differently in mobile networks?
What
makes mobile networks different?

Mohamed Boucadair: It's guidance for network operators Reinaldo: Server
discovery may be different, may not be your default gateway.  Gang Chen:
Mobile
networks are different Margaret Wasserman: What makes PCP server discovery
different

Stuart Cheshire: 3GPP does not use DHCPv4, so it's not that "mobile" is
different, it's that we have to define how to do PCP server discovery on
3GPP

Stuart Cheshire: Apple Airport will act on any PCP request it sees,
regardless
of destination addr/port. So the solution may be anycast.

Using PCP To Coordinate Between the CGN and Home Gateway Via Port
Allocation
draft-tsou-pcp-natcoord-08                            (10, Simon Perreault)

Alain Durand: Is this for PEER or only MAP?  Simon Perreault: Only MAP
Alain: I
don't buy the no-DHCP argument. Also, is this idempotent?  Simon: If you
retransmit the same request with the same nonce, you get the same port
set. If
you transmit a new request with a new nonce, you get a different port set.

Dave: Is this only for NAT44, or can it be extended to NAT64?  Simon: This
works
the same for NAT44, NAT64, NAT66, etc.

Call on list for adoption.

Dave: Thanks to Alain for his service.

=== END ===