Subject: [Pana] Issue 159: Enable multi-hop PANA support (update base specification)

From: Alper Yegin <[email-masked]>
Date: Mon, 04 Apr 2005 14:02:32 -0700

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

Proposed change highlights:

- 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.

Discussion:

In the proposed text, I stuck with link-scoped mcast discovery even for
handling the off-link PAAs. That can work by relying on on-link EP
detecting link-scoped mcast and triggering the PAA via EP-to-PAA
interface (our standard "traffic-driven discovery"). Though that is what
we discussed at IETF, I realized another approach is to replace
"link-scoped mcast" by "admin-scoped mcast", letting the probes reach
wherever the PAA is located. Any comments on this approach?

Here is the proposed text, comments welcome:

[1] 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 link
   local multicast address (TBD) and UDP port (TBD). The PAAs on the
same 
   link as the PaC 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).  

   Traffic-driven discovery SHOULD be deployed when the PAA is located
   multiple IP hops away from the PaCs. Since the link-scoped multicast 
   discovery messages cannot reach the target PAA, the deployment SHOULD

   rely on EPs being triggered by the PANA-PAA-Discover messages to
notify 
   the PAA. This scheme MAY be optionally deployed in networks where the
PAA 
   is on the same link as the PaCs. 

   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.

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

[3] 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.  

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

[5] 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

[6] 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.

[7] 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.

[8] 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.

[9] 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.

[10] Section 6.1

Remove

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

[11] Section 6.1

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

[12] 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.

[13] Section 7.2.8

Remove "{IP-Address}" from message format

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

[15] Section 7.3.5

Replace

   The IP-Address AVP (AVP Code 5) contains an IP address of the PaC or
   PAA.  When it is sent by the PaC, it is used to convey the new IP
   address of the PaC to the PAA when the PaC reconfigures its IP
   address after the successful PANA authentication.  This AVP is not
   used if the PaC's IP address used during the authentication and
   authorization phase is still valid.  It is sent by the PAA in
   PANA-Bind-Request to bind the IP address of the PAA to the PANA
   session.  The payload format of the IP-Address AVP is the same as
   that of the Device-Id AVP (see See Section 7.3.2).  Address families
   for IPv4 or IPv6 MUST be used for this AVP.

With

   The IP-Address AVP (AVP Code 5) contains an IP address of the PaC.  
   It is used to convey the new IP address of the PaC to the PAA when
the 
   PaC reconfigures its IP address after the successful PANA
authentication.  
   This AVP is not used if the PaC's IP address used during the 
   authentication and authorization phase is still valid.  The payload 
   format of the IP-Address AVP is the same as that of the Device-Id AVP
   (see See Section 7.3.2).  Address families for IPv4 or IPv6 MUST be 
   used for this AVP.

[16] 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.

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

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 13 Apr 2005 02:34:09 -0400

Hi Alper,

Please see my comments in line.

> wherever the PAA is located. Any comments on this approach?

I think admin-scoped multicast can create a management issue when
there are multiple PAAs in the same administrative scope and if the
PAAs are not managing the same set of EPs.  In other words, it might
be difficult to define an administrative scope and control multicast
packet routing for the admin-scoped multicast PANA messages to reach
the defined scope only.

On the other hand, it might not be a good if we define PANA multihop
in a way that the PaC has to rely on traffic-driven discovery to
capture link-local multicast at EP, because this means that it
requires more complexity at the EP and that requirement might to be
too much if the EP is implemented on a wireless LAN AP.

I am wondering if we could always rely on DHCP-based PAA discovery for
discoverying off-link PAAs instead of relying on either one of the
above two approaches.

This is also my comment on the proposed text [1].

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

OK.

>    each EP when a link-layer or IP address is used as the device

OK.

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

OK.

>       *  IP address and UDP port number of the PaC

OK.

>       packet could not possibly have been forwarded by a router.

OK.

>       and the device identifier(s) of the EP(s) in messages from the PAA

OK.

>       if the IP address matches the source address in the IP header.

I think this IP address check still works for multihop PANA and is
doable using unix socket programming.  Thus I think we can still keep
this check in the spec.

>    return.  similarly, IP addresses are used when the EP(s) is not 

"similary" -> "Similary".

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

OK.

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

OK.

>    exchanges, set to the assigned PANA port (TBD) otherwise.

OK.

> Remove "{IP-Address}" from message format

OK.

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

OK.

>    (see See Section 7.3.2).  Address families for IPv4 or IPv6 MUST be 

OK.

>    the received PANA messages prevents off-link attacks.

OK.

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

OK.

Regards,
Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 14 Apr 2005 16:41:46 -0700

Hi Yoshi,

Thank you for the feedback.

> > Though that is what
> > "link-scoped mcast" by "admin-scoped mcast", letting the probes 
> > reach wherever the PAA is located. Any comments on this approach?
> 

> discoverying off-link PAAs instead of relying on either one of the 

I think we can still provide admin-scoped mcast-based discovery in the
base spec. If there are some deployments that rather use DHCP, they can
always do that. But for other mostly straight forward deployments, mcast
can be the solution. Comments?

> doable using unix socket programming.  Thus I think we can still keep 

Even though Unix socket interface can get you this info, we still have
the other two issues which suggested removal of this check:
- If the PaC is behind a NAT, this check will automatically fail. 
- Still this is trying to solve another problem -- IP address ownership.

Regards

Alper

> >    It is used to convey the new IP address of the PaC to the PAA 
> > when the

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 20 Apr 2005 15:02:13 -0400

> can be the solution. Comments?

Is there other protocol that uses admin-scoped multicast based
discovery?

> - Still this is trying to solve another problem -- IP address ownership.

OK.  Now I think IP-Address AVP does not need to be carried in PUR
message at all because the PAA can know whether the PUR is for IP
address update by just checking the source IP address of the PUR.

What do you think?

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 21 Apr 2005 14:16:02 +0200

Hi Alper... a short question...

>- State PaC device ID has to be an IP address when EP is off-link.
is there no any problem when L2 security wants to be bootstrapped?
Regards.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Apr 2005 11:34:47 -0400

> can be the solution. Comments?

Another issue is that the PaC does not know whether the PAA is located
in the access network or beyond the access network.  Which multicast
address should the PaC use at the very beginning when it wants to
discover the PAA, link-local or admin-scoped one?  If admin-scoped
multicast is expected to work regardless of the location of the PAA,
can we rely on admin-scoped multicast without link-local multicast at
all?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Apr 2005 14:04:58 -0700

Rafa,

> is there no any problem when L2 security wants to be bootstrapped?

Do you see a problem? Let us know...

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 22 Apr 2005 02:42:44 +0200

Hi Alper...

>Do you see a problem? Let us know...
Sorry, I misread this sentence. If EP is off-link PaC device ID = IP 
address. Agree.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Apr 2005 17:56:30 -0700

>From http://www.iana.org/assignments/multicast-addresses:

There is a concept of relative addresses to be used with the scoped
multicast addresses.  These relative addresses are listed here:

Relative     Description                                       Reference
---------    ------------------------------------------------- ---------
  0          SAP Session Announcement Protocol                 [Handley]
  1          MADCAP Protocol                                   [RFC2730]
  2	       SLPv2 Discovery
[Guttman]
  3          MZAP
[Thaler]
  4	       Multicast Discovery of DNS Services
[Manning]
  5	       SSDP
[Goland]
  6	       DHCP v4
[Hall]
  7          AAP
[Hanna]
  8          MBUS                                              [RFC3259]

> address update by just checking the source IP address of the PUR.

It makes sense to me. We can remove IP-Address AVP completely from the
spec.

> can we rely on admin-scoped multicast without link-local multicast at

What I'm proposing is to use an admin-scoped mcast address "only". If
the PAA is on the same subnet as the PaCs, then the admin shall
configure the routers such that PANA admin-scoped mcast address is not
used beyond that subnet (effectively, using it like a link-local mcast
for those deployments).

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Apr 2005 13:19:41 -0400

> Relative     Description                                       Reference

Thank you for the information.  Now I don't see a problem except that
each router in the administrative domain needs to be carefully
configured in a way that PAAs outside the administrative boundary are
not mistakenly discovered (deployment issue).  But this is not a
protocol issue and I am ok with the use of admin-scoped multicast.

> It makes sense to me. We can remove IP-Address AVP completely from the

This is good.

OK.  

Next issue is that when the PaC does not know whether the PAA is
located in the access network or beyond the access network, I think
the PaC should use a non-link-local address as PRPA if it has such an
address before running PANA.  This is because if a link-local address
is used as PRPA, the PAA discovery with admin-scople mcast will fail
if the PAA is multiple hops away from the PaC.

What do you think?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Apr 2005 15:26:54 -0700

> if the PAA is multiple hops away from the PaC.

Yes.

An IPv4 PaC would not have both a LL and global address at the same
time. So, there is no "selection" issue.
 
We can have an explicit statement for IPv6 case, but even without that a
host implementation would not use a link-local address for anything
other than specific link-scoped actions (e.g., ND). I think RFC 3484
supports the desired selection too.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Apr 2005 18:45:29 -0400

> time. So, there is no "selection" issue.

Sure.

> supports the desired selection too.

Does this mean IPv6 PaC always needs a non-link-local address to
discover a PAA using admin-scoped multicast, even if the PAA is
actually on the same link?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Apr 2005 16:26:03 -0700

> actually on the same link?

No.... I just meant to say "if the PaC has both a link-local and a
global scoped address, it'd automatically use the global address as
PRPA." And I had already stated that a network that deploys off-link PAA
must allow configuration of a global IPv6 address on the PaC prior to
PANA.

Alper