Re: [Pana] Re: review pana spec

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

On Thu, Nov 30, 2006 at 10:20:57AM -0800, Mohan Parthasarathy wrote:
> Hi Yoshi,
> 
> the draft looks pretty good. I mainly went through the differences. Here are my comments. 
> 
> - Abstract calls it "link-layer" agnostic where as in the Introduction, there is
>   "minimum" link-layer dependency. Having gone through this discussion many
>   times it might be better to remove both these terms to avoid lengthy discussions :-)

For Abstract, we can replace "link-layer agnostic transport" with 
"network layer transport".  For Introduction we can remove 
"minimum link-layer dependency".

> 
> -Why isn't Key-Id included in the PANA-AUTH-KEY ? If you have multiple MSKs, isn't there
>   multiple PANA SAs and hence the Key-Id should be included ?

Thank you for pointing this out.  You are right, Key-Id needs to be 
included.  We can revise the text to:

"
  PANA_AUTH_KEY = prf+(MSK, PaC_nonce | PAA_nonce | Session_ID | Key_ID)

   where the prf+ function is defined in IKEv2 [RFC4306].  The pseudo-
   random function to be used for the prf+ function is specified in the
   Algorithm AVP in a PANA-Bind-Request message.  The length of
   PANA_AUTH_KEY depends on the integrity algorithm in use.  See
   Section 5.4 for the detailed usage of the PANA_AUTH_KEY.  PaC_nonce
   and PAA_nonce are values of the Nonce AVP carried in the first PANA-
   Auth-Answer and PANA-Auth-Request messages in the authentication and
   authorization phase or the re-authentication phase, respectively.
   Session_ID is the session identifier of the session.  Key_ID is the
   value of the Key-ID AVP.
"

> -Section 5.6 " Pac Updating its IP addresses" : Is this needed for basic operation of PANA ?
>  The example given in the section makes me believe that it is not required. But it is required
>  depending on what IP address you start with. Hence, some clarification is required.

Perhaps what we need to say is that PaC needs to update its IP address
*used for PANA*.  (We don't need to say which IP address is used for
PANA, which may be described by deployment-specific PANA applicability
documents.)

Here is revised text for Section 5.6 (also reflecting Alper's
comment):

"
5.6.  PaC Updating its IP Address

   A PaC's IP address used for PANA can change in certain situations,
   e.g., when the PaC moves from one IP link to another within the
   same PAA's realm.  In order to maintain the PANA session, the PAA
   needs to be notified about the change of PaC address.  In order to
   maintain the PANA session, the PAA needs to be notified about the
   change of the IP address of the PaC.

   After the PaC has changed its IP address used for PANA, it MUST
   send a PANA-Update-Request message to the PAA.  The PAA MUST update
   the PANA session with the new PaC address carried in the Source
   Address field of the IP header and return a PANA-Update-Answer
   message.  If there is an established PANA SA, both
   PANA-Update-Request and PANA-Update-Answer messages MUST be
   protected with an AUTH AVP.
"

> 
> -In the Security considerations, 
>    11.8.  IP Address Spoofing
> 
>             There is no way to prove the ownership of the IP address presented by
>             the PaC.  Hence an authorized PaC can launch a redirect attack by
>             spoofing a victim's IP address.
> 
>   the first sentence is worded in such a way that there is no way to do it. But if SEND
>   is deployed in access networks, then it should be possible. Sure, PANA by itself
>   cannot do it.

You are right.  Also, an unauthorized PaC as well as authorized PaC
can launch the attack.  How about the following text?

"
11.8.  IP Address Spoofing

   Without use of SEND (SEcure Neighbor Discovery [RFC 3971], there is
   no way to prove the ownership of the IP address presented by
   the PaC.  Hence an attacker can launch a redirect attack by
   spoofing a victim's IP address.  It is RECOMMENDED to use SEND to
   avoid such an attack.
"

Regards,
Yoshihiro Ohba


> 
> 
> 
> -mohan
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> > Sent: Sunday, November 19, 2006 10:39 AM
> > To: pana at ietf.org
> > Subject: [Pana] Preliminary pana-pana draft (13a)
> > 
> > is available at:
> > 
> > http://www.panasec.org/docs/editing/pana-spec.html
> > 
> > (Now we get 17 pages reduction.)
> > 
> > Please do sanity check to make sure that all resolutions discussed in
> > IETF67 and over mailing list are reflected appropriately.  Diff from
> > revision 12 is also available.
> > 
> > As soon as sanity check is done, I will submit a new revision (13)
> > which is to be used for IETF last call.
> > 
> > Regards,
> > Yoshihiro Ohba
> > 
> > _______________________________________________
> > 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