Subject: Re: [Pana] Identifier for the CTD received by nPAA ?

From: Julien Bournelle <[email-masked]>
Date: Thu, 1 Dec 2005 10:26:50 +0100

Hi yoshi,

On Wed, Nov 30, 2005 at 11:28:48PM -0500, Yoshihiro Ohba wrote:
> > On Wed, Nov 30, 2005 at 06:17:11PM +0530, Sasikanth Bharadwaj wrote:
> > > > > >
> > > >  Another alternative could be to use the MN's pCoA field. Thus the nPAA
> > > >  puts an identifier in it (Session identifier) and the pPAA replies with
> > > >  the same identifier.
> > > >
> > > >  Julien
> > > >
> > > Since the field is supposed to carry an address, I said new COA but as you
> > > said, any identifier should serve the purpose.
> > 
> >  so it appears that we have 3 alternatives:
> > 
> >  1/ leave this to the transport protocol.
> > 	
> > 	this is not a solution if we want to use one TCP connection for
> > 	all CT-Req/CTD exchange between pPAA and nPAA.
> > 	
> >  2/ the PaC provides its pCoA in the PSA message sent to the nPAA
> > 
> >  	it requires to modify the current PANA specs (pana-mobopts and
> > 	pana-statemachine)
> 
> This will not work if pCoA=PRPA=link-local address.  In this case,
> pCoA can conflict if two PaCs moving from two different previous
> networks to the same new network, but happened to have the same link
> local address in their previous networks.

 yes you're right but if we specify that it's the POPA that must be sent
 to nPAA we don't have this problem ?

 (Note that personnaly I would prefer option 3/.)

 Julien
> 
> Yoshihiro Ohba
> 
> 
> > 
> >  3/ nPAA and pPAA uses the MN's pCoA field of CT-Req and CTD as an
> >  identifier to match response to request.
> > 
> > 	in a sense it is compliant with RFC4067 since this field is used
> > 	by the nAR to match the response (as far as I understand)
> > 
> > 	in another sense it is not compliant since it is not the pCoA
> > 
> >  Any comments ?
> > 
> >  Julien
> > > 
> > > Sasikanth
> > > 
> > 
> > -- 
> > julien.bournelle at int-evry.fr
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana

-- 
julien.bournelle at int-evry.fr

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 01 Dec 2005 21:59:28 -0500

Hi Julien,

>  to nPAA we don't have this problem ?

I am not sure if this covers all possible scenarios.  What happens if
the two PaCs were behind different NAT boxes and assigned the same
private address as POPA, and then move to the new network?  I think
similar pCoA conflict can occur in this case.

Or if IPsec ciphering is used between PaC and EPs, then
POPA=IPsec-TIA=pCoA and the pCoA may not be known to pPAA if EP and
PAA are not co-located.  But this is not an issue if pPAA does not use
pCoA as context search key but just use it for matching CT-Req and CTD
(I think option 3/ implies it).

>  (Note that personnaly I would prefer option 3/.)

Option 3/ will work but only for pana-cxtp.  In that sense this looks
like a hack specific to pana-cxtp.  What happens if the pAAA and nPAA
are co-located with access routers and performing context transfer not
only for PANA context but also for contexts of other applications?  I
think some consideration may be needed for avoiding pCoA conflict
between nPAA-generated pCoA (for matching CT-Req and CTD) for
pana-cxtp and MN-generated pCoA carried in CTAR (for normal CXTP).

Yoshihiro Ohba

---

From: Sasikanth Bharadwaj <[email-masked]>
Date: Fri, 02 Dec 2005 13:06:46 +0530

Hi yoshi

comments inline

> similar pCoA conflict can occur in this case.

If we think in terms of COA rather than POPA and PRPA, this kind of conflict
still exists in CXTP because it is the pCOA field that is supposed to aid in
identifying contexts. So, I think the pCOA is expected to be unique/global

> (I think option 3/ implies it).

I'm not sure how such a scenario would occur in the regular CXTP case. But
isn't the PaC expected to send a PUR after configuring POPA? In this case
the pPAA will be aware of PaC's COA.

> pana-cxtp and MN-generated pCoA carried in CTAR (for normal CXTP).

It indeed is a hack specific to pana-cxtp and it will not work if other
contexts are also to be transferred. But anyway, I think contexts for other
applications need to be obtained separately because pana-cxtp is not
compliant with rfc 4067. Am I wrong here?

Sasikanth

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Dec 2005 03:08:19 -0500

Hi Sasikanth,

> identifying contexts. So, I think the pCOA is expected to be unique/global

Yes, I think so.

> the pPAA will be aware of PaC's COA.

In the case of pana-ipsec, PaC is communicating with PAA using PRPA
(=IPsec-TOA) and no PUR is sent to the PAA after configurating POPA
(=IPsec-TOA).

> compliant with rfc 4067. Am I wrong here?

I think you are right. Perhaps some applicability statement is needed
for not supporting contexts for other applications when pana-cxtp is
used.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 2 Dec 2005 11:32:07 +0100

Hi sasikanth and yoshi,

> > identifying contexts. So, I think the pCOA is expected to be unique/global

 yes, as an example, current CXTP does not deal with NAT (cf.
 Introduction)

> > compliant with rfc 4067. Am I wrong here?

 yes you're right. We don't use CTAR, context transfer occurs between
 PAA and not AR, authorization is done using PSA message, and now if we
 agree use of the MN pCoA's field.

> for not supporting contexts for other applications when pana-cxtp is

 yes, I think it's necessary.

 So to conclude on this point, do we agree on:

 - add an applicability statement concerning the use of pana-cxtp
 - use the MN pCoA's field to match CTD to CT-Req

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Dec 2005 21:22:03 -0500

>  - use the MN pCoA's field to match CTD to CT-Req

I agree on the conclusion.

Yoshihiro Ohba