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

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 20 Dec 2004 09:25:06 +0100

hi alper, 

with the usage of multi-hop pana some additional aspects need to be address.
however, it is not that bad. 
for example, the mitm attacks have been discussed in
<draft-eronen-ipsec-ikev2-eap-auth-02.txt> where we try to omit the
server-side public key based authentication in ikev2. 

another issue worth pointing out is that you wouln't want to install packets
filters in a pana multi-hop environment (if you decide not to create a
tunnel additionally). we discussed the aspect of having the ep/paa a few ip
hops away in the pana working group a long time ago and the reasons are
quite obvious: routing asymmetry

ciao
hannes

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