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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 03:44:02 -0700

> 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
Given that the Discovery packet is optional, how did the AC determine
this is a Discovery packet as opposed to the beginning of the DTLS
session setup? That's the challenge we are trying to resolve.

>     * 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.

I disagree with this, but see the similar state change comment below.
> 
> Common Port Apporach (Proactive implementation):
>     * AC will get the discovery packet on 0x2FBF port
Again, the AC thinks that the WTP already has a DTLS session setup. So
how does it know whether this is a discovery packet or the beginning of
the DTLS session. Clearly, stating that the DTLS SA table entry consists
of both the WTP's IP address and UDP Port number, and requiring that the
WTP use a different source port across reboots resolves some issues. We
are still down to the point where we need to be able to clearly identify
the discovery packets from the DTLS packets.

>     * 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.

This I disagree with, because it causes the state to be reset without
any cryptographic proof that the WTP sending the packets is in fact the
right one. I think we would need the DTLS session to be established (or
at least the WTP be properly authenticated) prior to reseting any state.

>     * 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

Neither one of situation 2b is acceptable, IMHO. There is no need to
impose a delay in the DTLS setup. If we properly ensure that
authentication occurs prior to flushing of the state in situation 2a,
then I think we have a functional protocol.

> 
> 
> 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.

That's only because of a flaw in the logic in situation 2a. Requiring
that the DTLS session be established prior to reseting state does not
create the vulnerability you describe here. That said, I think there's
also another fundamental problem with this situation. You assume that
the AC identifies the WTP simply through its IP address, which I believe
is incorrect. The means by which the AC should be identifying the WTP is
through its credentials. Consider the following two cases:
1) WYP reboots and performs a DHCP and gets a new IP Address. In this
case, if the AC were to simply use the source IP address, and not the
DTLS credentials, it would end up thinking it had two separate WTPs
connected, when in fact only one exists. Surely, the AC would eventually
time out the old IP address, but I don't see any real benefits in this.
Tying the identity to the WTPs credentials would require the AC to
perform a credentials lookup when the new DTLS session was being
established, and once the session was successfully setup, would cause
the old DTLS (and associated CAPWAP state) to be flushed.
2. WTP loses power, and at the same time another WTP reboots. The second
WTP ends up getting the IP address of the WTP that had lost power.
Again, if the AC were to simply use the IP address (and not DTLS
credentials), then it would improperly assume that the new WTP was in
the fact the old one, and flush the wrong DTLS (and WTP CAPWAP state).

> 
> 
> 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.

True, but at a cost. Again, requiring that state changes only occur once
the DTLS session is established eliminates all of these attacks, without
any time tax.

> 
> 
> Conclusion: Common Port approach behaves nearly same as Seperate port
>                   approach be it normal functioning or DoS 
> attack situation.

While I believe the tweaks I described above are required, I do
generally agree that either alternative are equivalent (from a
vulnerability standpoint).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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