Subject: Re: [Pana] Regarding Pana New PaC L2 Notification

From: [email-masked]
Date: Thu, 02 Mar 2006 17:55:07 +0100

hello nagaraju,

thank you very much for your feedback and pertinent comments. please see
below the answer:

Nagaraju wrote:
> If an EP uses an L2 based filtering and device IDs of PaC and EP are
> mac addresses then in such a scenario, when an unathorized PaC starts
> sending data, EP will drop those packets and sends
> panaNewPaCL2Notification to PAA using snmp notification operation.
> 
> panaNewPaCL2Notification is defined in the draft
> draft-ietf-pana-snmp-05 as
> 
> panaNewPacL2Notification NOTIFICATION-TYPE OBJECTS { 
> spdActionExecuted, panaEpIfIndex, panaL2SourceAddress } STATUS
> current DESCRIPTION "Notification that EP detected L2 traffic coming
> from an unauthorized source. " ::= { panaNotifications 2 }
> 
> When PAA receives NewPaCL2Notification it has to send PSR to EP.
> 
> But : 1.How can PAA send PSR to PaC when it knows only
> spdActionExecuted, panaEpIfIndex, panaL2SourceAddress (i.e, PAA does
> not know IP address of PaC yet)?

[from julien:]

If PaC has an autoconfigured address (autoconf in IPv6 or zeroconf in
IPv4) the EP should send the IP address.

If PaC hasn't an IP address, it will use DHCP (?), in this case we have
a trouble because the DHCP request will trigger the authentication while
PaC hasn't IP address. I think that the PAA shouldn't send PSR if no IP
address is available in the Notification.

> 2.Why does EP need to send its PaC's L2SourceAddress to PAA?(i.e.,
> why PAA needs to know L2 address of PaC?)

[from yoshi:]

Probably panaNewPacL2Notification is not needed for the purpose of
unsolicited PAA discovery. On the other hand, panaNewPacL2Notification
may be useful when the PaC is roaming among APs (EPs) of the same PAA's
realm once after a PANA session is established. The L2Notification can
be a trigger to reactively fetch the PaC-EP-Master-Key when the PaC
associated with an AP.

> 3.Does EP need to send panaNewPaCIPNotification also even when EP
> does L2 based filtering?(How else can PAA know PaC's IP address)

PaCIPNotification should (MUST) be used for PANA unsollicited Discovery
and if the IP address is empty, the PAA MUST discard the message.

We will update the SNMP document accordingly.

> Thanks&Regards, Nagaraju.

BR,
yacine, on behalf of the co-authors.

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

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

---

From: Nagaraju <[email-masked]>
Date: Fri, 03 Mar 2006 11:20:18 +0530

Hi Yacine,
     Please find comments inline.

> address is available in the Notification.

Do you mean IP address will be part of  NewPaCL2Notification?
It is not clear, in case of L2 based filtering, whether PaCIPNotification
should be used for unsolicited PAA Discovery or
L2Notification,with an IP address included, should be used.

> be a trigger to reactively fetch the PaC-EP-Master-Key when the PaC
So is this an on-demand filter installation?(i.e, PAA will install filter(in
which
PaC-EP-Master-Key is included) after receiving L2Notification from EP.)

If yes,  and panaNewPaCL2Notification is used only as a trigger for
fetching PaC-EP-Master-Key, then L2Notification  is not used at all
when a PAA installs filters on all the EPs after successful PANA
authentication
(In this case, as EP already has the filter information it does not send
L2Notificaton at all).

> and if the IP address is empty, the PAA MUST discard the message.

panaNewPacIPNotification contains the following objects spdActionExecuted,
spdIPEndpointAddType, spdIPEndpointAddress, spdIPSourceType,
spdIPSourceAddress,   spdIPDestinationType, spdIPDestinationAddress.

Hence, when IP address of PaC is not available, EP need not send
panaNewPaCIPNotification to PAA.

> yacine, on behalf of the co-authors.

Regards,
Nagaraju

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 3 Mar 2006 09:23:41 +0100

Hi,

> L2Notification,with an IP address included, should be used.

 I tend to think that, based on this discussion we should delete the
 NewPaCL2Notification because without IP address the PAA can't send PSR
 to the PaC.

 So I would suggest that NewPaCL3Notification should always be used and
 that if no IP address is available, either the EP does not send the
 notification or send it with IP address set to 0. In the latter case,
 the PAA simply does not send PSR.

 So, for unsolicited PAA Discovery, my suggestion is to always used
 NewPaCL3Notification.

 Would it clarify ?

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: [email-masked]
Date: Fri, 03 Mar 2006 11:32:55 +0100

Julien, Nagaraju,

Ok to have one single IP Notif, provided that the remark of Yoshi on 
roaming is clarified. more generally: is it necessary to notify the PAA 
with the unauthorized PaC L2@ to the PAA ?

thanks,
yacine

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 03 Mar 2006 09:37:20 -0500

> PaC-EP-Master-Key is included) after receiving L2Notification from EP.)

Yes.

> (In this case, as EP already has the filter information it does not send

This is also true.  On the other hand, sometimes on-demand key
installation might be useful to allow the key to be installed 
only when the PaC actually is attached to the EP.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 03 Mar 2006 09:45:30 -0500

> with the unauthorized PaC L2@ to the PAA ?

I think that the security level of the L2 notification is the same as
notifying unauthorized PaC's IP address to the PAA.  Also, even if the
key is installed to the EP as a result of on-demand keying triggered
by an attacker PaC who spoofs legitimate PaC's L2 address but does not
have the key, the impact of such a DoS attack is small as long as the
EP discards the key immediately after subsequent secure association
fails.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 3 Mar 2006 15:44:14 +0100

hi yoshi,

 two questions below,

> only when the PaC actually is attached to the EP.

 Is this on-demand key installation described somewhere ?

 Would  it be possible to use the L3Notif instead of the L2Notif ?

 thanks,

 -- Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 03 Mar 2006 14:40:50 -0500

>  Is this on-demand key installation described somewhere ?

It is described in draft-marin-pana-ieee80211doti-00.

>  Would  it be possible to use the L3Notif instead of the L2Notif ?

That is also possible when EP is doing IPsec ciphering.

Yoshihiro Ohba

---

From: Nagaraju <[email-masked]>
Date: Mon, 06 Mar 2006 11:59:01 +0530

Hi Yoshi,

    So we can use panaNewPaCL2Notifiaction only for on-demand key
installation (if at all required).
And panaNewPaCIPNotification can be used for traffic-driven discovery
when L2 based as well as IPSec based access control is used.
panaNewPaCIPNotification can also be used for on-demand filter installation
in case of IPSec based access control.
Am I correct?

But how can EP decide when to send panaNewPaCL2Notification
(i.e., traffic is from a PaC for which PAA has a session but EP does not
have a key)
and when to send panaNewPaCIPNotification ( i.e, traffic is from a PaC for
which
PAA does not have a session and EP does not have a key)?

In this case EP has to send both Notifications to make sure that
PAA either starts PANA session(if session does not exist) or PAA
installs filter on EP (if session exists).

And in L2Notification:
Is EPIfIndex is unique?
How can PAA know which EP it has to respond to,
in case more than one EP have same interface index in L2Notifiation?

And also when we use Notifications as trigger for on-demand key
installation,
Notication implimentation becomes MUST instead of MAY.
Notification is OPTIONAL when PAA installs filters on all EPs after
successful authorization of PaC.
Notification becomes MUST as EP does not know the traffic is
coming from an unauthrized PaC(in this case EP may wish either send or
not to send Notification to PAA)
or  from an authorized PaC but with no key on this EP from PAA yet (in
this case EP MUST send a Notification to PAA to get key information).

I think it is better if we use only one form of notification which will be
used for both
L2 and IPSec based access control. This single notification should contain
information required for both access controls and should suffice for PAA to
ither to start a session or install filter.

Currently PAA is supposed to send PSR when it gets a new PaC notification
and session does not exist. Now PAA should behave differnetly and this
should be captured in the draft.

And is EP supposed to allow DHCP traffic?

Nagaraju

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 7 Mar 2006 11:09:12 -0500

Hi Nagaraju,

Yes.

> PAA does not have a session and EP does not have a key)?

EP does not need to know whether the PAA has a session with the
detected PaC.  Please see below.  

> installs filter on EP (if session exists).

Yes.  I can explain this as follows:

An EP which does L2 ciphering can send panaNewPaCL2Notification to the
PAA whenever it finds an L2 address for which key is not installed
yet, and the PAA will send a key to the EP if it has a session
associated with the L2 address reported from by EP or ignore the
notification otherwise.  In addition, the EP can send
panaNewPaCIPNotification to the PAA whenever it finds an IP address of
an unauthorized PaC to trigger unsolicited PAA discovery.

Similarly, an EP which does IPsec ciphering can send
panaNewPaCIPNotification to the PAA whenever it finds an IP address of
a PaC for which key is not installed yet, and the PAA will send a key
to the EP if it has a session associated with the IP address reported
from by EP or otherwise it can send a PSR to the PaC.  On the other
hand, I suspect that on-demand key installation is not likely be used
for IPsec ciphering with the current form of panaNewPaCIPNotification,
because PaC's IP address will typically change when the PaC moves to
other subnet and the PAA will not be able to find an existing session
based solely on the PaC's IP address.  Probably ID_KEY_ID for the PaC
may need to be reported from EP for on-demand key installation for
IPsec.

> in case more than one EP have same interface index in L2Notifiation?

It has to be unique within a particular SNMP engine id corresponding
to the EP.  But it does not have to be unique across multiple EPs.

Yes.

Yes.

> this case EP MUST send a Notification to PAA to get key information).

This boils down to the on-demand key installation case.  So it would
be a MUST.

> ither to start a session or install filter.

I think we need more discussion before coming to this conclusion.

> should be captured in the draft.

I agree that the detailed behavior described above should be described 
in the draft.

> And is EP supposed to allow DHCP traffic?

In terms of pana-framework, yes.  OTOH, Section 5.2 of
draft-marin-pana-ieee80211doti-00.txt describes another case in which
DHCP is not allowed to pass EP before authentication succeeds.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 09 Mar 2006 01:17:02 -0500

Hi all

I have tried to follow this discussion becuase it looks very interesting

As a general comment in draft-marin-pana-ieee80211doti-00.txt, the
on-demand key installation was considered as a way of optimization to avoid
to install different keys in different Access Points(EP) even when PaC
could not move to that access points. This fact might be even worse ,
for example,
if we considered pre-authentication.

Although in the initial version of draft-marin-pana-ieee80211doti-00.txt
there is no reference to PANA SNMP, I completely support that PANA-SNMP
should reflect some kind of notification for on-demand key installation.
Additionally as it is being discussing this mechanism is not something
particular of PANA and link-layer devices as Access Points and it might
be also useful when EP are layer 3 devices.

Please see some additional comments inline...

>an unauthorized PaC to trigger unsolicited PAA discovery.
This description makes sense for me.

>based solely on the PaC's IP address.  
>
I think also a motivation to add a panaNewPaCL2Notification to trigger
key installation is PaC might not be able to contact with PAA becuase
link-layer device may not allow any IP traffic passing through. Thus the
only way to notify to PAA is EP sends some kind of notification.

However if EP allows PANA traffic (which is expected in case EP is an
AR), PaC might use PUR-PUA exchange to key installation. I think it is
possible when MN moves to a new EP/AR, PaC will try to update his new IP
address with PAA which means a PUR-PUA. When PAA receives PUR it could
also install a key.

>Probably ID_KEY_ID for the PaC
This ID-KEY-ID would include Session-Id | Key-Id as PANA-IPsec specifies??.

(Btw, I am thinking that in case of pre-authentication
panaNewPaCIPNotification might not require ID_KEY_ID)

>I agree that the detailed behavior described above should be described 
I don't know if for example on-demand key installation behaviour should
be specified here but at least to say those notifications may be used
for different management/administrative tasks (i.e. key installation)
could be enough.

My 2 cents.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Nagaraju <[email-masked]>
Date: Wed, 08 Mar 2006 14:50:43 +0530

Hi Yoshi,

    In on-demand key installation in IPSec ciphering case, EP would
not be able to send ID_KEY_ID as it does not have that information
when a PaC is not authenticated. I think IP address of PaC is enough
for PAA to find out whether it already has a session. Because if IP address
of a PaC changes, it sends PUR, and PAA now knows the new IP address
of the PaC. And when PaC tries to access the network with the new address
EP will send a panaNewPaCIPNotification with the new IP address  and
PAA can install filter.

> to the EP.  But it does not have to be unique across multiple EPs.

    So do you mean PAA  (along with Trap receiver) should have knowledge of
snmp engine IDs? I mean, should PAA distinguish requests based on snmp
engine IDs
(for which it has to keep a mapping of EP's Mac and snmp engine IDs)  Or
is it out of scope of PANA how a PAA is notified of EP's mac by an snmp trap
receiver.

Please correct me if I am wrong.

Nagaraju

> > > > > PaC hasn't IP address. I think that the PAA shouldn't send PSR if
no
> > IP

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 8 Mar 2006 09:06:29 -0500

> EP will send a panaNewPaCIPNotification with the new IP address  and

OK.  I agree that use of PUR for on-demand key installation is
sufficient for IPsec ciphering.

> is it out of scope of PANA how a PAA is notified of EP's mac by an snmp trap

I think any SNMP implementation needs to maintain the mapping between
an SNMP engine id and the transport address and other information
associated with the engine id.  When PAA receives an snmp trap, then
it can identify which EP is sending the trap based on the mapping.  To
me this is an SNMP implementation issue.

Yoshihiro Ohba

---

From: [email-masked]
Date: Mon, 13 Mar 2006 17:30:17 +0100

nagaraju, yoshi, rafa,

below is a tempative summary on this topic:

* fact 1 = originally the L2/IP notifs were envisaged to trigger 
unsolicited PAA discovery. Nagaraju noted that L2 notif is useless.
* fact 2 = another usage of the notifications is on-demand key 
installation. To this end, L2Notif can be useful (as well as IPNotif 
when IPsec protection is used).

* question 1 = do we need two separate notifications or one single IP 
notif (extended with L2@) is sufficient ?
* question 2 = should the SNMP draft details the on-demand key 
installation behavior ?

-> for Q1, I would prefer a single NewPacNotification.
-> for Q2, I would agree with rafa: saying that those notifications may 
be used for different management/administrative tasks (i.e. key 
installation) could be enough.

regards,
yacine

---

From: Nagaraju <[email-masked]>
Date: Tue, 14 Mar 2006 10:29:03 +0530

> -> for Q1, I would prefer a single NewPacNotification.

I also prefer a single NewPacNotification.

> installation) could be enough.

I agree.

Nagaraju