Re: Questions about draft-ietf-l2tpext-failover-02.txt
Vipin Jain <vipinietf <at> yahoo.com>
2003-10-17 17:35:18 GMT
My comments on the other set of issues..
> Thanx for your responses. My primary concern in all of this is to havea
> mechanism that allows for control plane only failover (with hitless
> dataplane) while also allowing for a full failover (control and data plane)
> aswell. I'm not sure how to achieve the hitless data plane with a tunnelid
> change. It also seems that for the full failover, we basically haveto
> change the tunnel id's to establish unique before and after data
> sequencenumber spaces (or else carry an additional field in every data plane
> packetto indicate the instance of the sequence number space).
Your point is very valid and the suggestions you make do have merit. My
response/concerns to that is inline..
> The construct provides a mechanism to authenticate (withtunnel password
> mechanism) that most of the implementationsalready have. IMO, the problem is
> not with using SCCRQ/SCCRP/SCCN,rather using that as a mechanism to switch
> over to a newtunnel.
> [pwh2] I agree that the problem is switching to a new tunnel. Since
> thefirst packet of the handshake arrives with an unexpected Ns doing the
> normalacknowledgment process would foul things up if it was a spoof. Thus
> thefirst packet, at least, probably needs to be special cased in terms of
> acknowledgement...itreally needs to be acknowledged by the 2nd packet (which
> is sent only ifthe credentials in the 1st packet are valid). The existing
> messages alsocarry AVPs that aren't really necessary to the task of
> recovering the sequencenumbers. Having said that, it doesn't really matter
> what we call these3 packets....I think the key here is that they be sent over
> the already establishedtunnel.
Usually the implementations, at least the ones I have seen, have the protocol
layer riding on top of a reliable layer. The reliable layer does litmus test
for an incoming packet based on the sequence numbers, if it matches then the
expected sequence numbers are updated and packet is delivered to the protocol
layer to parse the packet. Similarly, while sending Ns is updated and packet is
queued for transmission.
Therefore in order to ensure that transport layer notices the sequence number
miss, it should be able to quickly check (instead of going through all AVPs) to
know if it needs to hand over the message to protocol layer.
Fields that we could play around with are Ns and Nr fields. We can't possibly
fiddle around with other fields. However, if we choose known Ns, Nr (i.e. both
zero) then we are making it too predictable to know the sequence numbers during
failover. This is the same concern I had mentioned earlier, to solve that we
agreed to choose sequence numbers that were diametrically opposite.
> Why not a ResetReq withNs(0), Nr(0) to signal the reset of the control plane
> (and optionally the data plane). This could be receivedon the extant tunnel
> without, I think, any confusion withother control packets on the tunnel -
> receiver takes ResetReqas a command to flush transmit and receive control
> queuesfor tunnel and reset sequence numbers. Comes back withResetReply to
> confirm. The ResetReply could be ackedwith the normal ack mechanism. Now
> we have a boundarypacket in the control plane in both directions to resetthe
> control plane sequence numbers. Could you expand onwhy something along
> these lines could not be structured toaddress your concerns?
> Using one 'extant' tunnel to reset control planesfor various old tunnels
> might void the idea of having differentsecrets for different tunnels.
> [pwh2] I don't think this is what I was proposing. Rather I'm proposingthe
> handshake packets are sent on the existing tunnel's control plane usingthe
> existing tunnel's ids.
I mentioned my concerns for reusing the existing tunnel to transmit new control
packets above. Given that, I'd be inclined to do something close to what Keyur
and Leo proposed to achieve hitless dataplane failover mechanism:
- Establish a new tunnel (let's call it Failover Tunnel) to reset Ns values
(and optionally the authentication information) on two endpoints for a given
tunnel. Please note that authentication carried for a tunnel is different from
the authentication used for 'Failover tunnel' itself. Once Ns, Nr values are
set, two endpoints can start exchanging the control packets on the old tunnel.
Sessions are recovered as mentioned in the mechanism today.
> Because UDP packets could take different paths (IP routes)to reach the failed
> node, even after reset you can not besure the traffic will not interfere the
> new tunnel duringthe beginning. I don't think it either is a strong
> argument,but still a possibility.Resetting Ns=0 and Nr=0 would be opening up
> security holes.If someone blasts either of the endpoints with StopCCNswith
> predictable (Nr would be in the initial range) sequencenumbers would result
> in tunnel termination.
> [pwh2] I agree, but I think this is more a basic problem with StopCCN
> thanwith the failover mechanism.
There is a little difference: I think in regular case chances of getting the
retransmitted packet with same sequence number is much higher. During failover
we would get a totally different packet acknowledging (or preceived as by the
receiving end) as one of the post failover packet. Only way to avoid is to use
distant Ns values when the old tunnel is revived. I think we agree on this.
> It's not too hard to send a flood of S
> opCCNsto take down a tunnel even not knowing the sequence numbers. Yes, a
> resetto 0 makes it more easier. Your suggestion below would help with this
> (andwith the UDP re-ordering problem above). Posit that each side choses
> it'snew Ns in the 2nd and 3rd packets of the handshake. Each side choses
> anNs that is away from recent prior traffic. This restores
> upredictabilityfor the StopCCN scenario and addresses the UDP re-ordering.
> Well, to avoid that we'd have to mandate both endspick their own Ns values
> and let the other end set their Nrbased on that.thanks,--
let me know what you think.
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search