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

["MORAND Lionel RD-CORE-ISS" <lionel.morand at orange-ft.com>]

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:rdroms at cisco.com] 
> Envoyé : mardi 10 octobre 2006 08:06
> À : Yoshihiro Ohba; Alper Yegin
> Cc : 'Mark Townsley'; 'Mohan Parthasarathy'; pana at ietf.org
> 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" <yohba at tari.toshiba.com> 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 <alper.yegin at yegin.org>
> >>>>>>>>>> To: Mohan Parthasarathy <mohanp at sbcglobal.net>; Yoshihiro 
> >>>>>>>>>> Ohba <yohba at tari.toshiba.com>; Mark Townsley 
> >>>>>>>>>> <townsley at cisco.com>
> >>>>>>>>>> Cc: pana at ietf.org
> >>>>>>>>>> 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
> > Pana at ietf.org
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana