Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 10 Oct 2006 10:13:08 +0200

For the specific case of PPAC, I wonder if we could rely on DHCP Relay Agent Subscriber-ID Sub-option [RFC 3993]to inform the DHCP server that the new DHCP request is for an authenticated PaC.
The DHCP Relay Agent would be co-located with the EP (that would be the case for instance in DSL deployment). The EP would insert this sub-option only in case of PANA authentication success (or for other reasons outside the PANA context). It could be a way for the DHCP server to discrimnate the type of IP addresses to allocate (short-lease vs long-lease).
As Subscriber-ID, we could re-use the PANA Session-ID or any other appropriate value.

Does it make sense?

BR,

Lionel

> -----Message d'origine-----
> De : Ralph Droms [mailto:[email-masked]] 
> Envoyé : mardi 10 octobre 2006 08:06
> À : Yoshihiro Ohba; Alper Yegin
> Cc : 'Mark Townsley'; 'Mohan Parthasarathy'; [email-masked]
> Objet : Re: PPAC needed? (was RE: [Pana] Other suggestions 
> for pana-pana)
> 
> A couple of practical considerations...
> 
> Adding PAA-DHCP interaction now involves an entirely 
> different protocol suite and creates inter-protocol 
> entanglements.  While there may be some standards-based ways 
> for PAA-EP interaction (SNMP? [I know the issue is out of 
> scope for the doc itself]), there is no such mechanism in 
> place for DHCP today.
> 
> DHCPv4 reconfiguration is, as far as I know, not implemented 
> anywhere, so a requirement for DHCPv4 reconfiguration is 
> another inter-protocol entanglement.
> 
> I don't intend to imply that these considerations are 
> show-stoppers; I do see a difference in practice between 
> PAA-EP interaction and PAA_DHCP interaction.
> 
> - Ralph
> 
> 
> On 10/9/06 8:47 PM, "Yoshihiro Ohba" <[email-masked]> wrote:
> 
> > Alper,
> > 
> > On Mon, Oct 09, 2006 at 10:19:45PM +0300, Alper Yegin wrote:
> >>>> Or...
> >>>> 
> >>>> PRPA can be a temporary IP address allocated by the DHCP.
> >>>> Unspecified-sourced clients are allowed to hit the DHPC 
> server and
> >>> allocated
> >>>> the temp IP address. Once the client is PANA 
> authenticated, now the 
> >>>> PRPA-sourced IP packet is allowed to hit the DHCP server and 
> >>>> allocated permanent address.
> >>> 
> >>>> There may be other (better) architectural solutions that do not 
> >>>> require PAA-DHCP signaling.
> >>>> 
> >>> If the DHCP server hands out temporary and permanent addresses 
> >>> depending on whether authentication has occurred or not, 
> I don't see 
> >>> how you get around some sort of PAA-DHCP interaction anyway. This 
> >>> could be via option 82 information inserted by the PAA, or some 
> >>> other direct communication (or just assume that they are 
> co-located for these cases).
> >> 
> >> In my above example, the deployment depends on the EP doing the 
> >> appropriate filtering. Anyways, this is just an example of how "a" 
> >> deployment can achieve this without requiring PAA-DHCP interaction.
> > 
> > I don't see much difference between PAA-EP interaction and PAA-DHCP 
> > interaction.  In fact, I tend to view the DHCP server as another EP.
> > 
> > Since DHCP server can send a reconfiguration trigger to 
> DHCP client, I 
> > think we can simply rely on such a DHCP functionality and simplify 
> > PANA not requiring PaC to take any active role for IP address 
> > reconfiguration.
> > 
> > Yoshihiro Ohba
> > 
> > 
> >> 
> >> I acknowledge that some other deployments may prefer relying on 
> >> PAA-DHCP interaction. I'm fine with that, as long as we 
> don't need to 
> >> build any more bits into the PANA specification to support that :-)
> >> 
> >> Alper
> >> 
> >> 
> >> 
> >> 
> >>> 
> >>> - Mark
> >>>> 
> >>>> 
> >>>>>> Not only that, but also in a given deployment the IP address
> >>>>>> 
> >>>>> configuration
> >>>>> 
> >>>>>> mechanism may not even be based on DHCP. It's simpler and more
> >>> scalable
> >>>>>> 
> >>>>> to
> >>>>> 
> >>>>>> give a one-bit heads up to the PaC, and let it do whatever it 
> >>>>>> does to configure another IP address.
> >>>>>> 
> >>>>>> 
> >>>>> This is a classic argument over where the complexity 
> lies - in the 
> >>>>> PaC or in the Network. I think there are tradeoffs both ways on 
> >>>>> this. I do think that the communication from the PAA to 
> PaC here 
> >>>>> should be optional,  leaving the door open for the Network to  
> >>>>> hand out a new IP address on its own accord without 
> relying on the 
> >>>>> PaC to ask for one in all cases where it is necessary.
> >>>>> 
> >>>> 
> >>>> Sure, that's fine.
> >>>> 
> >>>> 
> >>>>> In general, renegotiating an IP address is typically 
> problematic 
> >>>>> on
> >>> IPv4
> >>>>> networks today (HIP and such aside). I don't think PANA 
> should be 
> >>>>> recommending this as not all stacks, transports, and 
> applications 
> >>>>> can handle it without difficulty (e.g., if this is a MUST for 
> >>>>> PANA, it raises the bar considerably for where PANA 
> could be used).
> >>>>> 
> >>>> 
> >>>> It's not a MUST for PANA (more specifically "for PaC").
> >>>> 
> >>>> Alper
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>>> - Mark
> >>>>> 
> >>>>> - Mark
> >>>>> 
> >>>>>> Alper
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>>> - Mark
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> Yoshihiro Ohba
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> On Sun, Oct 08, 2006 at 01:04:03AM +0300, Alper Yegin wrote:
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>>> If the initial address (PRPA) is not a link-local address, 
> >>>>>>>>>> then
> >>> you
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>> can
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>>> use it both before and after PANA. Either it is a private 
> >>>>>>>>>> address
> >>>>>>>>>> 
> >>>>> that
> >>>>> 
> >>>>>>>>>> gets NATed or a public address. If the underlying 
> protection 
> >>>>>>>>>> (e.g. IPsec) needs another address, it may have to get
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>> another
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>>> address which PANA does not have to worry about it i guess.
> >>>>>>>>>> Missing something ?
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>> You only talked about the IPsec case.
> >>>>>>>>> 
> >>>>>>>>> But for example in DSL case, the PaC cannot know 
> whether the 
> >>>>>>>>> PRPA
> >>> is
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>> good
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>> for post-PANA data communication or not. Unless the 
> PRPA is a 
> >>>>>>>>> link-
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>> local
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>> address, the PaC cannot tell one way or the other. 
> And there 
> >>>>>>>>> is no
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>> IKE/IPsec
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>> in that case.
> >>>>>>>>> 
> >>>>>>>>> Alper
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>>> -mohan
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> ----- Original Message ----
> >>>>>>>>>> From: Alper Yegin <[email-masked]>
> >>>>>>>>>> To: Mohan Parthasarathy <[email-masked]>; Yoshihiro 
> >>>>>>>>>> Ohba <[email-masked]>; Mark Townsley 
> >>>>>>>>>> <[email-masked]>
> >>>>>>>>>> Cc: [email-masked]
> >>>>>>>>>> Sent: Friday, October 6, 2006 1:19:37 PM
> >>>>>>>>>> Subject: RE: PPAC needed? (was RE: [Pana] Other 
> suggestions 
> >>>>>>>>>> for
> >>>>>>>>>> 
> >>>>> pana-
> >>>>> 
> >>>>>>> pana)
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>>> Mohan,
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>>> So,
> >>>>>>>>>>> we can
> >>>>>>>>>>> potentially make it by restricting what sort of 
> an address 
> >>>>>>>>>>> it
> >>>>>>>>>>> 
> >>>>> obtains
> >>>>> 
> >>>>>>>>>>> before running
> >>>>>>>>>>> PANA so that it does not require a new one after 
> (it can be
> >>> outside
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>> the
> >>>>>>> 
> >>>>>>> 
> >>>>>>>>>>> PANA spec)
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>> I'm not sure I understand this proposal. Can you 
> please elaborate?
> >>>>>>>>>> 
> >>>>>>>>>> Thanks.
> >>>>>>>>>> 
> >>>>>>>>>> Alper
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> >> 
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

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

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Oct 2006 13:29:43 +0300

Let's walk over this step by step.

For deployments that don't mind handing out non-temporary IP addresses prior
to PANA authentication, we don't have a problem.

For deployments where PaC's PRPA is a link-local address, obviously PaC
would know to configure a POPA via DHCP. No problem.

For deployments where PaC's PRPA is a temporarily allocated address (an IPv4
address), a POPA configuration needs to take place. The question is: How
does this get initiated?

If PAA and DHCP server are co-located, than an API can trigger the DHCP
server to initiate the process. No protocol work is needed.

[One WG choice is to stop here for now. Meaning: Deployments/architectures
that want to split the PAA and DHCP server, they've gotta deal with it.]

If PAA and DHCP server are not co-located, we have two options to consider:
a- Trigger PaC to initiate the process
b- Trigger DHCP server to initiate the process

Option (a) can be achieved by defining one bit in PANA. There were two
questions on that approach:
1- How does the PAA know to set that bit? 

   PRPA/POPA configuration type is a deployment choice. As such, it would
   be one of the PAA configuration parameters.

2- Even in that case, wouldn't we still need a PAA-DHCP interaction, so that
the DHCP server knows when to allocate PRPA vs. POPA?

   This is not a "must have." One can design architectures using this bit
and not necessarily requiring any PAA-DHCP interaction. For example: EP
allows unspecified sourced DHCP packets from unauthenticated PaCs to hit the
DHCP server. And the DHCP server allocates PRPA to such PaCs. Upon PANA
authentication, now the EP allows PRPA-sourced DHCP packets from the
authenticated PaC to hit the DHCP server. And now DHCP allocates POPA. DHCP
server in that deployment can make the distinction based on the source
address. Or, if the DHCP relay and EP are co-located, EP can also set some
bits on DHCP to signal that PaC is an authenticated one.

  Anyways, this is just an example of how using option (a) does not
automatically mean option (b) must also be implemented.

[Second WG choice is to stop here. Meaning: Define one bit of PANA to signal
PaC's need to configure another IP address.]

Option (b) requires another protocol design. [I don't even propose we
identify this as a WG choice right now, as we wouldn't want to venture into
more protocol design.]

Comments?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Oct 2006 10:04:47 -0400

> Option (a) can be achieved by defining one bit in PANA. There were two

I think option (a) can be achieved by defining additional information
(a flag?) in draft-ietf-dhc-paa-option.  If this is a deployment
issue on DHCP reconfiguration, solving it within DHCP could make
sense.

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 10 Oct 2006 10:05:15 -0700 (PDT)

>server to initiate the process. No protocol work is needed.
I guess this is the FORCERENEW option i guess.

  > be one of the PAA configuration parameters.

I have to agree with Yoshi that this can be solved outside of PANA. Hence,
we should not need any extra bit.

>identify this as a WG choice right now, as we wouldn't want to venture into

I don't think option b is needed.

-mohan