Subject: [Pana] PANA over IP-in-IP tunnels

From: Alper Yegin <[email-masked]>
Date: Mon, 09 Aug 2004 17:56:02 -0700

Can we run PANA over IP-in-IP tunnels as is, or do we need some
additional considerations for that? Consider the tunnel is established
prior to running PANA. PANA does not have anything to do with the
management of the tunnel, but simply takes it as a "link".

Alper

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 29 Aug 2004 13:32:58 -0400

Hi Alper,

I think we can run PANA over an IP-in-IP tunnel as is, if the tunnel 
has been already established before running PANA over it.

I found in I-D tracker a comment from IESG with regard to
draft-ietf-pana-requirement-08.txt:

"
4.5.3 -- Please justify this requirement.  I can think of lots of
scenarios where it simply wouldn't hold, such as a large hotel or
conference center which permits free intranet access but demands
payment for most (but not all) external access.  Beyond that, what
about tunneled connections?  Are they permissible, given this
requirement?
"

I think we might clearly mention in the requirement draft that PANA
can run over IP-in-IP link.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Aug 2004 17:36:31 -0700

Yoshi,

> has been already established before running PANA over it.

What would be the DI? 

If there is a secure lower-layer channel (like physical security, or if
this is an IPsec tunnel), would we use the TOAs as the DIs? TOA is
equivalent to a link-layer address.

If there is no secure channel, one needs to be built based on IPsec. In
that case, the lower-layer addresses have no significance as DI in the
context of PANA.

> can run over IP-in-IP link.

Yes, agreed.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 15 Aug 2004 17:46:38 -0700

> management of the tunnel, but simply takes it as a "link".
Though it is technically a single hop, it allows the PAA to be anywhere on
the internet. This means the attacker gets to consume all of the network resources (compared
to just a few devices if PAA is located on the edge) that is between the PaC and
the PAA. I don't remember all of the discussions on what prevented from PAA being
more than one hop away  i.e what are the dis-advantages of performing network access
authentication in the core ? Sure, hop count not being decremented in the tunnel still prevents
a few threats. 

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Aug 2004 16:33:55 -0400

> equivalent to a link-layer address.

For an IP-in-IP encapsulated tunnel, I think it is sufficient to use
the TOA (tunnel outer address) as DI.  But you also mention IPsec
tunnel.  For an IPsec tunnel, I am not sure whether using TOA-only as
DI is sufficient if we consider:

  - There can be multiple IPsec tunnels between the same IPsec
  endpoints.

  - An IPsec tunnel is UDP encapsulated when NAT-T is used
  and there may be multiple PaCs that are behind the same NAT box 
  and connecting to the same PAA.

> that case, the lower-layer addresses have no significance as DI in the

I agree.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 18 Aug 2004 11:45:49 -0700

>   and connecting to the same PAA.

Good point. We could try to capture the DI as the collection of IP
address, IPsec SPI, UDP port number. But I think this is not only
getting complicated, but also it may not cover all sorts of other
tunneling mechanisms.

How about treating this case similar to addressless point-to-point
links? That is, not ever carrying the DI in PANA but relying on the
identifiers that are locally available (e.g., logical interface number).

I think this is a simpler and more scalable solution that is also
somewhat aligned with the current design.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Aug 2004 00:01:16 -0400

> identifiers that are locally available (e.g., logical interface number).

I agree.  Note that an IPsec tunnel mode SA may not have a dedicated
logical interface, but it must have a dedicated SAD entry and some
local identifier corresonding to the SAD entry can work as DI in any
case.

> somewhat aligned with the current design.

OK.

Yoshihiro Ohba