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

From: Alper Yegin <[email-masked]>
Date: Wed, 05 Jan 2005 11:30:01 -0800

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

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2004 11:43 AM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [Pana] RE: Multi-hop PANA
> 
> 
> 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
> 
> 
> > -----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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Jan 2005 13:12:44 -0500

I see one issue with what you suggested for E:

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)

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.

BTW, do we support MAC address as DI in multi-hop PANA environment?  I
think we might still want to support bootstrapping L2sec.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Jan 2005 00:32:57 -0800

Hi Yoshi,

> PaCs, if we want to cover this scenario.

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.

> messages with the PAA.  This is doable using PANA-Ping exchange.

OK, PAA can take care of that.

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

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Jan 2005 22:22:52 -0500

Sorry for my delayed response.  I made a deeper analysis below.  
Hope my comment is not too late....

> extracted from the PANA messages can be used to identify PaC device.

Yes, that is possible.  But I have another issue (see below).

> 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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Jan 2005 14:18:44 -0800

Hi Yoshi,

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?

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]
> > > > 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
> > > > > discuss what it takes to handle the issues, and then decide
what
> > gets
> > > > >   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
> > > > >   all around, do we have a "selection" issue now? If it
matters
> > which
> > > > >   deployments using multiple PAAs that are more than 1-hop
away
> > should
> > > > >   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 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
> > > > >   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 more general solution could be to state that PAA
discovery,
> > NAT
> > > > > > traversal and IP address allocation before PANA signaling
are
> > out of
> > > > > > > > - Handling multiple PAAs that are in different parts of
a
> > domain
> > > > > > > PaC when there are multiple PaCs behind a NAT router?  How
the
> > PAA
> > > > > > > > > > current work. No holding up the documents or
anything
> > like
> > > > > > > > > > - The default is we stick to the current framework
and
> > move

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Jan 2005 17:37:12 -0500

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

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.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Jan 2005 15:45:55 -0800

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

> seeing the MAC address in a MAC frame over the hop where the address

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. 

Alper

> > > > > 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
> > > > > > > We cannot simply list the affected parts and state
"addressing
> > > > these
> > > > > > >   It is the simplest (and yet still practical) if we
simply
> > stated
> > > > > > >   ensure it does not matter which PAA is chosen for PANA
(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
> > > > > > >   before the PANA run. This is a deployment consideration,
no
> > > > > > >   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.
> > > > > > >   the IP source address. For that we need to drop these
checks
> > > > from
> > > > > > the
> > > > > > >   protocol design (maybe keep them conditionally -- only
with
> > > > on-link
> > > > > > > > the scope of PANA spec when PAA is not one-hop-away
(i.e.
> > not
> > > > > > > > > > Yes, PAA discovery is one of parts that get
impacted.
> > How
> > > > > > > > > NAT traversal can be another issue.  What is the
device
> > > > identifier
> > > > > > > > > > For each we should identify what the issues are and
how
> > we
> > > > > > > > > > > > The current protocol design is based on the
charter
> > > > > > > > > > > > standardization of PANA within this framework.
We
> > shall
> > > > > > > > > > > > Having said that, there is a value in being able
to
> > run
> > > > > > > > > > > > protocol design and the process (timeline). Than
we
> > > > > > > > > > > > WG needs to come up with an analysis that
enumerates
> > > > > > > > > > > > etc.).  Dan, can you please drive this
discussion on
> > > > > > > > > > > > - 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
> > > > > > > > > > > > not get too excited about multi-hop PANA and
drag
> > this
> > > > > > > > > > > There is an old issue (12) about multi-hope PANA.
It
> > also
> > > > > > > > > > >     PANA, but do not define a discovery mechanism
for
> > > > > > > > > > > (c) from the issue 12: PAA on the data path and
use
> > router

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Jan 2005 19:06:22 -0500

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

> 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