Subject: [Pana] Randy Turner's comments #1

From: Alper Yegin <[email-masked]>
Date: Thu, 01 Jul 2004 17:35:40 -0700

Hello,

Here is some feedback from Randy Turner on the PANA documents. Stay
tuned for more....

Alper

----------------

Comments on draft-ietf-pana-framework-00

(This was the version available on the IETF website PANA WG links)

------
Section 3 of the PANA Framework Document...

The last three paragraphs of section 3 describe the high-level exchange
necessary for a PaC to gain access to the network, and you also describe
the fact that an SA exists between the PaC and the EP.  I would
emphasize the point here (again) that the SA can either be implicit (in
the case of DSL and a pre-secured link) or explicit (requiring protocol
support "on the wire").

And I would also emphasize (even though it might be obvious to some),
that since an explicit SA typically requires some type of secure
encapsulation, and additional overhead, that this protocol overhead will
get stripped off at the EP and not affect communications beyond the EP.

You've already stated earlier in the draft, as I commented in my
original comments to you in earlier drafts, that it's important to place
the EP as close to the edge of the network as possible . So given this
point,  the "cost" of erecting an SA is also reduced because it only
exists for the initial "hop" in the access network.

-------

With regards to the following text:

 PRPA and the IP address of PAA are assumed to be on the same IP
      subnet, hence the PaC and PAA can perform on-link communication as
      required by PANA.  When the PaC replaces its IPv4 PRPA with POPA,
      this assumption may not hold true. In order to maintain the same
      on-link communication, the PaC and PAA SHOULD create host routes
      to each other upon PaC's IP address change.  The PaC SHOULD create
      a host route to the PAA, and the PAA SHOULD create a host route to
      the PaC (POPA).

I didn't see anywhere in the document leading up to this section a
discussion on the entity that is responsible for configuring the POPA.
Does the PAA have to be co-resident with the host that is responsible
for allocating/communicating the POPA to the PaC ?  If not, then the PAA
must "snoop" the IP configuration process between the PaC and the
"allocation entity" in order to create the necessary host route to the
PaC.  Let me know if I missed something in the text.

-------

Regarding the following text...

 When an IPv4 PRPA is configured, the same address may be used as
      both IPsec-TOA and IPsec-TIA.  In this case, a POPA is not
      configured.  Alternatively, an IPsec-TIA can be obtained via the
      configuration method available within [RFC3456] for IPv4, and
      [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly
      configured address constitutes a POPA.  Please refer to
      [I-D.ietf-pana-ipsec] for more details.

The last time I looked at the internals of an IPSEC implementation, and
the associated routing that takes place, the inner tunnel typically
reflects a different network than the network that is reflected by
IPSEC-TOA.  This means that the IP stack has (at least) two entries in
the route table. One entry says how to send a packet to the network
indicated by the TOA, and another route entry that says how to send
packets that are destined for the network reflected by the TIA.  the
remote node would have two different route entries that map to the same
network. UNLESS one of the route entries (for the TIA as an example)
contains a longer prefix than the route entry reflecting the TOA
network. This is how I was able to "force" packets down a tunnel if I
had overlapping routes. Is this making sense? I guess what I'm
suggesting is that the NAP probably would not use this capability
because of it's special nature.  Other IPSEC implementations may make
this easier I don't know. Let me know if you think this is something
that should be clarified.

Also, If the PaC authenticates successfully and accesses the network,
but there is an IPSEC SA between the PaC and PAA (or is it the EP), THEN
the user subsequently creates an IPSEC tunnel between the PaC and say a
corporate firewall termination point, how would this look? (assuming
there's quite a bit of overhead on the PaC for maintaining these two
SAs).

------

I'm not clear on the functional distinction between sections 10.1.2 and
10.1.3 - The NAPT CPE is also a router (it's NAT'ing between address
spaces). Since I don't believe NAPT has any specific impact on PANA
(since the CPE is the Pac), I would have just combined these two
sections, indicating that the router might also use NAPT.

-------

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 05 Jul 2004 00:51:08 -0400

Hello Randy Turner,

Thank you very much for sending valuable comments.  Please see my
comments in line.

> Here is some feedback from Randy Turner on the PANA documents. Stay

I agree that there can be a pre-established SA between PaC and EP when
PANA runs over pre-secured link.  One example is cdma2000 where a
link-layer SA needs to be established between a mobile and the radio
access network before establishing IP connectivity.  In this case, a
secure association protocol after PANA authentication is not
performed.  But I think it is probably not a good idea to use the word
"implicit SA" to represent the pre-established SA because the word
seems ambiguous.  Also, I am not sure what kind of security
association exists between PaC and EP in the case of physicaly secured
link because there is no cryptographic key shared betwen the two
entities.

> get stripped off at the EP and not affect communications beyond the EP.

OK.  How about revising the second last paragraph of section 3 from:

"
   In case a cryptographic access control needs to be enabled after the
   PANA authentication, a secure association protocol runs between the
   PaC and the EP.  The PaC should already have the input parameters to
   this process as a result of the successful PANA exchange. Similarly,
   the EP should have obtained them from the PAA via SNMP.  Secure
   association exchange produces the required security associations
   between the PaC and the EP to enable per-packet protection.
"

to:

"
   In case a cryptographic access control needs to be enabled after
   the PANA authentication, a secure association protocol runs between
   the PaC and the EP.  The PaC should already have the input parameters to
   this process as a result of the successful PANA exchange.  Similarly,
   the EP should have obtained them from the PAA via SNMP.  Secure
   association exchange produces the required security associations
   between the PaC and the EP to enable per-packet protection.
   Per-packet protection introduces additional per-packet overhead but
   the overhead exists only between the PaC and EP and will not
   affect communications beyond the EP.  In this sense it is important
   to place the EP as close to the edge of the network as possible.
"

> exists for the initial "hop" in the access network.

I think the revised text above covers this point.

> PaC.  Let me know if I missed something in the text.

Right.  This was addressed in PANA specification Issue 85
(http://danforsberg.info:8080/pana-issues/issue85).  To deal with
this, PANA-Address-Update-Request/Answer messages the current PANA
specification snapshot
(http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-05b.txt).

But I think we need some text in the framework draft.  How about
revising the above text to:

"
PRPA and the IP address of PAA are assumed to be on the same IP
subnet, hence the PaC and PAA can perform on-link communication as
required by PANA.  When the PaC replaces its IPv4 PRPA with POPA, this
assumption may not hold true. In order to maintain the same on-link
communication, the PaC and PAA SHOULD create host routes to each other
upon PaC's IP address change.  The PaC SHOULD create a host route to
the PAA, and the PAA SHOULD create a host route to the PaC (POPA).
PANA defines a mechanism for the PaC to report the POPA to the PAA.
"

> that should be clarified.

I think this routing issue is common to most IPsec tunnel mode
implementations and not speficic to IPsec tunnel mode usage with PANA.
So I am not sure we need to clarify this is the PANA framework draft.

> there's quite a bit of overhead on the PaC for maintaining these two

This aspect was once described in old pana-ipsec draft but removed
from the latest version, because there was some consensus that
consideration of remote IPsec gateway is out of scope of pana-ipsec
work.  I personally think that this issue is important but I am not
sure which document (existing one or a new one) would be the best
place to discuss this.

> sections, indicating that the router might also use NAPT.

I agree with you.  How above integrating section 10.1.2 and 10.2.3 
into a new section 10.1.2 as follows:

"
10.1.2 Router Mode

   In this case, the CPE acts as a router for the customer premises
   network.  The CPE itself may obtain the IP address using
   DHCP or be configured with static IP address.  Once the CPE is
   authenticated using PANA and is provided access to the service
   provider's network, the NAS should begin exchanging routing updates
   with the CPE. All devices at the customer premises will then have
   access to the service provider's network.

           Host--+
                 |
                 +----- CPE ---------------- NAS ------------- ISP
                 |   (Router, PaC)        (PAA,EP,AR)
           Host--+

                         Figure 9: Router Mode

   It is possible that both ends of the DSL link are configured with
   static IP addresses. PANA-based mutual authentication of CPE and
   NAS is desirable before data-traffic is exchanged between the
   customer premises network and the service provider network.  The
   CPE router may also use NAPT (Network Address Port Tranlation).
"

Regards,

Yoshihiro Ohba