Subject: [Pana] Multi-hop PANA

From: [email-masked]
Date: Wed, 8 Dec 2004 17:44:09 +0200

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 04 December, 2004 04:19
> To: [email-masked]
> Cc: Forsberg Dan (Nokia-NRC/Helsinki)
> Subject: Multi-hop PANA ( was RE: [issue138]: Requirement for one hop
> away relation to PAA discovery)
> 
> 
> 
> Basavaraj and I discussed this and here's our recommendation.
> 
> The current protocol design is based on the charter and protocol
> requirements (a framework). Our #1 objective is expedited
> standardization of PANA within this framework. We shall stay away
> from deviations that are likely to cause unnecessary delay to this
> process, especially this late in the game.
> 
> Having said that, there is a value in being able to run multi-hop
> PANA.  The question is, can we attain that value with minimum impact
> on the protocol and its standardization.
> 
> We need to assess the cost of relaxing the 1-hop requirement on the
> protocol design and the process (timeline). Than we can decide
> whether we consider this change before pushing the protocol design
> to IESG, or save it for later.
> 
> WG needs to come up with an analysis that enumerates the changes
> required to the protocol, and their impact (security, deployment,
> etc.).  Dan, can you please drive this discussion on the PANA ML
> (i.e., no design team) and produce a summary (a short write-up)?

Yes, I can do that.

> Couple important points:
> - This activity (analysis) should take place in parallel with the
> current work. No holding up the documents or anything like that.
> - In fact, we should finish this in one week! If it takes longer than
> that, that's an indication that the changes may not be that trivial. 
> - We'll only be discussing the multi-hop issue. This is not a free
> ticket for revising any other requirement. 
> - The default is we stick to the current framework and move on. Let's
> not get too excited about multi-hop PANA and drag this too long ;-)

Agreed.

So here are just couple of things to get going. 

There is an old issue (12) about multi-hope PANA. It also suggests
some improvements to the PAA discovery process.
http://danforsberg.info:8080/pana-issues/issue12

Some alternatives for the discovery problem: 

(a) rely on the existing EP-to-PAA notification, i.e. allow multi-hop
    PANA, but do not define a discovery mechanism for PAA further than
    on hop away from PaC.

(b) use PAA proxy on the EP or first hop router.

(c) from the issue 12: PAA on the data path and use router alert
    option (RFC2113) to inform PaC.

On example scenario, where multi-hop PAA would be suitable (figure
from issue12).

  +---------------------------------+        +--------//
  |  Network with untrusted nodes   |        | NAP/ISP
  |                +---------+      |      +-+--------+
  |          +-----+  Node 2 +------+///-->+   PAA    +-//
  |          |     +---------+      |      +-+--------+
  |      +---+-----+                |        |
  |      |  Node 1 |                |        |
  |      +---------+                |        |
  |          ^                      |        |
  +----------+----------------------+        +--------//
             |
          +--+---+
          | PaC  |
          +------+

Another one:
 
              +-----+           +----------------+
              |AP/EP|----+      | PAA/AAA Client |
              +-----+    |      +----------------+
                         |         |
 +---+        +-----+    |    +---------+
 |PaC|        |AP/EP|----+----|AR/EP    |----- Internet
 +---+        +-----+    |    +---------+
                         |
              +-----+    |
              |AP/EP|----+
              +-----+

Br,
- Dan

> PANA WG Chairs

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 09 Dec 2004 17:31:16 -0800

Yes, PAA discovery is one of parts that get impacted. How about others?
For example:

- IP addressing. Link-local PRPA is not acceptable.
- Security. 
  - TTL check cannot be used anymore.
  - Any additional MitM vulnerability?
- Handling multiple PAAs that are in different parts of a domain
(deployment considerations?)
- what else?

For each we should identify what the issues are and how we resolve them
(e.g., protocol change, clarifying text, deployment considerations,
etc.).

More discussions needed.

Alper

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2004 7:44 AM
> To: [email-masked]; [email-masked]
> Subject: Multi-hop PANA
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 08 Dec 2004 00:34:10 -0500

> (deployment considerations?)

NAT traversal can be another issue.  What is the device identifier of
PaC when there are multiple PaCs behind a NAT router?  How the PAA can
initiate PANA authentication for those PaCs.

Yoshihiro Ohba