Subject: [Pana] Comments on draft-ietf-pana-pana-04

From: Randy Turner <[email-masked]>
Date: Tue, 06 Jul 2004 23:11:41 -0700

Hi Alper, and the list,

I'm working my through the drafts as I get a moment (mainly on flights ;).
Here are some other comments on draft-ietf-pana-pana-04...more to follow.

I will try and hit the list with some final comments by this weekend.

Regards,
Randy
(will this group be meeting in San Diego?)

draft-ietf-pana-pana-04 comments
=========================================

The document mentions that PANA assumes that the PAA is one hop away from
the PaC. Is this a requirement on the topology, or could the scope of the
multicast be wider than this?

-------

In Section 4.7, Device ID Choice, the text says that "the ID can be an IP
address, a MAC address, or an identifier that is not carried on data packets
but has local significance." Maybe it's my years of doing standards, but I
think maybe you should stipulate that the device ID MUST NOT have temporal
characteristics. You're requiring that the PaC have an IP address prior to
PANA, which means that this address (in IPv4) will probably be a temporary
address (auto-configured somehow), and this would probably be especially
true in an IPv6 environment. Likewise, MAC addresses might have local
persistence that is more persistent than an IP address, but it could still
change.  I think that the device ID should reference an agreed upon value
between NAP or ISP and the PaC. The namespace might vary between ISP or NAP
but I think (if I were you) I would emphasize the non-transient nature of
the device ID. It's really what the authentication is all about so it's
important that this be solid. In the framework document, I think you mention
the use of network access identifiers (NAIs), which would be ideal for the
NAP case, but also something similar could be used for service provider
authentication as well. Correct me if I'm wrong, but to the PANA-aware nodes
in the network, the device-ID is an opaque series of bytes of some length.
Is this correct?

By the way, I'm assuming that it's possible for multiple PANA sessions to be
in progress at the same time. Probably one session for the NAP, and possibly
<N> number of service provider sessions.  Which brings me to another point
about the protocol document, and I believe the framework document.
Throughout these documents you've isolated the dominant  model of network
connectivity today: someone wants to get access to the global internet.  But
looking ahead, the use of PANA could be expanded to ISP, ASP, whatever. I
think it's important for the audience of PANA to understand that this is not
just an "ISP connectivity" method, but could be reused, as could the
topological infrastructure, for a number of different business models.

--------

I may have missed it, but it wasn't clear to me that the PaC state machine
could receive an unsolicited PANA-Start-Request until Figure 3 (just prior
to 4.3).  It might have been inferred in the discussion about race
conditions when a PANA-PAA-Discover message and a PANA-Start-Request message
are sent at the same time, but I was thinking this condition would only
occur if the PaC retransmitted the "discover" message quicker than the PAA
could respond. 

Is it part of the core state machine of PANA that the PaC OR the PAA can
start the process? I like the idea about how the EP can notify the PAA that
a potential PaC is trying to use the network prior to authentication. Would
this be the only scenario where the PAA initiates a PANA session?

---------

Regarding the overall security (integrity, possible confidentiality)
discussed in the draft (as well as in the PANA-IPSEC doc), I know that
integrity and confidentiality is a nice feature to offer,  but it only
encompasses a subset of the links that the traffic has to traverse. At the
application level, the endpoints of the application have knowledge of the
potential security requirements for the traffic that the protocol will
generate. If the application mandates security and confidentiality, then the
application will establish an "end-to-end" SA, utilizing possibly both
confidentiality and encryption.  If the application/service endpoint is
co-resident with the PaC functionality, I'm concerned about the overhead
involved in having duplicate, layered SAs established.  I think this concern
is restricted primarily to the confidentiality aspects of data traffic, and
not necessarily integrity checking.

NAP or ISP authentication credentials should probably be protected during
the PANA establishment phase, but this only happens during the
initialization of the session.  If I'm deploying an application that
requires confidentiality, I would probably not want to rely on layer-2 or
layer-3 mechanisms to guarantee conifdentiality. It's difficult for me to
see a scenario where a NAP would mandate confidentiality on a link. Nor a
traditional ISP. However, in an earlier comment, I suggested emphasizing the
fact that PANA could be used in an ASP environment as well, where the
"service provider selection" mechanism would select and create a network
between the PaC and an ASP. In this case, it's an "Application" Service
Provider, and the path between the PaC and ASP might require
confidentiality.

I feel like I'm rambling a bit here, but I think there's a point regarding
the applicability of a heavyweight SA that implements both confidentiality
and integrity for the link between the PaC and the PAA.

Without the discussion of IPSEC and complex SA mechanisms in the PANA
document set, the protocol seems much easier to grasp and understand (and
potentially implement, depending upon your point of view). In my experience,
carriers and network folk are drawn to simplicity. If you're open to this
idea, I think a quick and straightforward way to approach this would be to
isolate anything regarding confidentiality and complex SA establishment to a
document or documents external to the base PANA protocol specification.
You've got the basic AVP extensibility mechanisms anyway, so it's a short
walk for someone to use this method. You've already got the specifics
regarding EAP mechanisms outside the docs which is a good way to approach
this.

Overall, I understand the perceived need to potentially offer
confidentiality over network links that are "shared" at the edge, but I
believe that in most cases, it will be redundantly applied to protect
application information. I may be over-reacting a bit here, and it's not a
big deal for me, I just have had to make this balance before in complexity
and layering. Splitting off confidentiality from anything that might
resemble the "core" of PANA is the right way to go (and you've already done
this with the separate IPSEC draft). Because of the need to secure the PANA
session itself with respect to filtering at the EP, you have already bought
the requirement for session-tagging with integrity, so again, this is mainly
a confidentiality thing I'm talking about.

I was curious if the IESG or anyone else has commented on these particular
security aspects of PANA work?

----------

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jul 2004 19:41:30 -0400

Hello Randy Turner,

Thank you (again) for sending detailed comments.

Please see my comments below.

> draft-ietf-pana-pana-04 comments

This is a requirement on the topology, as described in Section 4.5.3
of draft-ietf-pana-requirements-08.txt.

> authentication as well. 

I am not sure whether you are talking about device identifier or
session identifier or both, but in PANA, device identifier is
changeable.  In the next revision, we will have
PANA-Address-Update-Request/Answer messsages to update device ID as
well as POPA (you can check the latest snapshot in
http://www.toshiba.com/tari/pana/pana-spec.html.)  Since device
identifier is defined as a changeable parameter, we defined session
identifier as a stable identifier (except for the case of mobility
handling described in section 4.9 where session identifier changes
after handoff.)

> Correct me if I'm wrong, but to the PANA-aware nodes

In PANA, device identifier have a Diameter Address type which is
derived from Diameter OctetString type.  PANA session identifier has
the same structure as Diameter Session-Id AVP.

> topological infrastructure, for a number of different business models.

This is an interesting scenario, but I think there is some significant
issues related to having <N> number of global IP addresses assigned by
<N> service providers, namely, source address selection issue and
multi-homing issue.  It is probably not a good idea to allow <N>
number of service provider sessions in PANA until those issues are
fully studied.

> occur if the PaC retransmitted the "discover" message quicker than the PAA

I think Figures 2 and 3 are not good example to show the race
condition because in the examples both either PaC or PAA is the
initiator of the discovery and initial handshake phase.

      PaC   EP      PAA    Message
      ------------------------------------------------------
       ---->o              (DHCP traffic triggers discovery at PAA
             ------>        via PAA-to-EP protocol)
       ------+
       <-----|------       PANA-Start-Request(x,0)[Cookie]
             +----->       PANA-PAA-Discover(0,0)
       ------------>       PANA-Start-Answer(y,x)[Cookie]
                           (continued to authentication phase)

In this example, both PaC and PAA tries to initiate discovery in which
case the race condition is likely to happen.

> this be the only scenario where the PAA initiates a PANA session?

Yes.  And there is such a requirement in
draft-ietf-pana-requirements-08.txt.

BTW, I am writing up a new I-D on PANA state machines.  That document
could help you understand PANA protocol behavior in detail.

> not necessarily integrity checking.

I know your concern as you made the same comment on the PANA framework
draft.  

Since IPsec is flexible enough to allow establishing an IPsec SA with
null encryption, it is possible to avoid double encyption (i.e., one
at application level the other between PaC and EP) if you use L3
per-packet ciphers in the access network.  Anyway, I think PANA
specification is not the right place to address this.

> Provider, and the path between the PaC and ASP might require

The same comment as above.

> regarding EAP mechanisms outside the docs which is a good way to approach

I think specifics regarding not only EAP mechanisms but also IPsec are
already separated from the PANA specification draft.  I believe the
current draft has the structure that allows a quick and
straightforward way to approach this and I guess you are not proposing
some addtional text for the PANA specification draft on this.

> a confidentiality thing I'm talking about.

The same comment as above.

> security aspects of PANA work?

This was once discussed in the context of pana-ipsec draft.

Best regards,

Yoshihiro Ohba

---

From: Randy Turner <[email-masked]>
Date: Thu, 08 Jul 2004 18:19:58 -0700

Hi,

The DSL Forum is establishing a model for the access scenario that I
mentioned in my earlier email, which is the single NAP authentication, and
possibly multiple service provider PANA sessions. Also, this will definitely
happen in the FTTP broadband multi-service environment as well. An existence
proof already exists for multi-homing of IP services into broadband CPE
through multiple FTTP service trials that are currently being operated by
SBC, Verizon, etc.

I think we should put more thought into adapting PANA for this scenario, if
it is currently not supported.

If you guys are going to be at the IETF meeting in San Diego, maybe we can
get together and discuss this; I have some ideas on how this might operate.

Randy

> From: Yoshihiro Ohba <[email-masked]>
> Date: Thu, 08 Jul 2004 19:41:30 -0400
> To: Randy Turner <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [Pana] Comments on draft-ietf-pana-pana-04
> 
> Hello Randy Turner,
>