Subject: [16NG] Review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Dec 2006 15:13:29 -0800

Review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

Overall Comments

On reading this document, it is not clear to me whether the SS
bridging functionality described can actually be implemented based
on IEEE 802.16e alone, or whether something else is required on the
SS and BS (such as 802.16k support).

Also, the behavior of the BS isn't described in much detail.  For example,
it's not clear to me how the BS is assumed to be able to forward frames
(can it VLAN tag?  Or does it only support GRE tunneling?)

The device that is described as a "bridge" does not seem to match very
well with the bridge capabilities defined in IEEE 802.1D.  Is the 
specialized
device described really necessary for implementation of IP over Ethernet CS?
If alternative implementations are possible, then does the material in 
Section 7
really belong in this document, or perhaps another "deployment 
considerations"
document?

Section 4.4

   Note that there may be additional MAC addresses behind SSs when SSs
   act as bridge connecting networks behind the SSs.  The additional MAC
   addresses may be also discovered when there is a controlled link
   state for the hosts behind the SS and the SS performs authentication
   of the link, e.g. by running IEEE 802.1X on the SS.

While the SS might discover MAC addresses behind it via learning,
or IEEE 802.1X, how is this information to be transmitted to
and used by the BS for security purposes?  My understanding is that
the BS maintains a table mapping each MAC address to keys used to
encrypt/decrypt traffic.  Since the IEEE 802.16e handshake does not
enable a SS associate a single key with multiple MAC addresses,
it would seem that if the SS forwards frames from other sources
behind it to the BS, that the BS will silently discard them.
Or are we assuming additional functionality on the BS beyond
what is in IEEE 802.16e?

   BS can construct link local address of each SS from adding prefix
   "FE80::/64" to last 24 bits of MAC address corresponding to the each
   SS and also derive solicited-node MAC address of each SS from prefix
   "33-33-FF" and last 24 bits of each SS's MAC address.

Why does the BS need to construct SS addresses?  The  need for this
isn't described elsewhere in the document.  Also, this assumes that the
SS does not desire privacy or that DHCPv6 isn't being used to assign
addresses.  My recommendation would be to delete this material since
it doesn't seem necessary.

Section 5.1

   Ethernet is realized on
   top of IEEE 802.16 by implementing bridging between all SSs with IEEE
   802.16 providing the links between the hosts and the bridge behind
   the BS like the twisted pair wires used in today's switched Ethernet.

Initially on reading this section I had assumed that the BS was forwarding
VLAN-tagged frames to a conventional IEEE 802.1D bridge, but as the
document went on, I realized that this was not a valid assumption.

You might state explicitly that the BS is assumed *not* to act as Bridge,
leaving this to the bridge it is connected to.  It also might be helpful to
describe the capabilities of the BS in more detail, describing how packets
are sent and received.  For example, on reading the document I wasn't
clear where non-forwardable multicast frames (such as those used by
IEEE 802.1X) would terminate.  On the BS?  On the Bridge?

Section 5.2

   Ethernet is emulated on top of IEEE 802.16 without making use of MBS
   as defined in 6.3.23 of [IEEE802.16e] to allow full control over the
   reaction of SSs to broadcast messages.  Instead of using MBS,
   broadcast and multicast messages are transferred in a unicast manner.

Please expand the term "MBS".  This paragraph seems to imply that
IP multicast/broadcast packets are sent as L2 unicast frames, and
that the BS replicates a multicast packet to each SS that is a member
of a given VLAN.  You might state this explicitly.

Section 5.3

   The BS SHALL forward all the radio connections belonging to one SS to
   a port of a bridge between all ports on the radio side and the
   interfaces towards the network side.  If the SS functions as a bridge
   then it SHALL support a bridging between all its LAN ports and the
   airlink.

"Radio connections" refers to all the CIDs allocated to a given SS, right?
Given IEEE 802.16e key management, what keys will the BS use to encrypt
frames forwarded to the SS?

   When performing bridging, any packets destined for one of the
   addresses in the Filtering Database SHALL be forwarded directly to
   that port, if appropriate for the particular scenario, and all
   packets received from a port, for which the packet's destination MAC
   address is also an entry for that port in the Filtering Database,
   SHALL be silently discarded.

Is it assumed that the SS also implements STP/RSTP?

Section 6.2

The figure should probably show the AR as a "one armed router" with
multiple virtual interfaces, one for each VLAN.

Also the Bridge links should probably be labeled with different VLANs,
(e.g. BS1 - Bridge link as "VLAN1", BS2 - Bridge link as "VLAN2", etc.).

Section 7.1

   Unicast 802.16 transport connections are extended to a bridge by any
   tunneling mechanism such as GRE tunnel between BSs and the bridge.
   As a result, point-to-point connections have been established between
   a bridge and each SSs.

Off-the-shelf bridges will not implement GRE or other tunneling protocols.
Can the BS decapsulate the frames, tag them with a VLAN and
forward to the bridge?  Or is it assumed that it can only GRE tunnel them?

Section 7.2

   If filtering is enabled the bridge SHALL permit all Address
   Resolution Protocol messages to pass to the ARP Proxy Agent and all
   Neighbor Discovery messages to pass to the Neighbor Discovery (ND)
   Relay Agent for additional processing as specified in following
   section.

IEEE 802.1D bridges often don't support layer 3 filtering capability.
So filtering ARP frames by Ethertype is feasible, but layer 3 filtering
for ND would require layer 3 filtering capability, which may not be
present.  Or is the "bridge" really a more sophisticated (and expensive)
device?

Section 7.3

   The bridge establishes and maintains information about each SS by the
   mean of an Identification Cache Table (ICT), which is an extension of
   the Filtering Database.  Note that the bridge in this document
   supports IGMP/MLD Snooping [RFC4541].

Do you really mean "each SS" here, or does this also include all the hosts
behind the SS.  If the latter, this is accomplished via learning, right?

   For IPv4 over Ethernet, ICT contains MAC address and Port Map, which
   constitute a filtering entry in Filtering Database, tunnel ID,
   lifetime, and one or more unicast and multicast IPv4 addresses.  The
   unicast IPv4 addresses can be learned by examining the source address
   of packets or DHCP Response message.  The multicast IPv4 address can
   be added and removed by snooping IGMP Membership Report and Leave
   Group messages from SS.

Looking at the figure, it seems like the BS is attached to a single
bridge port.  If so, then how is the bridge to carry out IGMP snooping?
Don't all the SSes look like they are attached to a single bridge port?

   The ARP Proxy Agent and the ND Relay Agent functions are based on
   information contained in the ICT.  Figure 5 and Figure 6 show the ICT
   for IPv4 over Ethernet and IPv6 over Ethernet.

Most bridges don't include support for ARP proxy or ND relay, right?

Section 8.1.1

   The bridge SHALL support an ARP Proxy.  The bridge SHALL have the
   ability to enable or disable the ARP Proxy.

Why is an ARP Proxy necessary?  This might be more clear if the
operation of the BS is more clearly described.

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: "David Johnston" <[email-masked]>
Date: Wed, 20 Dec 2006 16:28:20 -0800

Bernard,
I think you've raised a lot of valid issues.

My comments are inline...

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 3:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [16NG] Review of
draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

Overall Comments

<DJ>
16k is definitely needed. It describes how the 802.1D ISS maps onto the
802.3 CS SAP, describes exactly what the 802.3 CS SAP looks like, by
reference to the 802.3 spec and describes what type of link it provides
(a point to point LAN as described in 802.1D-2004 section 6.4.3. Before
16k, this was a matter of assumption rather than specification.
</DJ>

Also, the behavior of the BS isn't described in much detail.  For
example,
it's not clear to me how the BS is assumed to be able to forward frames
(can it VLAN tag?  Or does it only support GRE tunneling?)

<DJ>
The BS should not concern itself with vlan tagging. That is for a VLAN
capable bridge to embed within the payload of the 802 ISS primitive and
hand down to the BS through the 802.3 CS SAP. 16k Creates the conditions
under which we know how to do this I.E. through the 802.3 CS using the
802.3 Ethertype field to know what is in the payload. 
</DJ>

device described really necessary for implementation of IP over Ethernet
CS?

<DJ>
The thing called a bridge I think should explicitly made clear is an
802.1D Multi Port Relay. It is not *needed* for IP over Ethernet, but in
that case you will have at least one port per SS terminating into an IP
stack or router. 802.16 doesn't (and shouldn't) define forwarding rules
between the SSs. The bridge does that. So the bridge provides a handy
way of turning those multiple point to point links into one spigot of a
bridged LAN on which reside all the SSs and over which ARP can run in
the usual way.

It seems logical to me that the choice whether to bridge all SSs, or
have subsets of the SSs bridged independently or any other configuration
is an implementation decision for the BS-Bridge-IP product, with the
consequences of those decisions well explained by 16ng, so I think I
agree with the notion that this is deployment consideration material.
</DJ>

Section 4.4

<DJ> That would be verboten behavior. It is not for the BS to route or
discard based on MAC address. It is for the bridge. Similarly it is the
bridge that might find MAC addresses through learning. I don't see that
802.1X is any way to identify MAC addresses behind an interface. It is a
way to authenticate and authorize the port identified by the MAC address
of the NIC on the port, not the addresses behind it. So we are assuming
less functionality, not more : THE BS DOESN'T MESS WITH MAC ADDRESSES,
except for implementations that do it anyway because they know it won't
be a problem - e.g. they know the SS is a leaf node. 
</DJ>

<DJ> Agree. The situation is the same as any other bridged LAN </DJ>

Section 5.1

   Ethernet is realized on

Initially on reading this section I had assumed that the BS was
forwarding
VLAN-tagged frames to a conventional IEEE 802.1D bridge, but as the
document went on, I realized that this was not a valid assumption.

You might state explicitly that the BS is assumed *not* to act as
Bridge,
leaving this to the bridge it is connected to.  It also might be helpful
to
describe the capabilities of the BS in more detail, describing how
packets
are sent and received.  For example, on reading the document I wasn't
clear where non-forwardable multicast frames (such as those used by
IEEE 802.1X) would terminate.  On the BS?  On the Bridge?

<DJ> You don't need to tell me that the BS is assumed not to act as a
bridge, since I'm steeped in 802 architectural rules, but it seems that
lots of people don't know this, so it's worth repeating.

Non-forwardable multicast frames would terminate consistent with the LLC
behaviour. With 802.1X in place, there would be a place for them to go
just above the MAC and LLC, regardless of the presence of a relay
entity. Although why you would send EAPoL over 802.16 is beyond me when
it provides an out of band transport for EAP that avoids the race hazard
problems with keys. I don't think that this is for 16ng to define.
</DJ>

Section 5.2

<DJ>
The bridge does the replication. MBS is a specific 802.16 transport type
that is downlink broadcast only and doesn't really fit with what 16ng is
describing. An IP broadcast packets would typically end up with a
broadcast MAC address sent over a unicast 802.16 connection. I've
commented elsewhere about the need to be clear about the distinction.
</DJ>

Section 5.3

"Radio connections" refers to all the CIDs allocated to a given SS,
right?
Given IEEE 802.16e key management, what keys will the BS use to encrypt
frames forwarded to the SS?

<DJ> I think this text is confusing due to the use of non standard
terms. Isn't it packets that are forwarded, not connections? If I
interpret it right, I don't think it is allowed say what it is saying.
If I have a bridge at the SS, it can have all sorts of 802.1 specified
mechanisms for traffic and port segregation, like say, VLANs.
<DJ>

<DJ> No. This is an option for a bridge. I don't think we can mandate
such things. I think what perhaps should be said is something to the
effect - Bridging happens as per 802.1D, but it would be a really good
idea to make use of filtering to prevent unnecessary traffic flooding to
SSs that are leaf nodes (don't have a bridge).
</DJ>

Section 6.2

Section 7.1

Off-the-shelf bridges will not implement GRE or other tunneling
protocols.
Can the BS decapsulate the frames, tag them with a VLAN and
forward to the bridge?  Or is it assumed that it can only GRE tunnel
them?

<DJ> I think it's unfortunate that this level of allocation of function
to boxes exists. If the ports to MSs should bolt to bridge ports, let
them, but don't specify how. The bridge could be embedded in the BS,
hooked up by multiple Ethernet cables, hooked up through a GRE tunnel or
one of any number of other options.
<DJ>

Section 7.2

<DJ>
Isn't the filtering mentioned actually MAC address filtering, as per the
well defined filtering function in 802.1D, not ethertype or L3? So it's
ok, it won't filter ARP or ND. 
Better to be explicit and say .. Thou shalt filter neither ARP nor ND if
you want them to work.
Again I think this is a case of the assumptions well known to an 802
person being not obvious to the wider world.
<DJ>

Section 7.3

Do you really mean "each SS" here, or does this also include all the
hosts
behind the SS.  If the latter, this is accomplished via learning, right?

<DJ> Right </DJ>

<DJ> No. Each SS is attached to a separate bridge port. This isn't
802.11. This should be made clear. </DJ>

Section 8.1.1

<DJ> I don't think it is necessary unless the deployer feels the need to
deploy it for the usual reasons. This "You must have feature x but allow
the user to turn it on and off" sounds more like the domain of WiMAX
equipment requirements than IETF requirements.
</DJ>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Dec 2006 18:04:52 -0800

>My comments are inline...

Thanks for your reply.  The additional information you provided is very 
helpful.

>16k, this was a matter of assumption rather than specification.

I thought so; my suggestion would be for IEEE 802.16k to be listed as a 
normative reference.

>bridged LAN on which reside all the SSs and over which ARP can run in

This makes a lot of sense.

>agree with the notion that this is deployment consideration material.

Agreed.

>802.1X is any way to identify MAC addresses behind an interface.

I didn't understand that either.

>It is a

The part I'm missing is how the BS decides what keys to use to decrypt a 
frame sent by the SS.  Does it use the source MAC address (as in IEEE 
802.11i) or the CID to find the right key?  The document seems to assume 
that the BS is able to decrypt frames sent to it by the SS that originate 
from behind the SS.  But I'm missing how these frames are to be 
encrypted/decrypted.

>be a problem - e.g. they know the SS is a leaf node.

Is it correct to say that IEEE 802.16e assumes that the SS is a "leaf node" 
but that IEEE 802.16k allows this to be negotiated?  How does this interact 
with payload header compression?

><DJ> Agree. The situation is the same as any other bridged LAN </DJ>

OK.

>lots of people don't know this, so it's worth repeating.>

OK

>commented elsewhere about the need to be clear about the distinction.

That makes sense to me.

><DJ> I think this text is confusing due to the use of non-standard

I agree that the text is confusing.

>SSs that are leaf nodes (don't have a bridge).

I'd like the spec to address cases where the SS is a "leaf node" and also 
cases where it is a bridge, being clear about what is assumed in both cases. 
  For example, can the "leaf node" case be handled with IEEE 802.16e, 
without requiring IEEE 802.16k?  Or do all cases require support for IEEE 
802.16k?

>one of any number of other options.

I agree that this should not be specified in this document.

>person being not obvious to the wider world.

I wasn't clear from reading the document exactly what kind of filtering was 
being referred to.

>802.11. This should be made clear. </DJ>

That makes sense.

>equipment requirements than IETF requirements.

Right.  I wasn't clear why the specification needed to get into this level 
of detail.

---

From: "David Johnston" <[email-masked]>
Date: Wed, 20 Dec 2006 19:18:55 -0800

Bernard.
Second iteration responses below:

Bernard wrote:

<DJ> I expect the current draft (D4) of 16k to be the final one and it
will be approved soon, so we can probably reference 802.16k as an
approved standard within a couple of months.</DJ>

----

that the BS is able to decrypt frames sent to it by the SS that
originate 
from behind the SS.  But I'm missing how these frames are to be 
encrypted/decrypted.

<DJ> 802.16's link security protocol sets up security associations
(SAs). These are boxes that hold keying material following an
authentication and key exchange. There can be more than 1 SA, but
there's not much point for purely unicast traffic. When connections are
established, an existing SA is chosen for that connection. The keys from
that SA are used to protect MAC PDUs on that connection.

So yes.. It is the CID that is used to find the SA that supplies the
keys.
This happens between the SS and BS within the MAC. Frames can bridge
into to SS, get encrypted by the SS, go over the air, get decrypted by
the BS MAC and pop up out of the MAC CS SAP in plaintext. Similarly in
the other direction.

802.16's security does not care if the packet came from the LLC or the
relay entity, it treats it the same.

802.11 uses MAC addresses to identify the STA sender (not the source)
and so find the key. In uplink traffic, the DA and TA are the same. This
is a violation of the 802 rules and this is why you can't put a bridge
in a STA without pulling some stunts, like forcing the use of 4 address
frames (where TA and RA serve the function of the CID in 802.16). We
explicitly avoided this error in 802.16, based on hindsight that 802.11
facilitated.
</DJ>
 
---

>be a problem - e.g. they know the SS is a leaf node.

Is it correct to say that IEEE 802.16e assumes that the SS is a "leaf
node" 
but that IEEE 802.16k allows this to be negotiated?  How does this
interact 
with payload header compression?

<DJ> It is not correct to say that 802.16e assumes the SS is a leaf
node. 802.16k assumes that the SS might have a bridge and acts
accordingly. It doesn't interact with payload header suppression, that
is below the MAC service and nothing above the MAC service should care.

I don't know how leaf node determination is made. I had a conversation
with the 802.1 luminaries at the last IEEE meeting and argued that leaf
node determination was needed in 802.1 protocols to allow this sort of
efficiency saving in wireless systems.

Their response was that it is already in there and so bridges can be so
configured based on leaf node determination. I have no reason to doubt
them, but I haven't yet researched and found what bit of what standard
describes it.
</DJ>

----

>SSs that are leaf nodes (don't have a bridge).

I'd like the spec to address cases where the SS is a "leaf node" and
also 
cases where it is a bridge, being clear about what is assumed in both
cases. 
  For example, can the "leaf node" case be handled with IEEE 802.16e, 
without requiring IEEE 802.16k?  Or do all cases require support for
IEEE 
802.16k?

<DJ> Me too. However, I'd like 802.1 to determine the method of leaf
node determination, since the follow on action is to modify the behavior
of the 802.1D bridge. As above, 802.1 members say this is done, but I
don't know the details.

802.16k is not really required by anything except a bridge or other user
of the 802.1D Internal Sublayer Service. However if you're using the
Ethernet CS, it has a one line statement that the 802.3 CS service is
the same as the 802.3 MAC service. This could and should have been said
in the 802.3 CS text but it wasn't. The other 99.9% of 802.16k exists to
make things right when an 802.16 MAC is bolted onto a bridge port. Given
the expectation of the use of bridges in SSs and BSs, 16k turns out to
have been quite timely.

</DJ>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Dec 2006 10:42:47 +0100

David Johnston and Bernard Aboba commented on ETHCS document:
[many parts removed, as to fork to a separate topic]
>>> document's Section 4.4
>>> 
>>> Note that there may be additional MAC addresses behind SSs when 
>>> SSs act as bridge connecting networks behind the SSs.  The 
>>> additional MAC addresses may be also discovered when there is a 
>>> controlled link state for the hosts behind the SS and the SS 
>>> performs authentication of the link, e.g. by running IEEE 802.1X 
>>> on the SS.
>> 
>> or IEEE 802.1X, how is this information to be transmitted to and 
>> used by the BS for security purposes?  My understanding is that the
>>  BS maintains a table mapping each MAC address to keys used to 
>>  enable a SS associate a single key with multiple MAC addresses, it
>>  would seem that if the SS forwards frames from other sources 
>> behind it to the BS, that the BS will silently discard them. Or are
>>  we assuming additional functionality on the BS beyond what is in 
>> IEEE 802.16e?
> 
> <DJ> That would be verboten behavior. It is not for the BS to route 
> or discard based on MAC address. It is for the bridge. Similarly it 
> is the bridge that might find MAC addresses through learning. I don't
>  see that 802.1X is any way to identify MAC addresses behind an 
> interface. It is a way to authenticate and authorize the port 
> identified by the MAC address of the NIC on the port, not the 
> addresses behind it. So we are assuming less functionality, not more
>  : THE BS DOESN'T MESS WITH MAC ADDRESSES, except for implementations
>  that do it anyway because they know it won't be a problem - e.g.
> they know the SS is a leaf node. </DJ>

I am lacking understanding of the deployment scenarios needed by
non-leaf SS (subscriber station), as planned in the .16 space.

For example, is it imagined that when SS is non-leaf it's about a wimax
pcmcia/express card into a laptop?  The non-leaf SS would be the card
and the laptop would be a leaf node?  Or is it that the SS is an
antenna/receiver on the house roof and the leaf is the family multimedia
MAC?  Or is it that the SS is a multimode cell phone and the leaf is a
PDA attached to it?

Because some of those scenarios can be addresses by networking protocols
(above link-layer) where the security context is relatively more
cleared, relying on IPsec.  Ie the SS would not be a bridge but a router.

This comes to mind when reading that 'a bridge SS may connect networks
behind it'.  Just felt I had to mention this.

Alex

---

From: "David Johnston" <[email-masked]>
Date: Thu, 21 Dec 2006 09:29:29 -0800

> MAC?  Or is it that the SS is a multimode cell phone and the leaf is a

In the context of this discussion, by leaf-node, I mean the 802 MAC SAP
terminates upwards into a higher layer protocol, like IP.

By non leaf-node I mean the 802 MAC SAP has a relay entity attached
(I.E. Is a port into an 802.1D bridge.

The difference is important because a bridge needs to perform address
learning. To do this it needs to see all the traffic any bridge at the
other end of the link chooses to send. So if the MAC filters or routes
based on MAC address, it will interfere with this learning capability.

DJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Dec 2006 17:33:24 +0100

David Johnston wrote:
>> pcmcia/express card into a laptop?  The non-leaf SS would be the 
>> card and the laptop would be a leaf node?  Or is it that the SS is 
>> an antenna/receiver on the house roof and the leaf is the family
> multimedia
>> MAC?  Or is it that the SS is a multimode cell phone and the leaf 
>> is a PDA attached to it?
>> 
> 
> In the context of this discussion, by leaf-node, I mean the 802 MAC 
> SAP terminates upwards into a higher layer protocol, like IP.
> 

Thanks, very illustrative mentally, got it.

>  learning. To do this it needs to see all the traffic any bridge at 
> the other end of the link chooses to send. So if the MAC filters or 
> routes based on MAC address, it will interfere with this learning 
> capability.

Would IPv6 run the same way over non-leaf's egress interface as over
ingress interface.  Or there'd be no IPv6 stack on a non-leaf SS.

I'm tempted to think IPv6overETHCS is only concerned about leaf node SS,
ie its 802 MAC SAP terminates upwards into IP.

Alex

---

From: "David Johnston" <[email-masked]>
Date: Sat, 23 Dec 2006 11:53:48 -0800

>From above, looking into an 802 LLC, IP sits upon either a point to
point link, a shared media LAN or a bridged LAN with a mix of 802 media.
In the 802 view, it shouldn't care.. It might be a LAN with multiple
endpoints and IP will do ARP to find the right MAC address.

The reason leaf-node determination is an issue is that the draft
suggests we use a bridge in the BS and configure it to filter L2 traffic
in a particular way. To know how to filter, you need to know if a port
has a single MAC address at the other end. The reason for wanting to do
this is because we don't want normal bridging behavior to flood traffic
over resource constrained wireless links.

The same situation exists on normal 802.3 Ethernet, but we don't worry
about this issue because we don't care if a few extra packets fly over
an Ethernet wire.

So from a formal layering standpoint, IPv6overEthCS does not know about
leaf-node-ness or bridged-ness of L2, but the IPv6overEthCS draft does
indeed delve right into L2 bridges and specifies how to set things up at
L2. I'm a little uncomfortable with this.

DJ