Subject: [Capwap] Seperate Port Vs Common Port Approach Comparison...

From: "Navin (NKA)" <[email-masked]>
Date: Tue, 24 Oct 2006 03:19:59 +0530

Pat, Scott, et all,

Below, I have taken the liberty of comparing 'seperate port' apporach
with 'Common Port' approach.

To me it looks like, there is no additional advantage in going with
'seperate port'
approach. 'Common port' approach's behaviour (during normal
functioning as well as DoS attack) is nearly same as 'seperate port'
approach. Please go through
the comparison to know for yourself.

Regards,
Navin

-------------------------------------------------------------------------------------------------------------------

What is a Seperate Port Apporach ?
ANS: In this approach, seperate port (e.g. 0x2FBF) will be used for sending
     and receiving Capwap Discovery Control Plane packets. As all other
     control packets exchanged between AC and WTP are going to be DTLS
     secured, they will be sent to a different port (e.g. 0x2FC0).

What is a Common Port Apporach ?
ANS: Here, Capwap will use just one port (e.g. 0x2FBF) for sending and
     receiving Discovery as well as all other DTLS secured control plane pkts.

Situation 1: A legitimate WTP just now got powered and once its up, it starts
             sending discovery packet to ACs. And once discovery is complete,
             DTLS session establishment between WTP and AC.
Seperate Port Apporach:
    * AC will get the discovery packet on 0x2FBF port
    * it would do discovery reply.
    * WTP in turn would start the DTLS session establishement by sending
      CliehtHello message to 0x2FC0 port of AC.
    * When AC gets ClientHello on 0x2FC0 and finds out that no prior session
      information exists, it would continue with DTLS session establishment
      process.

Common Port Apporach:
    * AC will get the discovery packet on 0x2FBF port
    * AC will try finding out if prior session information for the WTP exists
      or not. If not, it would do discovery reply.
    * WTP in turn would start the DTLS session establishement by sending
      CliehtHello message to 0x2FBF port of AC.
    * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session
      information exists (and FSM state is Discovery), it would continue with
      DTLS session establishment process.

Situation 2a: A fully functional (in Capwap Run State) WTP gets rebooted
              accidently, and once it is up, it starts sending non-DTLS type
              Discovery packet again to an AC.
Seperate Port Approach (Proactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * it would do discovery reply.
    * WTP in turn would start the DTLS session establishement by sending
      CliehtHello message to 0x2FC0 port of AC.
    * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session
      information exists (with FSM=Run), AC will assume that most likely WTP
      got rebooted and it would go ahead and reset  (state=Discovery) WTP
      session information.  Ultimately, AC would continue with DTLS session
      establishment by processing ClientHello message.
Remark: No keepalive type timer expiry happens. So WTP will be up in NO time.

Common Port Apporach (Proactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * AC will try finding out if prior session information for the WTP exists
      or not. As it does (with FSM=RUN), AC will assume that most likely WTP
      got rebooted and it would go ahead and reset (state=Discovery) WTP
      session information. Ultimately, AC would do discovery reply.
    * WTP in turn would start the DTLS session establishement by sending
      CliehtHello message to 0x2FBF port of AC.
    * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session
      information exists (with FSM=Discovery), it would continue with DTLS
      session establishment process.
Remark: No keepalive type timer expiry happens. So WTP will be up in NO time.

Situation 2b: A fully functional (in Capwap Run State) WTP gets rebooted
              accidently, and once it is up, it starts sending non-DTLS type
              Discovery packet again to an AC.
Seperate Port Approach (Reactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * it would do discovery reply.
    * WTP in turn would start the DTLS session establishement by sending
      CliehtHello message to 0x2FC0 port of AC.
    * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session
      information exists (with FSM=Run), AC would simply discard the
      clientHello packet. And would wait for the keepalive timer to expire for
      the WTP session under consideration. Once the timer is expired, WTP
      session information will be deleted, bringing AC in sync with WTP.
      Ultimately AC will start processing clientHello packets to carry on with
      DTLS session establishment.
Remark: WTP UP will be in close to keepalive timer value time.

Common Port Apporach (Reactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * AC will try finding out if prior session information for the WTP exists
      or not. As it does (with FSM=RUN), AC will simply drop the incoming
      discovery pacekt and wait for the keepalive timer to expire for the WTP
      session under consideration. Once the timer is expired, AC's FSM will be
      in sync with WTP. From this point onwards, AC will start processing
      discovery packets followed by DTLS session establishment.
Remark: WTP UP will be in close to keepalive timer value time

Situation 3: There is one fully functional legitimate WTP providing WLAN
             services and is Capwap controlled by an AC. An illegal WTP
             somehow gets access to the WTP/AC's networks and can snoop
             packets from the wire. In such situation, it can snoop legitimate
             WTP's IP address and start sending discovery request to the AC
             on 0x2FBF. This is a sort of DoS attack situation.
Seperate Port Approach (Proactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * it would do discovery reply.
    * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION
      TO DISCOVERY REPLY.
    * Illegal WTP in turn would start the DTLS session establishement by
      sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC.
    * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session
      information exists (with FSM=Run), AC will assume that most likely WTP
      got rebooted and it would go ahead and reset  (state=Discovery) WTP
      session information.  Ultimately, AC would continue with DTLS session
      establishment by processing ClientHello message. But most likely the
      illegal WTP may not be having proper certificates etc, so its
      authentication will fail ultimately with AC.
Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought
        down by an illegal WTP.

Common Port Apporach (Proactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * AC will try finding out if prior session information for the WTP exists
      or not. As it does (with FSM=RUN), AC will assume that most likely WTP
      got rebooted and it would go ahead and reset (state=Discovery) WTP
      session information. Ultimately, AC would do discovery reply.
    * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION
      TO DISCOVERY REPLY.
    * Illegal WTP in turn would start the DTLS session establishement by
      sending CliehtHello message to 0x2FBF port of AC.
    * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session
      information exists (with FSM=Discovery), it would continue with DTLS
      session establishment process. But most likely the illegal WTP may not
      be having proper certificates etc, so its authentication will fail
      ultimately with AC.
Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought
        down by an illegal WTP.

Situation 4: There is one fully functional legitimate WTP providing WLAN
             services and is Capwap controlled by an AC. An illegal WTP
             somehow gets access to the WTP/AC's networks and can snoop
             packets from the wire. In such situation, it can snoop legitimate
             WTP's IP address and start sending discovery request to the AC on
             0x2FBF. This is a sort of DoS attack situation.
Seperate Port Approach (Reactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * it would do discovery reply.
    * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY.
    * Illegal WTP in turn would start the DTLS session establishement by
      sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC.
    * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session
      information exists (with FSM=Run), AC will keep dropping the clientHello
      packet coming from duplicate (illegal) WTP. Assuming Capwap Keepalive
      messages continue to come to AC, legitimate WTP's session would remain
      intact.
Remark: DoS attack was NOT SUCCESSFUL.

Common Port Apporach (Reactive implementation):
    * AC will get the discovery packet on 0x2FBF port
    * AC will try finding out if prior session information for the WTP exists
      or not. As it does (with FSM=RUN), AC will simply drop the incoming
      discovery pacekt coming from duplicate (& illegal) WTP. Assuming Capwap
      Keepalive messages continue to come to AC, legitimate WTP's session
      would remain intact.
Remark: DoS attack was NOT successful.

Conclusion: Common Port approach behaves nearly same as Seperate port
                  approach be it normal functioning or DoS attack situation.
-------------------------------------------------------------------------------------------------------------------
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Hasan Raza <[email-masked]>
Date: Wed, 25 Oct 2006 20:57:14 +0530

Hi Navin,

[I thought to reply to this mail as per my understandings. Others may
correct me if I am wrong somewhere]

It seems that the common port approach you are suggesting is based on
the wtp session presence/absence logic. As WG folks already discussed on
a separate thread recently, the unauthenticated/plain packets should not
result in any state change at the AC. Otherwise, we would open up
avenues for attacks. Moreover, I believe that the logics you presented
here have basic flaws. And it does not give any solution to distinguish
discovery and DTLS packets, either.

>       DTLS session establishment process.
Did you miss something here? Yes, I believe so. AC in idle (not
discovery) state can receive discovery as well as DTLS client hello
packets. The AC state is same (idle), and the wtp session does not
exist, then how would AC know that the received packet is discovery or
DTLS client hello? You definitely need some extra information to
differentiate among the two kind of packets.

> Remark: No keepalive type timer expiry happens. So WTP will be up in NO time.
Just by receiving ClientHello packet, AC should not tear down the
existing session. To tear down the existing session, DTLS handshake
should be successful.

> Remark: No keepalive type timer expiry happens. So WTP will be up in NO time.
It is a doom, if we do so. Anybody could send plain/unauthenticated discovery
packet and tear down the existing WTP sessions at AC.

> Remark: WTP UP will be in close to keepalive timer value time.
No. There is no reason for AC to discard clientHello packets.

> Remark: WTP UP will be in close to keepalive timer value time
As Pat suggested, discarding discovery requests would lead to delay in
re-joining of WTP.

> Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought
I believe if somebody implements AC like this, then it will be his fault
to open such silly avenues for attacks. Existing session should be
brought down only once DTLS authentication and a new connection
establishment was successful. Otherwise, anyone can send DTLS
clientHello packet to delete wtp sessions at AC.

> Remark: DoS attack was NOT SUCCESSFUL.
DTLS session can not be established with wrong certificate/credentials.
Illegal WTP won't be able to establish a connection. Draft clearly says
that the new session at AC is established only after WTP joins the AC.

>                   approach be it normal functioning or DoS attack situation.
There does not seem to be any such DoS attack situation with the two
port approach as you presented in this mail. Moreover, the
implementation of common port scheme, the way you suggested will
definitely backfire.

Hasan

---

From: "Navin (NKA)" <[email-masked]>
Date: Wed, 25 Oct 2006 23:44:07 +0530

After sending this email, I realized that I had not put down my
thoughts correctly.
Let me re-send this email again. I will surely be able to answer your
questions in
a newer email.

Regards,
Navin