Subject: [L2tpext] Re: Questions about draft-ietf-l2tpext-failover-02.txt

From: Vipin Jain <[email-masked]>
Date: Fri, 31 Oct 2003 12:25:40 -0800 (PST)

Paul,

my comments inline..

> My comments inline [pwh3]

> Usually the implementations, at least the ones I have seen, have the 
> protocollayer riding on top of a reliable layer. The reliable layer does 
> litmus testfor an incoming packet based on the sequence numbers, if it 
> matches then theexpected sequence numbers are updated and packet is delivered

> to the protocollayer to parse the packet. Similarly, while sending Ns is 
> updated and packet isqueued for transmission.Therefore in order to ensure 
> that transport layer notices the sequence numbermiss, it should be able to 
> quickly check (instead of going through all AVPs) toknow 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 possiblyfiddle around with other fields. However, 
> if we choose known Ns, Nr (i.e. bothzero) then we are making it too 
> predictable to know the sequence numbers duringfailover. This is the same 
> concern I had mentioned earlier, to solve that weagreed to choose sequence 
> numbers that were diametrically opposite.
> [pwh3] I agree with the issues about separation of the reliable layer andthe 
> protocol layer.   You mention we can only play with Ns and Nr.   Whynot take 
> one of the reserved bits in the header to signal a UI frame (Ns= 0, Nr = 
> 0)?   The reliable layer would handle all UI frames - thus avoidingthe issue 
> of to pass up to the protocol layer or not.   The handshaking todo the 
> failover could thus be done with a sequence of UI frames.   The 
> authenticatedhandshaking with UI frames would include the new sequence 
> numbers to be usedthus avoiding predictability of the new Ns
Reserved Bits: I am in for that. Based on the discussions earlier Mark and
we agreed that if we can get it done by using a control plane message exchange
there is no need to make a L2TP-header change for this.
Using Ns=0, Nr=0 Scheme: This is flawed because it might naturally coincide
with the sequence numbers of a tunnel thereby confusing this as an
acknowledgement for a packet sent earlier.
      
> I mentioned my concerns for reusing the existing tunnel to transmit new 
> controlpackets above. Given that, I'd be inclined to do something close to 
> what Keyurand 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 
> giventunnel. Please note that authentication carried for a tunnel is 
> different fromthe authentication used for 'Failover tunnel' itself. Once Ns, 
> Nr values areset, two endpoints can start exchanging the control packets on 
> the old tunnel.Sessions are recovered as mentioned in the mechanism today.
> [pwh3] What would be the packet exchange here?   I presume we would havethe 3

> way handshake to establish the failover tunnel and then packets todo the 
> reset?   Or would they be carried on the 3 way handshake.
packet exchange:
- establish a new tunnel (called 'Failover Tunnel')
- exchange the new sequence numbers of the old tunnels for control plane
- Both ends would reset their sequence numbers based on the values exchanged on
'Failover Tunnel'.
- The 'Failover Tunnel' is torn down after al tunenls are considered recovered
(i.e. when they have been exchanged and agreed upon by both peers. Remaining
tunnels are torn down assuming they do not need recovery by at least one of the
endpoints.

> One negativeto this approach is that it would require the systems to have the

> resourcesavailable to at least temporarily manage the additional tunnels - 
> this mightimply being able to temporarily peak at double the normally 
> supported numberof tunnels.   If the non-failed endpoint was at it's maximum 
> number of tunnels,how would it know to make an exception for the failover 
> tunnel setup?
And therefore we would RECOMMEND keeping space for at least tunnel for recovery
purposes. If it can't establish the tunnel, then it could retry 'x' times
before concluding the tunnel recovery mechanism failed. This is much better
than current proposal where we'd establish one new tunnel for every old tunnel.

> Howdoes the transition to the new sequence number occur? 
> I  presume we handoff the new sequence numbers to the reliable layer and
> it then purges it'sre-ordering rx queue, renumbers any outstanding,
> transmits and immediatelyre-transmits them?  Any stale receives get 
> automatically discarded as outof window.
- Renumbering outstanding transmits might create more unpredictability for no
benefit. Because control plane on the failed node would have lost the context
related to previous messages, it is better to flush everything off and start
with new sequence numbers.
The old tunnel becomes active only upon getting confirmation from its peer that
it has reset control plane sequence numbers. So this would have to be a three
way handshake as described below. For example, for an old tunnel:
- Failed node sends: "Reset Nr to 5665 for Old Local Tid = 9, Old Tid = 6".
- Non Failed node responds: "Nr for Old Tid = 9 reset to 5665, Reset Nr to 4435
for the same tunnel (i.e. Old Local Tid = 6, Old Tid = 9 from this node's
perspective)". Failed endpoint upon getting this message must first enqueue the
response of this message and then start sending control messages on the Old
tunnel.
- Failed node sends: "Nr for Old Tid = 9 reset to 4435". Non failed node upon
getting this can start sending control messages.
  
>  It's not too hard to send a flood of SopCCNsto 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.    
    
> [pwh3] We might want the non-failed endpoint to provide a hint in the 
> 2ndpacket of the exchange to help the failed endpoint pick an Ns that is 
> farenough away.   Might be useful if the failed endpoint's mirroring of 
> it'sNs is relatively infrequent and there had been a lot of control traffic 
> onthe tunnel.
Sure, picking our own Ns and scheme described above would take care of this
security hole.  
  
thanks,
-- vipin

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

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

---

From: Vipin Jain <[email-masked]>
Date: Fri, 31 Oct 2003 12:25:40 -0800 (PST)

Paul,

my comments inline..

      

packet exchange:

  

  
thanks,
-- vipin