Re: [LinkSec] IETF PANA
> There is a potential problem I'm identifying, but if it is ok for other
> PaC's on the same L2 segment to see each other's frames, then there is no
> issue.
PANA does not make a dedicated channel assumption. So, from its perspective
other hosts eavesdropping PANA traffic is not a threat to PANA (but maybe to
the EAP method used).
> I'm just pointing out that because there is no means to contain PANA
> frames on individual L2 segments, the traffic may show up in places that
> were un-intended.
If this is a concern, the operator can place the PAA closer to the STA, such
as on the AP or the switch. As long as these nodes have an IP stack, that's
OK. But aside from that, I'm still trying to understand how this situation
arises. Please see below...
> LLDP uses one of the BPDU multicast addresses and is
> therefore not forwarded by bridges in the L2 network. The addresses I'm
> referring to below are L2 multicast addresses, but the same 'flooding'
> effect is possible if they are L2 unicast addresses and unknown by the L2
> bridges.
The destination MAC address of the PANA messages are always unicast, except
for the initial discovery message (rightfully).
Alper
>> -----Original Message-----
>> From: Alper Yegin [mailto:alper@docomolabs-usa.com]
>> Sent: Thursday, July 24, 2003 7:49 PM
>> To: CONGDON,PAUL (HP-Roseville,ex1); Yoshihiro Ohba
>> Cc: 'Jim Burns'; stds-802-1@ieee.org; stds-802-linksec@ieee.org
>> Subject: Re: [LinkSec] IETF PANA
>>
>>
>> Hi Paul,
>>
>>> Thanks for the clarification. Regarding "flooding", I didn't mean
>>> between a STA and AP, I mean any L2 switch or set of
>> switches between
>>> the PaC and the PAA could potentially replicate and send the PANA
>>> packets out all ports if the destination address is not known or if
>>> the destination address is multicast and there is not a specific
>>> filter in place...
>>
>> I'm a bit confused about this. Is this "replication" a
>> feature you are looking for, or a problem you are
>> identifying? The destination address you are referring to, is
>> it a link-layer address or IP address?
>>
>> Thank you.
>>
>> Alper
>>
>>
>>
>>>
>>> Paul
>>>
>>>> -----Original Message-----
>>>> From: Alper Yegin [mailto:alper@docomolabs-usa.com]
>>>> Sent: Thursday, July 24, 2003 3:09 PM
>>>> To: Yoshihiro Ohba; CONGDON,PAUL (HP-Roseville,ex1)
>>>> Cc: 'Jim Burns'; stds-802-1@ieee.org; stds-802-linksec@ieee.org
>>>> Subject: Re: [LinkSec] IETF PANA
>>>>
>>>>
>>>> Hi Paul,
>>>>
>>>>>> I believe the PANA conversation is terminated at the first
>>>> router and
>>>>>> it is ok for PANA packets to be flooded everywhere on the
>>>> local LAN
>>>>>> segments between the node and the router.
>>>>>
>>>>> Just a minor note that PANA conversation can be terminated
>>>> not only at
>>>>> the first hop router but also at any IP node on the same
>> IP link as
>>>>> client IP hosts.
>>>>
>>>> Just to expand a bit more on what Yoshi said: The only
>> requirement of
>>>> PANA is that the client (PaC) and the authentication agent
>> (PAA) be
>>>> on the same IP-hop. As such, PAA can be on any one of the access
>>>> routers, or any one of the access points as well. Or even on a
>>>> separate dedicated server on that last hop. Appendix section in
>>>> http://ietf.org/internet-drafts/draft-ietf-pana-requirements-0
>>>> 7.txt covers all these scenarios.
>>>>
>>>> Btw, what do you mean by "flooding" PANA packets? Are you
>> asking if
>>>> one can send PANA messages between the STA and AP?
>>>>
>>>> Alper
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Paul
>>>>>
>>>>> Thanks,
>>>>> Yoshihiro Ohba
>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jim Burns [mailto:jeb@mtghouse.com]
>>>>>>> Sent: Thursday, July 17, 2003 4:09 AM
>>>>>>> To: stds-802-1@ieee.org; stds-802-linksec@ieee.org
>>>>>>> Cc: Alper Yegin; Yoshihiro Ohba
>>>>>>> Subject: [LinkSec] IETF PANA
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Folks,
>>>>>>> I sat down with the IETF PANA lead, Alper Yegin as well
>>>> as Yoshihiro
>>>>>>> Ohba and John Vollbrecht to discuss PANA. There is some
>>>> possibility
>>>>>>> that we can learn from each other and possibly find some places
>>>>>>> where our models/layers could exchange infomation. At the very
>>>>>>> least, we should be able to share some problem
>>>> definitions (probably
>>>>>>> best done by watching each other's email lists -- see below for
>>>>>>> details).
>>>>>>>
>>>>>>> A very fast and simplistic synopsis of the meeting is: What are
>>>>>>> the differences between 802.1X and PANA? PANA runs over IP and
>>>>>>> 802.1X runs over ethernet. PANA will work for the operators who
>>>>>>> have a link layer
>>>> that is not
>>>>>>> ethernet. This means that PANA passes its keying material on to
>>>>>>> IPSEC (while 802.1X passes its on to 802.11i and
>> perhaps 802.3 in
>>>>>>> the future). This means that PANA blocks at layer 3 --
>>>> blocking all
>>>>>>> but PANA packets (while 802.1X blocks at layer 2 all but eapol
>>>>>>> packets).
>>>>>>>
>>>>>>> For those who are textually challenged and prefer pictures:
>>>>>>> EAP
>>>>>>> +----------------+---------------------+
>>>>>>> | |
>>>>>>> 802.1X PANA
>>>>>>> | |
>>>>>>> ethernet IP
>>>>>>>
>>>>>>>
>>>>>>> The IEEE LinkSec info has been posted to the PANA site.
>>>>>>>
>>>>>>> Please see the IETF PANA group information below:
>>>>>>> To get on the IETF PANA email list:
>>>>>>> To Subscribe: pana-request@research.telcordia.com
>>>>>>> In Body: (un)subscribe
>>>>>>> Archive:
>>>>>>> ftp://ftp.research.telcordia.com/pub/Group.archive/pana/archiv
>>>>>> e
>>>>>> Let me know if you have any problems.
>>>>>> The IETF PANA home page is at:
>>>>>> http://www.ietf.org/html.charters/pana-charter.html
>>>>>> If you have trouble accessing it pleast let me know.
>>>>>>
>>>>>> Sincerely,
>>>>>> Jim B.
>>>>>>
>>>>>
>>>>
>>>
>>
>