Subject: [Pana] Device ID comment from pana-pana-12

From: Mark Townsley <[email-masked]>
Date: Mon, 18 Sep 2006 06:35:09 +0200

In "5.7. Device ID Choice" section, the paragraph begins: "The device 
identifier used in the context of PANA can be an IP address, a MAC 
address, or ..." and later in the paragraph new text has been added to 
try and make clear that the device id is local, not to be exchanged in 
the protocol: "The locally-significant identifiers are used locally to 
associate PANA sessions with the local interfaces and are not meant to 
be exchanged with the peers."

However, later in the section, we are told that for IPsec based 
security, "the PAA MUST provide IP addresses as device identifiers of 
EPs, and expect the PaC to provide its IP address in return. Similarly, 
IP addresses are used as the device identifiers when the EPs are not on 
the same IP subnet as the PaC."

I *think* what you are trying to say here is that IP addresses *are* 
exchanged somehow, but I'm not sure if that is supposed to be by IPsec 
or PANA?

Further, Section 5.8 mentions including a Device ID AVP, which again is 
in conflict with the new text in 5.7. This all seems quite unclear.

I still find the use of link-specific "Device IDs" as in conflict with 
the layer-agnostic advantages that PANA purports. If the IP address was 
*always* the Device ID, I think the layers would be better preserved. 
Why can this not be?

Thanks,

- Mark

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Sep 2006 02:12:35 -0400

Hi Mark,

> be exchanged with the peers."

Let me quote the entire paragraph:

"
   The device identifier used in the context of PANA can be an IP
   address, a MAC address, or an identifier that may not be carried in
   data packets but has local significance in identifying a connected
   device (e.g., circuit id, PPP interface id).  The last type of
   identifiers (i.e., locally-significant identifiers) are commonly used
   in point-to-point links where MAC addresses are not available and
   lower-layers are already physically or cryptographically secured.
   The locally-significant identifiers are used locally to associate
   PANA sessions with the local interfaces and are not meant to be
   exchanged with the peers.
"

The "locally-significant identifier" in the last sentense points to
the last (third) type of device identifier, i.e., "an identifier that
may not be carried in data packets but has local significance in
identifying a connected device (e.g., circuit id, PPP interface id,
not an IP address or a MAC address."

If this text can be interpreted in multiple ways (I don't think so),
we will need to fix the text.

> the same IP subnet as the PaC."

This part is for the first type of device identifier, i.e., IP
address.  This does not apply to locally significant identifiers.

> exchanged somehow, but I'm not sure if that is supposed to be by IPsec 

This is supposed to be by PANA.  The reason is that the PaC needs to
know the device identifiers of EPs to generate PaC-EP-Master-Keys
which is used by IPsec.

> in conflict with the new text in 5.7. This all seems quite unclear.

Again it depends on whether the new text in Section 5.7 (quoted above)
can be interpreted in multiple ways.  Do you think
multi-interpretation is possible with the current text?

> *always* the Device ID, I think the layers would be better preserved. 

If we allow only IP address to be used as device id, then (i) support
for IPv4/IPv6 dual-stack PaCs and PaCs with multiple IPv6 addresses
would be more complicated, and (ii) bootstrapping link-layer ciphering
would not be possible.

Regards,
Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Mon, 18 Sep 2006 18:38:06 +0300

> we will need to fix the text.
I understand the semantics better now, but am still struggling with what
a locally significant ID is used for in the PANA protocol, and why it is
introduced alongside a non-locally significant ID.

First, if a description for a local-id is going to remain, I think it
would be a bit more clear to introduce the terminology in the first
sentence. That is:

OLD:

   The device identifier used in the context of PANA can be an IP
   address, a MAC address, or an identifier that may not be carried in
   data packets but has local significance in identifying a connected
   device (e.g., circuit id, PPP interface id)...

NEW:

   The device identifier used in the context of PANA may be an IP
   address, a MAC address, or a locally-significant identifier that 
   is not carried in data packets. A locally-significant ID
   has significance in identifying a connected device (e.g., circuit 
   id, PPP interface id)...

(I also cleaned up some of the language around - "may not" is ambiguous, and brings doubt into what "local" really means here, so I replaced it with "is not" which is more definitive)

Second, of what use to PANA is a device ID that is of local significance, and never appears in data packets or PANA messages? Is this significant only from a local API perspective? If so, does it even belong in a protocol spec along side things like IP and MAC address which are exchanged between PANA nodes and appear in data packets, and thus are clearly something quite different?

> would be more complicated, and 
If the rules are that a given set of IP prefixes (of either version) are
associated with a given PANA session, I don't see why. For better or
worse, I would think that a *network* authentication protocol would
naturally include such *network-level* mechanisms.
> (ii) bootstrapping link-layer ciphering
> would not be possible.
>   
This is representative of the PANA layering violations that I and others
keep stumbling upon.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Sep 2006 20:20:19 -0400

On Mon, Sep 18, 2006 at 06:38:06PM +0300, Mark Townsley wrote:

(snip)

>    has significance in identifying a connected device (e.g., circuit 

Yes, this is better (please see my another comment below).

> Second, of what use to PANA is a device ID that is of local significance, and never appears in data packets or PANA messages? Is this significant only from a local API perspective? If so, does it e…

It is significant from a local API perspecitive.  But I see your point.
Implementations can handle locally siginificant identifiers even
without being mentioned in the specification.  I am ok with removing
the locally significant identifiers from the spec.

> naturally include such *network-level* mechanisms.

IP prefixes are not device ids.  Each IP address would be a device
identifier when IP address is used as device id.  In this case, since
only one device id is associated with a PANA session, multiple PANA
sessions would be required, which is inefficient.  Also, in the
architecture that allows an entity that performs access control to be
physically separated from an entity that authenticates clients, I
believe that use of network-layer protocol for carrying authentication
information should not necessary restrict the access control function
to be based on IP address only.

> This is representative of the PANA layering violations that I and others

The formal review of pana-framework draft from IEEE 802.11 WG did not
claim that bootstrapping 802.11i PSK mode should not be done, while
they claimed about a particular way of bootstrapping 802.11i PSK mode.
So I thought we are fine...

Regards,
Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Tue, 19 Sep 2006 11:23:21 +0300

> the locally significant identifiers from the spec.
I think it is probably better to go ahead and leave it out then. If you
do keep it in the spec, perhaps describe it in a completely separate
paragraph or section vs. the Device IDs that actually cross the wire.
> to be based on IP address only.
OK, then a device ID is really just some unique value that exists at the
PaC and PAA prior to the PANA session starting. Why tie the "device ID"
to data traffic at all? I would think that, whether data traffic
enforcement is done with MAC addresses or IP prefixes (including v4 /32
or v6 /128) this would be independent of the "identity" of a given
"device."

I have a related question, In the "local device ID case" how did PANA
negotiate what traffic was allowed to flow from the PaC through the EP
or PAA/EP?

> So I thought we are fine...
I am speaking more of the reaction from the IETF at large during LC, and
my own review. Basically, if PANA is supposed to operate at the Network
Layer, anytime it affects something at the link-layer (or requires
something of a link-layer) it is violating that layering. Bootstrapping
a link-layer cipher is by definition such a violation. I'm not stating
whether it can be made to work or not, I'm stating that it is an example
of PANA trying to do more than *network* level authentication and
enforcement.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 19 Sep 2006 22:58:28 +0300

> something of a link-layer) it is violating that layering. Bootstrapping

Is this really a layer violation? Considering that the inter-layer info
exchange is on the same stack that terminates the protocols, is this
considered a layer violation? 

I remember once Bernard (?) brought this up, and I had responded to that.
There was no follow up. I don't remember any further discussion on that.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 19 Sep 2006 19:44:28 -0400

On Tue, Sep 19, 2006 at 11:23:21AM +0300, Mark Townsley wrote:

(snip)

> paragraph or section vs. the Device IDs that actually cross the wire.

I am fine with leaving it out in the spec unless there is objection from others.

> or v6 /128) this would be independent of the "identity" of a given

I think you are talking about filtering parameters to be applied for a
given device.  In PANA, filtering parameters are not negotiated.
Instead, we tie an identifier that is supposed to be carried in every
packet originated from or destined to the network access client that
is authenticated using EAP.  That identifier is device identifier.
Based on this mapping between device identifier and network access
client, additional mapping between device identifier and detailed
filtering parameters can be made outside network access authentication
protocol.  This design approach is commonly used in link-layer
authentication/access control such as IEEE 802.1X, and PANA simply
follows the same approach.

> negotiate what traffic was allowed to flow from the PaC through the EP

Detailed filtering parameters are not negotiated in PANA.  If it is
needed, it can be done using other protocol, e.g., IKEv2.

Regards,
Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 Sep 2006 12:08:00 +0300

> follows the same approach.
OK, the text you had implied to me that filters would be created based
on an IP or MAC address (e.g., permit/deny traffic from the IP address
given by the Device ID). If this is not the case, please add some text
to make that clear (or point me to text that I missed that makes it
clear that filters are not negotiated in any way in PANA).

So, if I am hearing you now, the "Device ID" is a unique value exchanged
between the PAA and PaC. The value may be an IP address, MAC address, or
some other value by convenience, but is not used by the system in any
other way. Is that correct?
> needed, it can be done using other protocol, e.g., IKEv2.

That's unfortunate, IMHO, as it makes it very difficult to understand
exactly what the PAA is supposed to do with IP traffic based upon the
PANA authentication. Is there some history I am unaware of that directed
you in this decision?

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 20 Sep 2006 07:24:48 -0400

On Wed, Sep 20, 2006 at 12:08:00PM +0300, Mark Townsley wrote:

(snip)

> given by the Device ID). 

Yes, that is the case.

> If this is not the case, please add some text

We followed the PANA requirements described in Section 4.1.2 of RFC 4058:

"
   After a device is authenticated by using PANA, it MUST be authorized
   for "network access." That is, the core requirement of PANA is to
   verify the authorization of a PaC so that PaC's device may send and
   receive any IP packets.  It may also be possible to provide finer
   granularity authorization, such as authorization for QoS or
   individual services (e.g., http vs. ssh).  However, while a backend
   authorization infrastructure (e.g., RADIUS or Diameter based AAA
   infra) might provide such indications to the PAA, explicit support
   for them is outside the scope of PANA.  For instance, PANA is not
   required to carry any indication of the services authorized for the
   authenticated device.
"

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 21 Sep 2006 12:28:05 +0300

>    required to carry any indication of the services authorized for the

This approach is aligned with the other network access authentication
protocols. Future extensions may change that, but I think this is good
enough for now.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 21 Sep 2006 12:45:00 +0300

> other way. Is that correct?

Device ID has significance for per-packet access control. During the PANA
authentication, authenticated client ID (e.g., [email-masked]) is associated
with the client's access device. Following the PANA authentication, EPs rely
on Device IDs to police the client's traffic (they don't know "joe"). So,
the device ID has significance for the per-packet access control phase that
follows PANA authentication phase. Determination of device ID happens during
PANA authentication, but its actual use is for the next phase of operation. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 21 Sep 2006 13:23:35 +0300

> paragraph or section vs. the Device IDs that actually cross the wire.

I think it is better if we keep it in the text. Not mentioning
locally-significant DIs would leave people wondering about that case. We can
split a paragraph for clarification.

Alper

---

From: Mark Townsley <[email-masked]>
Date: Thu, 21 Sep 2006 14:22:09 +0300

> PANA authentication, but its actual use is for the next phase of operation. 
So, the Device ID *is* in fact a filter, albeit a very limited one.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 21 Sep 2006 15:47:21 +0300

> So, the Device ID *is* in fact a filter, albeit a very limited one.

The device ID and a cryptographic key (when present, as it's optionally
needed and used) are the input from PANA authentication phase to the
per-packet access control phase. The latter phase can take these and create
a simple "allow-all-traffic" filter; or it can create a more comprehensive
one via some negotiation. That's not part of PANA protocol.

Alper