Subject: RE: [Pana] WG Review: Recharter ofProtocolforcarryingAuthenticationfor Network Access (pana)

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Tue, 21 Jun 2005 14:24:19 -0400

There are enterprise deployment scenarios where restrictions on the
placement of  PAA and EP would be problematic (esp where both PAA and EP
are assumed to be co-located). 

While first-hop deployments are likely to be common and may need to be
optimized for, there are cases where multi-hop deployments are needed,
depending on what a user of this technology is trying to protect, what
the roll-out plans are, and to what extent already-deployed network
devices can be enabled/upgraded as necessary. Some use cases were
documented in the multi-hop PANA I-D (draft-ohba-multihop-eap-00). 

The charter and the protocol must not preclude these deployment
scenarios.

More inline ... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mohan Parthasarathy
> Sent: Monday, June 20, 2005 5:08 PM
> To: Yoshihiro Ohba
> Cc: Alper Yegin; [email-masked]; 'Sam Hartman'; Mark Townsley 
> (townsley); [email-masked]; 'Russ Housley'; John Schnizlein (jschnizl)
> Subject: Re: [Pana] WG Review: Recharter 
> ofProtocolforcarryingAuthenticationfor Network Access (pana)
> 
>  
> > I have a feeling that this is a good opportunity to make a 
> change on 
> > that and I have one usage:
> > 
> > An access network consists of a set of IP links and routers 
> where the 
> > IP links are using different link-layer types.  Instead of using 
> > different L2 ciphering mechanisms per link-layer type, one 
> may want to 
> > use IPsec for all links.  Then it might make sense to place 
> EP(s) on 
> > the router(s) at the boundary between the access network 
> and the rest 
> > of the Internet, instead of having an EP on each router that is one 
> > hop away from PaC.  This is also good for mobility, because once an 
> > IPsec SA is bootstrapped between a PaC and the EP that is multiple 
> > hops away from the PaC, the PaC does not need to perform 
> > Diffie-Hellman key exchange every time it switches from one 
> IP link to 
> > another in the same access network.  Instead, the PaC will 
> just need 
> > to perform MOBIKE for updating IP address of the IPsec SA.
> > 
> This looks like HMIP :-) When you change access routers 
> within the same access network, you still configure a new 
> PRPA. Doesn't that trigger mobility at L3 ? Or you have 
> assumed that all of them are advertising the same prefix or 
> something else to suppress L3 movement detection i.e how does 
> it interact with "mobility" ?
> 
> 
> > Note that as a side effect of allowing PAA to be multiple hops away 
> > from PaC, the PANA protocol itself has already been 
> designed enough to 
> > allow IPsec EP to be multiple hops aways from PaC.  So it 
> seems to me 
> > that this is basically a deployment issue.
> > 
> To some extent i agree that it is a deployment issue. But it 
> makes some assumptions which i don't know whether it is valid 
> or not (today or tomorrow).
> 
> 1) The access network supports links of different access 
> types (WLAN, Wimax etc.) 
>      and controlled by the same operator. If it is not the 
> same operator, you can't have
>      a single EP at the boundary of internet and access network.
> 
> 2) Most of the access network has some form of "filtering" or 
> "enforcement" at the edge.
>     Why would that change in the future ? There is one 
> exception to this that in some of the
>     WLAN hotspot deployments that i know of, which uses web 
> authentication (not 802.1x)
>     the access control is not done at the APs or the router 
> it connects to but the access controller
>     that sits in a centralized place. I don't know whether 
> this is an indicator of change :-) With 802.1x,
>    it will  still be in the access points (at least the 
> per-packet encryption/authentication).
> 
> To some extent,  i do agree that we don't have to explicitly 
> restrict the charter to say that "EP should be just one hop 
> away". But implicitly assuming that it would work may not be 
> good.  We have at least provide some guidance (in the PANA framework
> document) on how this can be deployed. I am not sure what you 
> wanted and don't know how fits well within the current scope 
> of the working group.
> 

[Susan] What deployment issues are you concerned about that need to  be
documented in a framework doc?

Thanks
Susan

> -mohan
> 
> 
> 
> -mohan
> 
> > Best regards,
> > Yoshihiro Ohba
> > 
> > 
> > 
> > On Tue, Jun 14, 2005 at 06:05:50PM -0700, Mohan Parthasarathy wrote:
> > >  > > >
> > > > > > The WG didn't feel a need to make a change on that. 
> (Though I 
> > > > > > guess
> > > > with
> > > > > > little or no change on the PANA-IPsec document that 
> could be 
> > > > > > accomplished).
> > > > > 
> > > > > Why not? Can we have a little more detail?
> > > > 
> > > > The location of the PAA and the location of the EP(s) are 
> > > > independent from each other. People could have asked 
> for off-link 
> > > > EPs even when the PAA was mandated to be on-link.
> > > > 
> > > > There is a tendency that the EP should be on the 
> network element 
> > > > closest to the PaCs. I think that's why WG members are content 
> > > > with the current design. Of course we should let anyone 
> who has a 
> > > > different point of view to speak up.
> > > > 
> > > I am not convinced that the use case of EP being multiple 
> hops away 
> > > has been discussed before in this mailing list. Till someone can 
> > > describe the use case, we should not talk about it in the 
> recharter.
> > > 
> > > -mohan
> > > 
> > > 
> > > > 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
> 
> _______________________________________________
> 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: Jari Arkko <[email-masked]>
Date: Wed, 22 Jun 2005 08:01:39 +0300

>>of the working group
Do we know of any specific reason why multi-hop would
not work? Say, a box that integrates the PAA and EP and
sits at the border between the access network and the
Internet connection? I'm not aware of any reason... though
I realize that some of the mobility optimizations people have
thought of might have issues. But not the base. Or am I
missing something?

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 22 Jun 2005 19:24:05 -0700

> thought of might have issues. But not the base. Or am I
Agreed that the base spec should just work without any changes.
But my concern is, none of the multi-hop use cases are described
in any official PANA document. It is left for reader's imagination
when they read "Both PAA and EP can be multiple hops away". 
Perhaps, it is okay..but sounded odd to me..

Yoshi's use case relates to mobility (which is not included in the
charter) and we can work out the details later. 

 Interestingly, neither PANA requirements nor the threat analysis was
 done with more than one hop in mind. Now everything just seems
 to work with multiple hops. It is too good to be true :-)

-mohan

-mohan