Subject: RE: [Pana] RE: Multi-hop PANA

From: [email-masked]
Date: Tue, 14 Dec 2004 13:57:26 +0200

Hi all,

These could be solved by the proposal (b) below (2nd picture).

The more general solution could be to state that PAA discovery, NAT
traversal and IP address allocation before PANA signaling are out of
the scope of PANA spec when PAA is not one-hop-away (i.e. not
supported).

Br,
- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 08 December, 2004 07:34
> To: Alper Yegin
> Cc: Forsberg Dan (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Pana] RE: Multi-hop PANA
> 
> 
> 
> On Thu, Dec 09, 2004 at 05:31:16PM -0800, Alper Yegin wrote:
> > 
> > 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?
> 
> 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
> 
> > 
> > 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
> >  
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, December 08, 2004 7:44 AM
> > > To: [email-masked]; [email-masked]
> > > Subject: Multi-hop PANA
> > > 
> > > > -----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
> 

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Dec 2004 11:43:00 -0800

We cannot simply list the affected parts and state "addressing these is
outside the scope". Let's identify all possible parts that get affected,
discuss what it takes to handle the issues, and then decide what gets
done in the pana solution, what is left aside.

Having said that, here is an attempt:

A- PAA discovery

  Issue: How does the PaC discover PAA if it is off-link.

  Alternative solutions considered:
  1- EP upon detecting standard (link mcast) solicitation of a new PaC
can 
  use EP-to-PAA protocol to trigger an unsolicited PSA sent from the
PAA.
  2- Design a PAA proxy that resides on EP.
  3- Rely on router alert option 2113.
  4- Design a DHCP option for PAA discovery.

  Assessment (well, for now my personal assessment):
  Not sure about availability of 3.
  2 seems to have high impact on the design.
  1 is what we can mention in the spec (no protocol work needed on
PANA).
  4 is what we can do on the side.

B- Multiple PAAs

  Issue: If there are multiple PAAs in the access network, scattered 
  all around, do we have a "selection" issue now? If it matters which
  PAA is selected, then we need to talk about that.

  Solution considered:
  It is the simplest (and yet still practical) if we simply stated that
  deployments using multiple PAAs that are more than 1-hop away should
  ensure it does not matter which PAA is chosen for PANA (no protocol 
  work needed). 

C- IP addressing

  Issue: If the PAA is off-link, a link-local PRPA is not suitable.

  Solution considered:
  Just state that, if a deployment is using off-link PAAs, it must
ensure
  allocation of non-link-locals as PRPA. For example, it can allow
  global address configuration via DHCP, or stateless IPv6 autocnfig
  before the PANA run. This is a deployment consideration, no protocol
  work needed.

D- TTL check

  Issue: If the PAA is off-link, we cannot rely on TTL check.

  Solution considered:
  We haven't required PAA be on-link because we needed this TTL check.
  We (naturally) encoded this check in the design knowing that PAA is
  always on-link. Now, is it safe to remove this check? An alternative
  is to maintain this check only for PAAs that are discovered to be
on-link.
  That way a conservative deployment can still maintain the TTL check
  by using on-link PAAs. This requires protocol work. 

E- NAT traversal

  Issue: Now that PAA can be multiple hops away, there may be NATs
between
  the PaC and PAA. The may impact PAA discovery and integrity checks.

  - PAA discovery:
  If we go back to proposed resolutions to [A], I'm not sure which one
is
  impacted.

  - Integrity checks:
  Integrity checks fail when PANA peer compares the IP address DI with
  the IP source address. For that we need to drop these checks from the
  protocol design (maybe keep them conditionally -- only with on-link
PAAs).
  What is the impact of this change?

Please dig for more issues, alternative solutions, and provide comments.

Alper

> Sent: Tuesday, December 14, 2004 3:57 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Pana] RE: Multi-hop PANA
> 
> Hi all,
>