Subject: [Pana] access control information in the EP

From: [email-masked]
Date: Thu, 23 Oct 2003 16:27:31 +0200

Hi all,

* Below is the DI definition quoted from [I-D.ietf-pana-requirements]:

    Device Identifier (DI)

         The identifier used by the network as a handle to control and
         police the network access of a client. Depending on the access
         technology, this identifier might contain any of IP address,
         link-layer address, switch port number, etc. of a connected
         device.

* Recent [I-D.ietf-pana-pana] states the following for the DI AVP:

    The first octet (8 bits) of the Device-Id (Code 1025) AVP data
    contains the device type. Rest of the AVP data payload contains the
    device data.  The content and format of data (including byte and bit
    ordering) is expected to be specified in specific documents.  For
    instance, [RFC2464].

             UNKNOWN                           0
             IPV4_ADDRESS                      1
             IPV6_ADDRESS                      2
             L2_ADDRESS                        3

    For type 1 (IPv4 address), data size is 32 bits and for type 2 (IPv6
    address), data size is 128 bits.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |           Data...                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

let's try to figure out what are the infos needed to be transported by 
the PAA-to-EP protocol (say SNMP...) with the following couple of questions:

1) In order to police the network access of a client at the EP, are 
source addresses sufficient ? should the EP be capable to identify a 
specific flow with, e.g. the IP 5-tuple (srcAddr, destAddr, srcPort, 
destPort, L4Prot) ?

2) When Type=L2_ADDRESS, what are the various possible underlying link 
layer for the access network ?
FYI, http://www.iana.org/assignments/ianaiftype-mib gives a pretty 
exhaustive ;-) list of underlying interface types via the IANAifType 
definition.

Thanks,
Yacine El Mghazli

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 23 Oct 2003 11:45:21 -0700

> specific flow with, e.g. the IP 5-tuple (srcAddr, destAddr, srcPort,

For basic network access authorization, source address based filtering is
sufficient (plus, the cryptographic binding where needed... which will
require to pass a key to the EP). I can see how one might want to extend on
this, especially if the AAA backend protocol is returning a detailed
authorization profile. In that case, in addition to being able to pass just
the source address, can we also pass a blob of data that contains a more
detailed filter? The format and usage details are not interesting for the
PAA2EP protocol, it just carries the stuff.

> exhaustive ;-) list of underlying interface types via the IANAifType

I don't think the list size of the specifics of each link-type would impact
the PAA2EP protocol design. You don't have to provide specific format for
each. You can follow the lead of what RFC2461 did on that:

        Link-Layer Address
                     The variable length link-layer address.

                     The content and format of this field (including
                     byte and bit ordering) is expected to be specified
                     in specific documents that describe how IPv6
                     operates over different link layers.  For instance,
                     [IPv6-ETHER].

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 23 Oct 2003 11:45:21 -0700

Link-Layer Address

Alper

---

From: [email-masked]
Date: Mon, 27 Oct 2003 10:45:03 +0100

Alper:

> PAA2EP protocol, it just carries the stuff.

OK then what is needed once the working group has agreed on the right 
candidate to use as the PAA-2-EP protocol (let's say SNMP) ?

SNMP transport generic objects: the content of these objects is 
determined by the specific MIB modules design. does PANA need such 
designs or only guidelines on the context using SNMP ?

>                      operates over different link layers.  For instance,

I think this lattest point is strongly related to the previous one.

> Alper

Thanks,
Yacine

---

From: [email-masked]
Date: Mon, 27 Oct 2003 10:45:03 +0100

Alper:

Thanks,
Yacine

---

From: Alper Yegin <[email-masked]>
Date: Mon, 27 Oct 2003 12:28:02 -0800

Hi Yacine,

> designs or only guidelines on the context using SNMP ?

At the end, a vendor needs to understand what exactly should be implemented,
and what appears on the wire between the PAA and EP. In that sense,
guidelines would not be sufficient (unless they point to specific object
definitions) for providing interoperability.

It might be the case that the objects we need are already defined and used
in a similar context. Than pointing out which ones should be used for this
purpose might be sufficient. Otherwise, we'd need to define new objects
specifically for the PAA2EP communication.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 27 Oct 2003 12:28:02 -0800

Hi Yacine,

Alper