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

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 15 Dec 2004 09:48:01 +0100

Hi Alper,

see my comments below..

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

I agree that 1 is what we can mention in the spec. Note that, as already
mentioned in section 4.2, the EP can also trigger the authentication
when it detects data packets from an unauthorized PaC.

I wonder if there is an additional "selection" issue here regarding the
relationship between EP and PAA. Now (1-hop scenario) I think it is
assumed that the EP gets in touch with the PAA that is located in the
same link. What happens when there are multiple PAAs in the access
network all around? Which PAA will be chosen by the EP? A possibility
might be to have a static configuration.

I also agree that 4 is what we can do in another I-D.

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

Not sure if this is correct. Even if it does not matter which PAA is
chosen for PANA, I think we should state a basic way to select the PAA.
This depends also on the discovery mechanism will be chosen.

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

Agree.

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

In your opinion, is it possible to have NAT traversal outside the base
spec? I think this is the most complex issue.
Could we state that, in the presence of a NAT, the PAA cannot be more
than one IP hop away?

Regards,
--Gerardo

> Please dig for more issues, alternative solutions, and 
> provide comments.
> 
> Alper
>  
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > 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,
> > 
> > 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
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 15 Dec 2004 17:42:20 -0800

Hello Gerardo,

> might be to have a static configuration.

Yes, static configuration is what we can recommend. Well, we don't have
a dynamic discovery even for on-link PAA anyways.

> This depends also on the discovery mechanism will be chosen.

I think we'd say "pick any". This can change in the future... Some
future I-D can additional info on the PSR and define a selection
mechanism based on that. Anyways, this is independent of whether PAA is
on-link or off-link.

> Could we state that, in the presence of a NAT, the PAA cannot be more

We can keep that as a backup plan. But I still rather understand what it
takes to make PANA go through NATs. If that proves too complex, we can
fall back to what you are suggesting. So, how bad is what I'm suggesting
above, and are there alternative solutions?

Alper