Subject: RE: [Pana] issue85 (initial text)

From: Alper Yegin <[email-masked]>
Date: Tue, 13 Jul 2004 11:51:34 -0700

Yoshi,

I'd suggest to have a more generic PANA message, such as "PANA-Update".
Initially we can use this just to update the IP address of PaC. We can
evaluate other types of updates as need arises. What do you think?

Also, I didn't understand where Device-ID comes into the picture. When
do we update the device-ID?

I have some editorial comments as well. I'll wait for your response to
these first.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoshihiro Ohba
> Sent: Tuesday, May 18, 2004 6:51 PM
> To: [email-masked]
> Subject: [Pana] issue85 (initial text)
> 
> This is the initial text for issue 85.
> 
> Comments are appreciated.
> 
> ----------
> 
> 
> [1] Add the following item in section 4.1.1
> 
> "
>    o  IP-Address AVP: Conveys an IP-Address of a PaC.
> "
> 
> 
> [2] Add the following items in section 4.1.5:
> 
> "
>       *  IP address of PaC (may be the same as the Device-Id of PaC)
> 
>       *  IP address of PAA (may be the same as the Device-Id of PAA)
> "
> 
> 
> [3] Add the following item in section section 4.1.7:
> 
> "
>       When an IP-Address AVP is included, the AVP is valid if (i) the
>       Address type contained in the AVP matches the expected one
>       (i.e., either IPv4 or IPv6) that is used for the current PANA
>       session and (ii) the AVP value matches the one extracted from
>       the IP header.
> "
> 
> [4] Update the following paragraph of section 4.4
> 
> "
>    The second type of re-authentication is based on a single protected
>    message exchange without entering the authentication phase.
>    PANA-Reauth-Request and PANA-Reauth-Answer messages are used for
this
>    purpose.  If there is an established PANA SA, both the PaC and the
>    PAA are allowed to send a PANA-Reauth-Request message to the
>    communicating peer whenever it needs to make sure the availability
of
>    the PANA SA on the peer and expect the peer to return a PANA-
>    Reauth-Answer message.  Both PANA-Reauth-Request/
PANA-Reauth-Answer
>    messages MUST be protected with a MAC AVP.
> "
> 
> to:
> 
> "
>    The second type of re-authentication is based on a single protected
>    message exchange without entering the authentication phase.
>    PANA-Reauth-Request and PANA-Reauth-Answer messages are used for
>    this purpose.  If there is an established PANA SA, both the PaC and
>    the PAA are allowed to send a PANA-Reauth-Request message to the
>    communicating peer whenever it needs to make sure the availability
>    of the PANA SA on the peer and expect the peer to return a
>    PANA-Reauth-Answer message.  In this case, both
>    PANA-Reauth-Request/PANA-Reauth-Answer messages MUST be protected
>    with a MAC AVP.  If there is an established PANA session but
>    without an established PANA SA, both the PaC and the PAA are
>    allowed to send a PANA-Reauth-Request message to the communicating
>    peer whenever it needs to make sure the availability of the PANA
>    session on the peer and expect the peer to return a
>    PANA-Reauth-Answer message.  In this case, both
>    PANA-Reauth-Request/PANA-Reauth-Answer messages are not protected
>    with a MAC AVP.
> "
> 
> [5] Insert the following section after section 4.7:
> 
> "
> 4.8. Updating PaC's Address
> 
> A PaC's address can change in certain situations.  For example, the
> PANA framework [I-D.ietf-pana-framework] describes a case in which a
> PaC replaces a pre-PANA address (PRPA) a post-PANA address (POPA), and
> the PaC and PAA create host routes to each other in order to maintain
> on-link communication based on the POPA where the link-layer address
> of the PaC is used as the device identifier.  Also, a PaC's device
> identifier may change regardless of whether a link-layer address or an
> IP address is used as the device identifier.  As a result, it is
> possible when a link-layer address is used as the device identifier
> that both the device identifier and an IP address change.  In any
> case, the PAA needs to be notified about the change of address(es).
> 
> After the PaC has changed its address(es), it MUST send a
> PANA-Address-Update-Request message to the PAA.  The message carries
> the new address(es) in a Device-Id AVP and/or an IP-Address AVP.  At
> least one of these AVPs MUST appear in the request.  If an IP address
> is used as the device identifier, a Device-Id AVP MUST be used and an
> IP-Address AVP MUST NOT be used.  If an address contained in the
> request is invalid, the PAA sends a PANA-Error message with a result
> code PANA_INVALID_DEVICE_ID or PANA_INVALID_IP_ADDRESS depending on
> whether the device identifier or the IP address is invalid (in case
> both a Device-Id AVP and an IP-Address AVP are included and both are
> invalid, whichever result code is returned).  Otherwise, the PAA
> updates the address(es) of the PaC of the session attributes and
> returns a PANA-Address-Update-Answer message.  If there is an
> established PANA SA, both PANA-Address-Update-Request and
> PANA-Address-Update-Answer messages MUST be protected with a MAC AVP.
> "
> 
> [6] Change Figure 10 to:
> 
> "
>                  Message                     Direction:
>                                              PaC---PAA
>                  ----------------------------------------
>                  PANA-PAA-Discover           -------->
> 
>                  PANA-Start-Request          <--------
>                  PANA-Start-Answer           -------->
> 
>                  PANA-Auth-Request           <--------
>                  PANA-Auth-Answer            -------->
> 
>                  PANA-FirstAuth-End-Request  <--------
>                  PANA-FirstAuth-End-Answer   -------->
> 
>                  PANA-Bind-Request           <--------
>                  PANA-Bind-Answer            -------->
> 
>                  PANA-Reauth-Request         <------->
>                  PANA-Reauth-Answer          <------->
> 
>                  PANA-Termination-Request    <------->
>                  PANA-Termination-Answer     <------->
> 
>                  PANA-Address-Update-Request -------->
>                  PANA-Address-Update-Answer  <--------
> 
>                  PANA-Error                  <------->
> "
> 
> [7] Change sections 6.4.9 and 6.4.10 from:
> 
> "
> 6.4.9 PANA-Reauth-Request (PRAR)
> 
>    PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA.
> 
>          PANA-Reauth-Request ::= < PANA-Header: 5, REQ >
>                        < Session-Id >
>                        [ Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> 
> 6.4.10 PANA-Reauth-Answer (PRAA)
> 
>    PANA-Reauth-Answer (PRAA) is sent in response to a
>    PANA-Reauth-Request.
> 
>          PANA-Reauth-Answer ::= < PANA-Header: 5 >
>                        < Session-Id >
>                        [ Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> "
> 
> to:
> 
> "
> 6.4.9 PANA-Reauth-Request (PRAR)
> 
>    PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA.
> 
>          PANA-Reauth-Request ::= < PANA-Header: 5, REQ >
>                        < Session-Id >
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> 
> 6.4.10 PANA-Reauth-Answer (PRAA)
> 
>    PANA-Reauth-Answer (PRAA) is sent in response to a
>    PANA-Reauth-Request.
> 
>          PANA-Reauth-Answer ::= < PANA-Header: 5 >
>                        < Session-Id >
>                     *  [ AVP ]
>                    0*1 < MAC >
> "
> 
> [8] Add the following sections:
> 
> "
> 6.4.16 PANA-Address-Update-Request (PAUR)
> 
>    PANA-Address-Update-Request (PAUR) is sent by the PaC to the PAA.
> 
>          PANA-Address-Update-Request ::= < PANA-Header: 9, REQ >
>                        < Session-Id >
>                    0*1 { Device-Id }
>                    0*1 { IP-Address }
>                    0*1 < MAC >
> 
> 
> 6.4.17 PANA-Address-Update-Answer (PAUA)
> 
>    PANA-Address-Update-Answer (PAUA) is sent by the PAA to the PaC in
>    response to a PANA-Address-Update-Request.
> 
>          PANA-Address-Update-Answer ::= < PANA-Header: 9 >
>                        < Session-Id >
>                    0*1 < MAC >
> "
> 
> "
> 6.5.19 IP-Address AVP
> 
>    The IP-Address (AVP Code: 1041) contains an IP address of a PaC.
>    The payload format of the IP-Address AVP is the same as that of the
>    Device-Id AVP (see See section Section 6.5.2).  Address families
>    for IPv4 or IPv6 MUST be used for this AVP.
> "
> 
> 
> [9] Add the following result code in section 6.5.7.2:
> 
> "
>    PANA_INVALID_DEVICE_ID  5019
> 
>       Error code from PAA to PaC or from PaC to PAA.  This error is
>       returned in a PANA-Error message when the Device-Id AVP
>       contained in a received PANA-Bind-Request, PANA-Bind-Answer or
>       PANA-Address-Update-Request message is invalid.
> 
>    PANA_INVALID_IP_ADDRESS  5020
> 
>       Error code from PAA to PaC.  This error is returned in a
>       PANA-Error message when the IP-Address AVP in the received
>       PANA-Address-Update-Request message is invalid.
> 
> "
> 
> [10]  Modify the AVP occurrence table as:
> 
> "
>                           +-----------------------------------------+
>                           |        Message                          |
>                           |          Type                           |
>                           +-----+-----+-----+-----+-----+-----+-----+
>       Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
>       --------------------+-----+-----+-----+-----+-----+-----+-----+
>       Result-Code         |  0  |  0  |  0  |  0  |  1  |  1  |  0  |
>       Session-Id          |  0  | 0-1 |  1  |  1  |  1  |  1  | 0-1 |
>       Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
>       EAP-Payload         | 0-1 | 0-1 |  1  |  1  | 0-1 |  0  |  0  |
>       MAC                 |  0  | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
>       Nonce               |  0  | 0-1 |  0  |  0  | 0-1 |  0  |  0  |
>       Device-Id           |  0  |  0  |  0  |  0  | 0-1 | 0-1 |  0  |
>       Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
>       Protection-Cap.     | 0-1 |  0  |  0  |  0  | 0-1 |  0  |  0  |
>       PPAC                | 0-1 |  0  |  0  |  0  |  1  | 0-1 |  0  |
>       Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
>       Failed-AVP          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
>       ISP-Information     |  0+ | 0-1 |  0  |  0  |  0  |  0  |  0  |
>       NAP-Information     | 0-1 |  0  |  0  |  0  |  0  |  0  |  0  |
>       EP-Device-Id        |  0  |  0  |  0  |  0  |  0+ |  0  |  0  |
>       Key-Id              |  0  |  0  |  0  |  0  | 0-1 | 0-1 |  0  |
>       IP-Address          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
>       --------------------+-----+-----+-----+-----+-----+-----+-----+
> 
>                  Figure 11: AVP Occurrence Table (1/3)
> 
>
+---------------------------------------------+
>                           |      Message
|
>                           |       Type
|
+------+------+-----+-----+-----+------+------+
>       Attribute Name      | PRAR | PRAA | PTR | PTA | PER | PFER |
PFEA |
--------------------+------+------+-----+-----+-----+------+------+
>       Result-Code         |  0   |  0   |  0  |  0  |  1  |  1   |  0
|
>       Session-Id          |  1   |  1   |  1  |  1  |  1  |  1   |  1
|
>       Termination-Cause   |  0   |  0   |  1  |  0  |  0  |  0   |  0
|
>       EAP-Payload         |  0   |  0   |  0  |  0  |  0  |  1   |  0
|
>       MAC                 | 0-1  | 0-1  | 0-1 | 0-1 | 0-1 | 0-1  | 0-1
|
>       Nonce               |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Device-Id           |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Cookie              |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Protection-Cap.     |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       PPAC                |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Session-Lifetime    |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Failed-AVP          |  0   |  0   |  0  |  0  |  1  |  0   |  0
|
>       ISP-Information     |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       NAP-Information     |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       EP-Device-Id        |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
>       Key-Id              |  0   |  0   |  0  |  0  |  0  | 0-1  | 0-1
|
>       IP-Address          |  0   |  0   |  0  |  0  |  0  |  0   |  0
|
--------------------+------+------+-----+-----+-----+------+------+
> 
>                  Figure 12: AVP Occurrence Table (2/3)
> 
> 
>                           +-------------+
>                           |   Message   |
>                           |     Type    |
>                           +------+------+
>       Attribute Name      | PAUR | PAUA |
>       --------------------+------+------+
>       Result-Code         |  0   |  0   |
>       Session-Id          |  1   |  1   |
>       Termination-Cause   |  0   |  0   |
>       EAP-Payload         |  0   |  0   |
>       MAC                 | 0-1  | 0-1  |
>       Nonce               |  0   |  0   |
>       Device-Id           | 0-1  |  0   |
>       Cookie              |  0   |  0   |
>       Protection-Cap.     |  0   |  0   |
>       PPAC                |  0   |  0   |
>       Session-Lifetime    |  0   |  0   |
>       Failed-AVP          |  0   |  0   |
>       ISP-Information     |  0   |  0   |
>       NAP-Information     |  0   |  0   |
>       EP-Device-Id        |  0   |  0   |
>       Key-Id              |  0   |  0   |
>       IP-Address          | 0-1  |  0   |
>       --------------------+------+------+
> 
>                  Figure 13: AVP Occurrence Table (3/3)
> "
> 
> [11]  Change the text in section 7 from:
> 
> "
>          PANA-PAA-Discover (PDI)
>          PANA-Start-Request (PSR)*
>          PANA-Start-Answer (PSA)**
>          PANA-Bind-Request (PBR)
>          PANA-FirstAuth-End-Request (PFER)
>          PANA-Reauth-Request (PRAR)
>          PANA-Termination-Request (PTR)
> 
>          *)  PSR that carries a Cookie AVP is not retransmitted.
>          **) PSA that does not carry a Cookie AVP is not
retransmitted.
> "
> 
> to:
> 
> "
>          PANA-PAA-Discover (PDI)
>          PANA-Start-Request (PSR)*
>          PANA-Start-Answer (PSA)**
>          PANA-Bind-Request (PBR)
>          PANA-FirstAuth-End-Request (PFER)
>          PANA-Reauth-Request (PRAR)
>          PANA-Termination-Request (PTR)
>          PANA-Address-Update-Request (PAUR)
> 
>          *)  PSR that carries a Cookie AVP is not retransmitted.
>          **) PSA that does not carry a Cookie AVP is not
retransmitted.
> "
> 
> [12]  Add the folliwng text in section 8:
> 
> "
>    j) Updating PaC's address
> 
>    An attacker can generate a PANA-Address-Update-Request with an
>    invalid Device-Id AVP or an IP-Address AVP.  There are several
>    threats:
> 
>    - An attacker spoofs an address and registers itself with the
>    address.  If the registered address is not assigned to any PaC,
>    subsequent PANA messages sent from the PAA to the attacker will not
>    reach any node and this is not a significant harm.  If the
>    registered address is assigned to some PaC, subsequent PANA
>    messages sent from the PAA to the attacker will reach the PaC, but
>    will be silently discarded because the Session-Id is different.
> 
>    - An attacker registers other PaC with any address.  As a result,
>    subsequent PANA messages sent from the PAA to the PaC will not
>    reach the PaC.
> 
>    To avoid all those attacks against an address update, an additional
>    mechanism may be defined outside the PANA protocol for the PAA to
>    validate ownership of the address.
> "
> 
> 
> Best regards,
> 
> Yoshihiro Ohba
> 
> _______________________________________________
> 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: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jul 2004 15:39:43 -0400

> evaluate other types of updates as need arises. What do you think?

I think we can do that.

> do we update the device-ID?

- When an IP address is used as the device identifier, it can change
if the PaC configures its temporary link-local address based on RFC
3041 and the lifetime of the temporary address is expired.

- When a MAC address is used as the device identifer, it can change if
the PaC has multiple interfaces to the same link and switches from one
interface to another.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Jul 2004 13:19:38 -0700

Yoshi,

> 3041 and the lifetime of the temporary address is expired.

RFC3041 only deals with global addresses. The link-local addresses stay
the same (and it does not jeopardize the privacy).
 
> the PaC has multiple interfaces to the same link and switches from one

This is more like session migration from one network interface to
another. I think we can discuss that, but we need another issue in the
tracker. Issue 85 is concerned about change of PaC IP address from PRPA
to POPA.

Alper

|
|
|
|

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 09:28:23 -0400

Hi Alper,

> the same (and it does not jeopardize the privacy).

Do you assume two interface identifiers on the same interface (e.g.,
one derived from an IEEE identifier for link-local address and
one randomly generated identifier for global addresses)?

In case where only one interface identifier is used per interface (I
believe this is the typical case), if the interface identifier
changes, doesn't it mean that the link-local address also changes?

> tracker. Issue 85 is concerned about change of PaC IP address from PRPA

There is another case in which device-id update is needed.  In
draft-ietf-pana-framework-00.txt, Case D of IPv4 in Appendix A.1 and
Case C of IPv6 in Appendix A.2 use the device id update mechanism.
I once mentioned this:
http://www1.ietf.org/mail-archive/web/pana/current/msg00679.html

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jul 2004 12:42:36 -0700

> > > > Also, I didn't understand where Device-ID comes into the
picture.
> > When

I think this is possible.

> changes, doesn't it mean that the link-local address also changes?

I'm not sure if there is any requirement to have the same interface
identifier across all IPv6 addresses on the same physical interface.

> http://www1.ietf.org/mail-archive/web/pana/current/msg00679.html

These are in the Appendix because they rely on a secure DHCP scheme that
is not a standard. That's why I don't think they are sufficient to add
new things to the base protocol.

By the way, case C says:

      "... and that there is no need for
      additional PRAR-PRAA exchange to update the PaC-DI."

Alper

> 
> Yoshihiro Ohba
> 
> >
> > Alper
> >
> >
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > > >
> > > > I have some editorial comments as well. I'll wait for your
response
> > to
> > > > > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> > > > >       *  IP address of PaC (may be the same as the Device-Id
of
> > PaC)
> > > > >
> > > > >       *  IP address of PAA (may be the same as the Device-Id
of
> > PAA)
> > > > >       When an IP-Address AVP is included, the AVP is valid if
(i)
> > the
> > > > >    PANA-Reauth-Request and PANA-Reauth-Answer messages are
used
> > for
> > > > this
> > > > >    purpose.  If there is an established PANA SA, both the PaC
and
> > the
> > > > >    PANA-Reauth-Request and PANA-Reauth-Answer messages are
used
> > for
> > > > >    this purpose.  If there is an established PANA SA, both the
PaC
> > and
> > > > >    the PAA are allowed to send a PANA-Reauth-Request message
to
> > the
> > > > > A PaC's address can change in certain situations.  For
example,
> > the
> > > > > PANA framework [I-D.ietf-pana-framework] describes a case in
which
> > a
> > > > > PaC replaces a pre-PANA address (PRPA) a post-PANA address
(POPA),
> > and
> > > > > identifier may change regardless of whether a link-layer
address
> > or an
> > > > > the new address(es) in a Device-Id AVP and/or an IP-Address
AVP.
> > At
> > > > > is used as the device identifier, a Device-Id AVP MUST be used
and
> > an
> > > > > code PANA_INVALID_DEVICE_ID or PANA_INVALID_IP_ADDRESS
depending
> > on
> > > > > both a Device-Id AVP and an IP-Address AVP are included and
both
> > are
> > > > > PANA-Address-Update-Answer messages MUST be protected with a
MAC
> > AVP.
> > > > >    PANA-Address-Update-Request (PAUR) is sent by the PaC to
the
> > PAA.
> > > > >
> > > > >          PANA-Address-Update-Request ::= < PANA-Header: 9, REQ
>
> > > > >                        < Session-Id >
> > > > >                    0*1 { Device-Id }
> > > > >                    0*1 { IP-Address }
> > > > >                    0*1 < MAC >
> > > > >
> > > > >
> > > > >    PANA-Address-Update-Answer (PAUA) is sent by the PAA to the
PaC
> > in
> > > > >    The payload format of the IP-Address AVP is the same as
that of
> > the
> > > > >       Error code from PAA to PaC or from PaC to PAA.  This
error
> > is
> > > > >       contained in a received PANA-Bind-Request,
PANA-Bind-Answer
> > or
> > > > >       Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA
|
> > PDI |
> > > > >       Session-Id          |  0  | 0-1 |  1  |  1  |  1  |  1
|
> > 0-1 |
> > > > >       Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0
|  0
> > |
> > > > >       EAP-Payload         | 0-1 | 0-1 |  1  |  1  | 0-1 |  0
|  0
> > |
> > > > >       MAC                 |  0  | 0-1 | 0-1 | 0-1 | 0-1 | 0-1
|  0
> > |
> > > > >       Nonce               |  0  | 0-1 |  0  |  0  | 0-1 |  0
|  0
> > |
> > > > >       Device-Id           |  0  |  0  |  0  |  0  | 0-1 | 0-1
|  0
> > |
> > > > >       Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0
|  0
> > |
> > > > >       Protection-Cap.     | 0-1 |  0  |  0  |  0  | 0-1 |  0
|  0
> > |
> > > > >       PPAC                | 0-1 |  0  |  0  |  0  |  1  | 0-1
|  0
> > |
> > > > >       Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0
|  0
> > |
> > > > >       Failed-AVP          |  0  |  0  |  0  |  0  |  0  |  0
|  0
> > |
> > > > >       ISP-Information     |  0+ | 0-1 |  0  |  0  |  0  |  0
|  0
> > |
> > > > >       NAP-Information     | 0-1 |  0  |  0  |  0  |  0  |  0
|  0
> > |
> > > > >       EP-Device-Id        |  0  |  0  |  0  |  0  |  0+ |  0
|  0
> > |
> > > > >       Key-Id              |  0  |  0  |  0  |  0  | 0-1 | 0-1
|  0
> > > > >       Result-Code         |  0   |  0   |  0  |  0  |  1  |  1
|
> > 0
> > > > |
> > > > >       Session-Id          |  1   |  1   |  1  |  1  |  1  |  1
|
> > 1
> > > > |
> > > > >       Termination-Cause   |  0   |  0   |  1  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       EAP-Payload         |  0   |  0   |  0  |  0  |  0  |  1
|
> > 0
> > > > |
> > > > >       MAC                 | 0-1  | 0-1  | 0-1 | 0-1 | 0-1 |
0-1  |
> > 0-1
> > > > |
> > > > >       Nonce               |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Device-Id           |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Cookie              |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Protection-Cap.     |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       PPAC                |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Session-Lifetime    |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Failed-AVP          |  0   |  0   |  0  |  0  |  1  |  0
|
> > 0
> > > > |
> > > > >       ISP-Information     |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       NAP-Information     |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       EP-Device-Id        |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > |
> > > > >       Key-Id              |  0   |  0   |  0  |  0  |  0  |
0-1  |
> > 0-1
> > > > |
> > > > >       IP-Address          |  0   |  0   |  0  |  0  |  0  |  0
|
> > 0
> > > > >    subsequent PANA messages sent from the PAA to the attacker
will
> > not
> > > > >    messages sent from the PAA to the attacker will reach the
PaC,
> > but
> > > > >    mechanism may be defined outside the PANA protocol for the
PAA
> > to

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 18:20:50 -0400

> I think this is possible.

I think so.

> identifier across all IPv6 addresses on the same physical interface.

I don't think there is such a requirement.  But should we mandate the
use of multiple interface identifiers to support RFC 3041 with PANA?
If so, I think we should explicitly mention this in the framework
document.

>       additional PRAR-PRAA exchange to update the PaC-DI."

The text is correct.  Figure 20 in the framework draft contains a bug.  I
will fix it.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jul 2004 16:40:42 -0700

> If so, I think we should explicitly mention this in the framework

This mandate is not arising from PANA, but this is an unstated
assumption in RFC3041. The RFC is specifically about changing
global-scope (and now-deprecated site-locals), nothing to do with the
link-locals. Hence the use of different interface identifiers is
inherent to RFC3041. I don't think we should do anything on that in PANA
documents.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 11:37:48 -0400

Hi Alper,

I double checked this with KAME implementation and you are right.  I
agree that the device identifier update is probably not needed for
usual cases.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jul 2004 16:06:10 -0700

My comments on the proposed text are below....

>       session and (ii) the AVP value matches the one extracted from

I think (i) and (ii) are over-constraining, and not sure about their
value. (ii) seems to achieve some kind of verification, but the PaC can
always spoof the IP source address anyways.  

this
of
PANA-Reauth-Answer
>    PANA-Reauth-Request/PANA-Reauth-Answer messages are not protected

I have a proposed text for this, which I think saves space:

"
   The second type of re-authentication is based on a single protected
   message exchange without entering the authentication phase.
   PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this
   purpose.  If there is an established PANA session, both the PaC and
the
   PAA are allowed to send a PANA-Reauth-Request message to the
   communicating peer whenever they need to make sure the availability
of
   the session on the peer and expect the peer to return a PANA-
   Reauth-Answer message.  Both PANA-Reauth-Request/ PANA-Reauth-Answer
   messages MUST be protected with a MAC AVP when a PANA SA is
available.
"

So I think this is a test to see the availability of the matching
session on the peer. And it must be cryptographically protected when
possible. [Actually, I might even recommend we rename this type of usage
as PANA-ping or something. Though we can tackle this while resolving
issue 105.]

> PANA-Address-Update-Answer messages MUST be protected with a MAC AVP.

Removing the "update of DI" from the above text and some other
editorials:

 A PaC's IP address can change in certain situations.  For example, the
 PANA framework [I-D.ietf-pana-framework] describes a case in which a
 PaC replaces a pre-PANA address (PRPA) with a post-PANA address (POPA),
and
 the PaC and PAA create host routes to each other in order to maintain
 on-link communication based on the POPA. The PAA needs to be notified 
 about the change of PaC address.
 
 After the PaC has changed its address, it MUST send a
 PANA-Update-Request message to the PAA.  The message MUST carry
 the new PaC address in an IP-Address AVP. If the address contained in
the
 request is invalid, the PAA MUST send a PANA-Error message with the
result
 code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST
 update the PANA session with the new PaC address 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 a MAC AVP.
 "

>                                              PaC---PAA

                 PANA-Update-Request -------->
                 PANA-Update-Answer  <--------

> 6.4.16 PANA-Address-Update-Request (PAUR)

just renaming to PUR and removing DI part.

6.4.16 PANA-Update-Request (PUR)

    PANA-Update-Request (PUR) is sent by the PaC to the PAA.
 
          PANA-Update-Request ::= < PANA-Header: 9, REQ >
                        < Session-Id >
                        < IP-Address >
                    0*1 < MAC >

6.4.17 PANA-Update-Answer (PUA)
 
    PANA-Update-Answer (PAUA) is sent by the PAA to the PaC in
    response to a PANA-Update-Request.
 
          PANA-Update-Answer ::= < PANA-Header: 9 >
                        < Session-Id >
                    0*1 < MAC >
 "
> [9] Add the following result code in section 6.5.7.2:

I think we can remove the DI part here.

>    PANA_INVALID_IP_ADDRESS  5020

And this becomes 5019.

>       PANA-Address-Update-Request message is invalid.

We can add "(e.g., a non-unicast address)."

|
|
PFEA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>                  Figure 12: AVP Occurrence Table (2/3)

 PUR and PUA.

Device-Id 0 0

>       NAP-Information     |  0   |  0   |

IP-Address 1 0

retransmitted.
>          PANA-Address-Update-Request (PAUR)

PUR

retransmitted.
>    invalid Device-Id AVP or an IP-Address AVP.  There are several

remove "invalid Device-Id AVP or".

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 19:47:34 -0400

> always spoof the IP source address anyways.  

Yes, (ii) cannot prevent source address spoofing, thus I agree that 
(ii) might not be needed.

For (i), is there any valid case where IP-Address AVP with IPv4(v6) 
is contained while PANA runs over IPv6(v4)?

I agree on the rest of your suggestions.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jul 2004 17:11:26 -0700

> is contained while PANA runs over IPv6(v4)?

I see it this way:
- Can PANA session start on IPv4(v6) and than switch to IPv6(v4) after
successful PANA authentication?

I couldn't find a solid scenario to back up the need for this. But on
the other hand I couldn't see the benefit of constraining this, or the
cost of relaxing either...

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 20:33:20 -0400

> cost of relaxing either...

OK, I can live with also removing (i) until this case is determined to
be an error case without exception, given that this becomes a new PANA
issue.

Yoshihiro Ohba