Subject: [Pana] Issue 159: Enable multi-hop PANA support (Take 2)

From: Alper Yegin <[email-masked]>
Date: Mon, 02 May 2005 13:26:45 -0700

http://danforsberg.info:8080/pana-issues/issue159

Incorporating the changes from earlier discussions....

Proposed change highlights:

New updates in Take 2:

- Use admin-scoped mcast for discovery
- Remove IP Address AVP

Others from Take 1:

- Fix the PAA discovery
- Remove TTL checks
- Remove integrity checks comparing L2/L3 headers with PANA payloads
- Remove PAA's IP address sent by the PAA
- Make UDP port selection NAT-friendly.
- State PaC device ID has to be an IP address when EP is off-link.

Here is the proposed text, comments welcome:

[1] Section 4.1

Remove

  o  IP-Address AVP: contains an IP Address of the PaC.

[2] Section 4.2

New text for the first 3 paragraphs:

When a PaC attaches to a network, and it does not already know the IP
address of the PAA, it MUST rely on dynamic discovery methods,
such as a multicast-based and a traffic-driven discovery. 

The PaCs and PAAs MUST implement multicast-based discovery where the
PaC sends a PANA-PAA-Discover message to a well-known 
administratively scoped multicast address (TBD) and UDP port (TBD). 

The network administrator MUST configure the multicast scope such that
the discovery messages can reach only the designated PAA(s). In 
case the PAA(s) is on the same link as the PaC, the administratively 
scoped multicast messages MUST not be forwarded by the routers. Details 
of scope configuration are discussed in [RFC2365].

The PAA(s) that receive the discovery message MUST respond with a
unicast 

PANA-Start-Request message sent to the soliciting PaC.

Alternatively, the PaC MAY also choose to start sending data packets 
before getting authenticated. The EP in an access network that 
implements PANA SHOULD drop such unauthorized packets upon receipt. 
Additionally, the EP MAY also take this traffic as an indication of 
unauthorized PaC and notify the PAA. The EP-to-PAA notification
SHOULD be sent via [I-D.ietf-pana-snmp]. In response, the PAA SHOULD 
send an unsolicited PANA-Start-Request message to the PaC. This is
called
traffic-driven PAA discovery (an alternative to the PaC explicitly
soliciting for a PAA). Deployment of this alternate scheme is optional.

The EP-to-PAA notification MAY also be generated in response to
receiving a link-up event notification on the EP 
[I-D.ietf-dna-link-information].

Alternative PAA discovery schemes may be designed (e.g., DHCP-based)
but they are outside the scope of this specification.

If the PaC knows the IP address of the PAA, it can send a unicast 
PANA-PAA-Discover message and initiate the PANA exchange.

[3] Figure 4: remove "IP-Address" AVP sent by the PAA.

[4] Section 4.3

Replace

The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
also used for binding device identifiers of the PaC and EP(s), and
the IP address of the PAA to the PANA SA. To achieve this, the
PANA-Bind-Request message MUST contain the device identifier in a
Device-Id AVP for each EP if a Protection-Capability AVP is included
in the message. Otherwise, the message SHOULD contain the device
identifier in a Device-Id AVP for each EP when a link-layer or IP
address is used as the device identifier of the PaC. The
PANA-Bind-Request message MUST also contain the IP address of the PAA
in an IP-Address AVP. 

With

The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
also used for binding device identifiers of the PaC and EP(s)to the 
PANA SA. To achieve this, the PANA-Bind-Request message MUST contain

the device identifier in a Device-Id AVP for each EP if a 
Protection-Capability AVP is included in the message. Otherwise, the

message SHOULD contain the device identifier in a Device-Id AVP for 
each EP when a link-layer or IP address is used as the device
identifier 
of the PaC. 

[5] Figure 7: remove "IP-Address" AVP sent by the PAA.

[6] Section 5.3

Replace

* IP address of PaC (may be the same as the Device-Id of PaC when
IP address is used as the device identifier)

With

* IP address and UDP port number of the PaC

[7] Section 5.5

Remove:

o The IP Hop Limit (or TTL) field has a value of 255, i.e., the
packet could not possibly have been forwarded by a router.

[8] Section 5.5

Replace

o When a Device-Id AVP is included, the AVP is valid if the device
identifier type contained in the AVP is supported (check performed
by both the PaC and the PAA) and is the requested one (check
performed by the PAA only) and the device identifier value
contained in the AVP matches the value extracted from the
lower-layer encapsulation header corresponding to the device
identifier type contained in the AVP (check performed by the PAA
only). Note that a Device-Id AVP carries the device identifier of
the PaC in messages from the PaC to the PAA and the device
identifier(s) of the EP(s) in messages from the PAA to the PaC.

With

o When a Device-Id AVP is included, the AVP is valid if the device
identifier type contained in the AVP is supported (check performed
by both the PaC and the PAA) and is the requested one (check
performed by the PAA only). Note that a Device-Id AVP carries 
the device identifier of the PaC in messages from the PaC to the
PAA and the device identifier(s) of the EP(s) in messages from the 
PAA to the PaC.

[9] Section 5.5

Remove

o When an IP-Address AVP is received in a message, the AVP is valid
if the IP address matches the source address in the IP header.

[10] Section 5.6

Replace

It is assumed that the PAA knows the link type and the security
mechanisms being provided or required on the access network (e.g.,
based on physical security, link-layer ciphers enabled before or
after PANA, or IPsec). Based on that information, the PAA can decide
what type of EP device id will be used when running PANA with the
client. When IPsec-based security [I-D.ietf-pana-ipsec] is the
choice of access control, the PAA SHOULD provide IP address(es) as
EP(s)' device ID, and expect the PaC to provide its IP address in
return. In case IPsec is not used, MAC addresses are used as device
identifiers when available. If non-IPsec access control is enabled,
and a MAC address is not available, device ID exchange does not occur
within PANA. Instead, peers rely on lower-layers to provide
locally-significant identifiers along with received PANA messages.

With

It is assumed that the PAA knows the link type and the security
mechanisms being provided or required on the access network (e.g.,
based on physical security, link-layer ciphers enabled before or
after PANA, or IPsec). Based on that information, the PAA can decide
what type of EP device id will be used when running PANA with the
client. 

When IPsec-based security [I-D.ietf-pana-ipsec] is the
choice of access control, the PAA SHOULD provide IP address(es) as
EP(s)' device ID, and expect the PaC to provide its IP address in
return. Similarly, IP addresses are used when the EP(s) is not 
on the same IP subnet as the PaC is.

In other cases, MAC addresses are used as device identifiers when 
they are available. 

If non-IPsec access control is enabled, and a MAC address is not 
available, locally-significant identifiers (e.g., as a circuit id) 
MUST be used as device id. Note that these identifiers are not
exchanged within PANA messages. Instead, peers rely on lower-layers 
to provide them along with received PANA messages.

[11] Section 5.7

New text for the section

   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). In order to establish reachability, 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 PAA MUST update
   the PANA session with the new PaC address (source IP 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.

[12] Section 6.1

Remove

The Hop Limit (or TTL) field of the IP header MUST be set to 255.

Replace

   When a PANA-PAA-Discover message is multicast, IP destination address
   of the message is set to a well-known link-local multicast address
   (TBD). 

With

   When a PANA-PAA-Discover message is multicast, IP destination address
   of the message is set to a well-known administratively scoped 
   multicast address (TBD).

[13] Section 6.1

Replace all occurrences of "PANA packet" with "PANA message"

[14] Section 6.1

Replace

When the PANA packet is sent in response to a request, the UDP source
and destination ports of the response packet MUST be copied from the
destination and source ports of the request packet, respectively.
The destination port of an unsolicited PANA packet MUST be set to an
assigned value (TBD), and the source port MUST be set to a value
chosen by the sender.

With

When the PANA message is sent in response to a request, the UDP
source and destination ports of the response message MUST be copied 
from the destination and source ports of the request message, 
respectively.

The source port of an unsolicited PANA message MUST be set to a value
chosen by the sender. The destination port MUST be set to the peer's
port number if it has already been discovered via earlier PANA
exchanges, set to the assigned PANA port (TBD) otherwise.

[15] Section 7.2.8

Remove "{IP-Address}" from message format

[16] Section 7.2.18

New text for the section

   The PANA-Update-Request (PUR) message is sent either by the PaC or
   the PAA to deliver attribute updates and notifications. In the scope
   of this specification only the PaC IP address can be
   updated via this mechanism.

         PANA-Update-Request ::= < PANA-Header: 10, REQ >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

[17] Figure 10: Set PBR to 0 for IP-Address AVP

[18] Section 7.3.5

Remove this section completely.

[19] Section 7.3.16

Remove 

PANA_INVALID_IP_ADDRESS  5018

      This error is returned in a PANA-Error-Request message when the
      IP-Address AVP in the received PANA-Update-Request message is
      invalid (e.g., a non-unicast address).  Only the PAA can generate
      this code.

[20] Section 9.2

New text for the section

   PANA uses one well-known administratively scoped IPv4 multicast
address,
   and one well-known administratively scoped IPv6 multicast address 
   (Section 4.2 and Section 6.1), which need to be assigned by the IANA.

[21] Section 10.1

Remove

Since the PaC and PAA are on the same IP link, a simple TTL check on
the received PANA messages prevents off-link attacks.

[22] Section 10.9

New text for the section

   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.

[23] Figure 10, 11

Remove "IP-Address AVP" from these tables.

[24] Figure 12: remove "IP-Address" AVP sent by the PAA.

[25] Add to the normative references:

RFC2365

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 05 May 2005 14:46:42 -0400

Hi Alper,

The new text looks good.

Regards,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 06 May 2005 12:48:35 +0200

Hi Alper ... a short comment

In section 4.2

Cookie =

        <secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )

and text also says:"
The
   device identifier of the PaC can be extracted from a link-layer or IP
   header of PANA messages."

In case EP is a L2 device, PAA cannot know PaC's link-layer (DI would be 
MAC address)  in a multi-hop case. In fact DI would not be sent to PAA 
until PBA message and therefore it woud not be possible to calculate 
cookie following these instructions.

Maybe cookie could be generated by using PaC's IP address instead.

Comments?.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Fri, 06 May 2005 13:18:36 -0700

Rafa,

Sure. Note that this is just an example. It may not be applicable to all
deployments. There can be other ways to produce the cookie value. How it
is produced does not impact interoperability.

Alper

> -----Original Message-----
> From: Rafa Marin Lopez [mailto:[email-masked]]
> Sent: Friday, May 06, 2005 3:49 AM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [Pana] Issue 159: Enable multi-hop PANA support (Take 2)
>