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

From: Alper Yegin <[email-masked]>
Date: Tue, 04 Jan 2005 11:16:00 -0800

Folks,

Let's drive this work to conclusion.

If there are additional issues to be discussed, please bring them up
now. Anything that may be impacted by relaxing the 1-hop constraint
should be put on the table. And we shall analyze its effect on the
protocol design.

We shall finish this up by Jan 10. 

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Tschofenig Hannes
> Sent: Monday, December 20, 2004 12:25 AM
> To: Alper Yegin; [email-masked]; [email-masked]
> Subject: RE: [Pana] RE: Multi-hop PANA
> 
> 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

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 11 Jan 2005 10:15:29 +0100

hi alper, 

for packet filter installation to be useful you need to ensure that
a) you install the filter at the devices which will later be traversed by
the actual data
b) the routes in the direction from entity A to entity B are typically
different from B to A (routing asymmetry). 

to address these two issues is subject to work in the nsis working group and
requires special handling. going along this road requires a number of
mechanisms which are outside the scope of a multi-hop pana solution since
they are then touching the work done in nsis on nat/firewall traversal. 

ciao
hannes

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Dienstag, 11. Jänner 2005 08:48
> To: 'Gerardo Giaretta'
> Cc: [email-masked]; [email-masked]; [email-masked]
> Gerardo,
> > What about the issue raised by Hannes regarding packet filter 
> > installation?
> 
> Hannes had said:
> 
>  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
> 
> 
> I don't quite understand what exactly the issue is here.
> 
> Alper
> 
> 
> 
> > 
> > Regards,
> > --Gerardo
> > 
> > 
> > > Alper
> > >
> > >
> > > > From: Alper Yegin [mailto:[email-masked]]
> > > > Sent: Tuesday, December 14, 2004 11:43 AM
> > > > To: [email-masked]'; [email-masked]'
> > > > Cc: [email-masked]'
> > > > 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]
> > > > > 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
> > > > >
> > > > > > 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:
> > > > > > >
> > > > > > > - 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
> > > > > >
> > > > > > >
> > > > > > resolve them
> > > > > > > (e.g., protocol change, clarifying text, deployment
> > > considerations,
> > > > > > > etc.).
> > > > > > >
> > > > > > > More discussions needed.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Alper
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > Subject: Multi-hop PANA ( was RE: [issue138]:
> > > > > > Requirement for one
> > > > > > > hop
> > > > > > > > > The current protocol design is based on the 
> charter and
> > > protocol
> > > > > > > > > standardization of PANA within this 
> framework. We shall
> > > > > > stay away
> > > > > > > > > protocol design and the process (timeline). 
> Than we can
> > > decide
> > > > > > > > > WG needs to come up with an analysis that 
> enumerates the
> > > changes
> > > > > > > > > etc.).  Dan, can you please drive this 
> discussion on the
> > > PANA ML
> > > > > > > > > - 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
> > > > > > > > > - The default is we stick to the current
> > > framework and move
> > > on.
> > > > > > > Let's
> > > > > > > > There is an old issue (12) about multi-hope 
> PANA. It also
> > > suggests
> > > > > > > > (a) rely on the existing EP-to-PAA notification, i.e.
> > > > > > allow multi-hop
> > > > > > > > (c) from the issue 12: PAA on the data path and 
> use router
> > > alert
> > > > > > > > On example scenario, where multi-hop PAA would 
> be suitable
> > > (figure
> > > > > > > > from issue12).
> > > > > > > >
> > 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 
> > ====================================================================
> > 
> > 
> > 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 
> > ====================================================================
> 
> 
>

---

From: [email-masked]
Date: Mon, 24 Jan 2005 13:14:22 +0200

Here is the current status of the multi-hop issues. Please let me know
if there is something more that we need to address or if we could
proceed to editorial change proposals against the current draft.

-------------------------------------------------------------------------------
A- PAA discovery
B- Multiple PAAs
C- IP addressing
D- TTL check
E- NAT traversal
-------------------------------------------------------------------------------

A- PAA discovery

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

  1- EP upon detecting PDI sent by a PaC can use EP-to-PAA protocol to trigger an 
     unsolicited PSR sent from the PAA. 

  This does not require any additional protocol work. PANA already supports
  this model (see "traffic-driven PAA discovery").

  2- Design a DHCP option for PAA discovery.

  This additional scheme can be pursued in DHC WG. 

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) to state
  that deployments using multiple PAAs should ensure it does not 
  matter which PAA is chosen for PANA. This is already stated in
  the base spec for multiple on-link PAAs. Same rule should apply
  to multiple off-link PAAs as well, hence there is no protocol
  change needed.

  Future PANA extensions (separate I-Ds) can describe a detailed 
  selection scheme, if necessary.
   
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
  autoconfig before the PANA run. This is a deployment consideration,
  no protocol work needed.

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

  We can either drop the TTL checks, or use an adaptive scheme where
  TTL checks are enforced as soon as PaC and PAA knows the peer is
  on-link. PAA may already know whether PaCs are always on-link or not.
  PAA and PaC can inspect the first PANA packets to determine if the
  peer is on-link, and enforce the check on any subsequent PANA packet.

E- NAT traversal

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

  Issue: PAA Discovery
  
  None of the schemes in [A] are impacted by NATs. Hence there is no 
  issue on PAA discovery.

  Issue: Integrity checks
  
  Integrity checks fail when PANA peer compares the IP address DI with
  the IP source address. 

  Solution considered:

  This check is only performed on the PAA. We can state that this check
  should be used only when there are no NATs between the PaC and PAA.
-------------------------------------------------------------------------------

> Sent: 21 January, 2005 02:06
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; Forsberg Dan (Nokia-NRC/Helsinki); [email-masked]
> On Thu, Jan 20, 2005 at 03:45:55PM -0800, Alper Yegin wrote:
> > > > Isn't this the problem of "IP/MAC address ownership" which we
> > decided to
> > > > leave outside the scope of PANA spec? Am I missing something?
> > > 
> > > It might be an address ownership problem.  But can we 
> just extending
> > > the PANA protocol without trying to minimize the security impacts
> > > caused by the protocol extension?
> > 
> > We have the same problems even with the one-hop PANA. And 
> we had said
> > this was not for PANA "protocol" to solve. Additional 
> mechanisms that
> > are separate from the PANA protocol can be used, when necessary.
> > 
> > Just to clarify: I agree with you that this is a problem; 
> my point is
> > this is not for PANA to solve, and it is not newly introduced by the
> > mhop extension (we already had an instance of it before).
> 
> I agree that this is not newly introduced by the mhop extension.  On
> the other hand, the resulting impact of the same problem could be much
> larger with the mhop extention.  We might not have to completely solve
> the address ownership problem within PANA, but I think we should try
> to mitigate the impact to the extent that we allowed for single-hop
> PANA, which is my point.
> 
> > 
> > > I personally don't feel comfortable with binding a key to 
> MAC address
> > > declared by someone who is several IP hops away from me, without
> > > seeing the MAC address in a MAC frame over the hop where 
> the address
> > > is being used.
> > 
> > This is not the first time we are seeing such a problem. 
> Please see what
> > happens with Mobile IP, when MN sends a registration 
> request (or binding
> > update) to a home agent. Care-of address can be spoofed. 
> 
> Yes, it might be just another form of the same identifier-locator
> binding problem.  I think every protocol that deals with the
> identifier-locator binding should have a mechanism at least to
> mitigate the problem to some extent.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > Alper
> > 
> > 
> > 
> > 
> > 
> > > 
> > > Yoshihiro Ohba
> > > 
> > > 
> > > 
> > > >
> > > > Alper
> > > >
> > > >
> > > >
> > > >
> > > > > From: Yoshihiro Ohba [mailto:[email-masked]]
> > > > > Sent: Wednesday, January 19, 2005 7:23 PM
> > > > > To: Alper Yegin
> > > > > Cc: 'Yoshihiro Ohba'; [email-masked]; [email-masked]
> > > > > Sorry for my delayed response.  I made a deeper 
> analysis below.
> > > > > Hope my comment is not too late....
> > > > >
> > > > > On Wed, Jan 12, 2005 at 12:32:57AM -0800, Alper Yegin wrote:
> > > > > > Hi Yoshi,
> > > > > >
> > > > > > > a) When there are two PaCs connected to different 
> NAT boxes
> > but
> > > > they
> > > > > > > are assigned the same private address X, the PAA 
> will see the
> > same
> > > > IP
> > > > > > > address DI (i.e., X) contained in the PBAs from 
> those PaCs and
> > > > thus
> > > > > > > the PAA will not be able to distinguish the two 
> PaCs using DI
> > > > solely.
> > > > > > > (The same problem is described in RFC 3947.)  
> Some additional
> > > > > > > information would need to be used with DI to 
> distinguish those
> > two
> > > > > > > PaCs, if we want to cover this scenario.
> > > > > > >
> > > > > > > PaC1 -- NAT1 --+
> > > > > > >  (X)           |
> > > > > > >                +--- PAA
> > > > > > >                |
> > > > > > > PaC2 -- NAT2 --+
> > > > > > >  (X)
> > > > > >
> > > > > > This is an issue when DI is the IP address of the PaC.
> > > > > > I think PAC-DI in conjunction with the source IP 
> address (NAT
> > > > address)
> > > > > > extracted from the PANA messages can be used to identify PaC
> > device.
> > > > >
> > > > > Yes, that is possible.  But I have another issue (see below).
> > > > >
> > > > > >
> > > > > > > There is another issue for E:
> > > > > > >
> > > > > > > b) To prevent a NAT box from deleting the 
> address/port mapping
> > > > during
> > > > > > > the PANA session, the PaC needs to periodically keep
> > exchanging
> > > > > > > messages with the PAA.  This is doable using PANA-Ping
> > exchange.
> > > > > >
> > > > > > OK, PAA can take care of that.
> > > > > >
> > > > > > > BTW, do we support MAC address as DI in multi-hop PANA
> > > > environment?  I
> > > > > > > think we might still want to support bootstrapping L2sec.
> > > > > >
> > > > > > Yes. We shall not perform DI verification in the 
> received PANA
> > > > messages,
> > > > > > as the original L2 header is not preserved once the 
> packets are
> > > > routed
> > > > > > at the first hop router. Do you see any other issues there?
> > > > >
> > > > > I see a DoS issue with binding an address that is not in the
> > > > > encapulating headers of PANA messages.  An attacker 
> PaC that uses
> > *its
> > > > > own MAC address* with its own credentials and behind 
> a NAPT router
> > can
> > > > > establish multiple PANA sessions with 
> cryptographycally binding
> > > > > different MAC addresses for those sessions by specifying those
> > > > > addresses in Device-Id AVPs.  If those MAC addresses 
> are actually
> > used
> > > > > by other PaCs, those PaCs will not be able to 
> cryptographycally
> > bind
> > > > > their own MAC addresses to their sessions because 
> they are already
> > > > > bound to the attacker's sessions.
> > > > >
> > > > > I think this issue also applies to the case where IP 
> address is
> > used
> > > > > as DI and there is a NAPT router between PaC and PAA.
> > > > >
> > > > > To solve this problem, the cryptographic binding between the
> > device
> > > > > identifier and a shared secret (i.e., an IKE shared 
> secret or an
> > IEEE
> > > > > 802.11i PSK) that is derived from the AAA-Key and used by the
> > secure
> > > > > association protocol between PaC and EP, should be 
> created by a
> > secure
> > > > > association protocol where EP can always see the 
> device identifier
> > in
> > > > > each data packet.  Instead, the shared secret needed 
> to run the
> > secure
> > > > > association protocol should be bound to some other identifier
> > (such as
> > > > > Session-Id) that is *assigned by the PAA* (not a 
> device identifier
> > > > > *declared by the PaC*) before running the secure association
> > protocol.
> > > > >
> > > > > In the case of IPsec ciphering, ID_KEY_ID which 
> contains the PANA
> > > > > Session-Id is bound to the IKE pre-shared secret 
> before running
> > IKEv2,
> > > > > and then the binding between the IKE pre-shared secret and the
> > device
> > > > > identifier of the PaC (i.e., PaC's IP address) is 
> made by IKEv2.
> > In
> > > > > the case of the PSK mode of IEEE 802.11i, the PSK is 
> bound to the
> > MAC
> > > > > address of the PaC, and this binding needs to exist 
> before running
> > the
> > > > > 4-way handshake.  So I think that the combination of 
> multihop-PANA
> > and
> > > > > bootstrapping IEEE 802.11i may be difficult to prevent the DoS
> > attack.
> > > > > Instead, a better secure association protocol such as 
> PEKM may be
> > > > > needed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Yoshihiro Ohba
> > > > >
> > > > > >
> > > > > > Alper
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Yoshihiro Ohba
> > > > > > >
> > > > > > > On Wed, Jan 05, 2005 at 11:30:01AM -0800, Alper 
> Yegin wrote:
> > > > > > > >
> > > > > > > > Does anyone see any problems with what I 
> suggested for D and
> > E?
> > > > > > > > Especially performing the checks conditionally.
> > > > > > > >
> > > > > > > > PAA is assumed to know its location (1-hop vs 
> m-hop). PaC
> > can
> > > > learn
> > > > > > if
> > > > > > > > the PAA is on-link as soon as it receives the 
> PSR. If PaC
> > and
> > > > PAA
> > > > > > are
> > > > > > > > on-link, they perform the TTL and header 
> integrity checks
> > > > > > accordingly.
> > > > > > > >
> > > > > > > > Alper
> > > > > > > >
> > > > > > > >
> > > > > > > > > outside the scope". Let's identify all 
> possible parts that
> > get
> > > > > > > > affected,
> > > > what
> > > > > > gets
> > of a
> > > > new
> > > > > > PaC
> > > > > > > > >   use EP-to-PAA protocol to trigger an unsolicited PSA
> > sent
> > > > from
> > > > > > the
> > > > > > > > PAA.
> > > > > > > > >   1 is what we can mention in the spec (no 
> protocol work
> > > > needed on
> > > > > > > > PANA).
> > > > matters
> > > > > > which
> > simply
> > > > stated
> > > > > > should
> > (no
> > > > > > > > >   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
> > no
> > > > TTL
> > > > > > check.
> > > > PAA
> > > > > > > > >   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
> > > > > > > > >   Issue: Now that PAA can be multiple hops 
> away, there may
> > be
> > > > NATs
> > > > > > > > between
> > integrity
> > > > > > checks.
> > sure
> > > > which
> > address
> > > > DI
> > > > > > with
> > > > > > > > >   the IP source address. For that we need to 
> drop these
> > checks
> > > > > > from
> > > > > > > > the
> > with
> > > > > > on-link
> > > > discovery,
> > > > > > NAT
> > > > > > out of
> > > > > > > > > > the scope of PANA spec when PAA is not one-hop-away
> > (i.e.
> > > > not
> > > > > > > > > > supported).
> > > > > > > > > >
> > > > > > > > > > Br,
> > > > > > > > > > - Dan
> > > > > > > > > >
> > > > > > > > > > > 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:
> > > > > > > > > > > >
> > > > a
> > How
> > > > > > PAA
> > > > > > > > > > > > For each we should identify what the 
> issues are and
> > how
> > > > we
> > > > > > > > > > > resolve them
> > > > > > > > > > > > > > Basavaraj and I discussed this and 
> here's our
> > > > > > > > recommendation.
> > > > > > > > > > > > > >
> > charter
> > > > and
> > > > > > > > > > > > > > requirements (a framework). Our #1 
> objective is
> > > > > > expedited
> framework.
> > We
> > > > shall
> > > > > > > > > > > > > > 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
> > > > > > > > > > > > > > protocol design and the process 
> (timeline). Than
> > we
> > > > can
> > > > > > > > decide
> > > > > > > > > > > > > > whether we consider this change 
> before pushing
> > the
> > > > > > > > > > > protocol design
> > enumerates
> > discussion on
> > > > > > > > > > > > > > (i.e., no design team) and produce 
> a summary (a
> > > > short
> > > > > > > > write-up)?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, I can do that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Couple important points:
> > > > > > > > > > > > > > - 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
> > framework
> > > > and
> > > > > > move
> > > > > > > > > > > > > > not get too excited about multi-hop PANA and
> > drag
> > > > this
> > > > > > > > > > > too long ;-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There is an old issue (12) about 
> multi-hope PANA.
> > It
> > > > also
> > > > > > > > suggests
> > > > > > > > > > > > > (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.
> > > > > > > > > > > > >
> > use
> > > > router
> > > > > > > > > > > > > On example scenario, where multi-hop 
> PAA would be
> > > > suitable
> > > > > > > > (figure
> > > > > > > > > > > > > from issue12).
> > > > > > > > > > > > >
> > > > > > > > > > > > >   |          +-----+  Node 2 
> +------+///-->+   PAA
> > > > +-//
> +----------------+
> +----------------+