Subject: [Pana] DiameterIdentity of new PAA in draft-ietf-pana-mobopts-01.txt

From: Vijayarajan <[email-masked]>
Date: Tue, 29 Nov 2005 17:07:17 +0530

Hi Julien,
 
In draft-ietf-pana-mobopts-01.txt i.e. "PANA Mobility Optimizations", as
part of
Context transfer, an intermediate AAA-Key material is provided by
previous
PAA to new PAA. 
 
AAA-Key-int = The first N bits of
              HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
Where DiameterIdentity is the identifier of the current(new)
PAA
 
This computation is done at previous PAA. How does the previous
PAA know the DiameterIdentity of current(new) PAA?
This draft suggests "Context Transfer Protocol" RFC4067 as a
Possible way of transferring context. But RFC4067 message 
Context Transfer Request(CT-Req) does not have a field for
sending DiameterIdentity of new PAA. 
 
Is the method of determining DiameterIdentity of new PAA left
to implementations? One method I could think of is a reverse
DNS lookup on new PAA's source address(used in CxTP messages).

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

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 29 Nov 2005 13:27:56 +0100

Hi (again),

  comments inline,

> DNS lookup on new PAA's source address(used in CxTP messages).

 yes this can be done through a reverse DNS lookup as you suggest or by
 preconfiguration. From my point of view, pPAA and nPAA will have SAs to
 protect CXTP exchanges, so pPAA will know nPAAs'identity.

 However, we could also send the nPAA's identity in the CT-Req message
 which would require some modifications to current RFC4067. 
 (Note that we are already not fully compliant to current CXTP RFC.)
 
 Any comments ?

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 29 Nov 2005 23:54:22 +0200

>  (Note that we are already not fully compliant to current CXTP RFC.)

Sending nPAA ID to the pPAA is context-specific. For that, I wouldn't
have expected RFC4067 to have that.

Alper

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 30 Nov 2005 13:20:09 +0100

Hi alper, all,

> have expected RFC4067 to have that.

 yes you're right. So we have the following options:
 a/ let this as a preconfiguration task or reverse DNS

 b/ put the nPAA ID in the Context Data Block (CDB) with the PSA
 message in the CT-Req message. This would require adding some 
 TLVs in the CDB.
 
 another option is:
 c/ derive the key based on pPAA's identity.

---

From: Sasikanth Bharadwaj <[email-masked]>
Date: Wed, 30 Nov 2005 18:13:58 +0530

Hi

>  c/ derive the key based on pPAA's identity.
Using the nPAA's IP address instead of diameter id for key derivation is
another option.
I think the key has to be bound to some identifier corresponding to the nPAA
as well
and that is the reason why the diameter id was included.

Sasikanth

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 30 Nov 2005 17:26:25 +0200

I'd say "b".

Alper

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2005 2:20 PM
> To: Alper Yegin
> Cc: 'Julien Bournelle'; 'Vijayarajan'; [email-masked]
> Subject: Re: [Pana] DiameterIdentity of new PAA
indraft-ietf-pana-mobopts-
> 01.txt