Subject: RE: Question about incoming calls, number 2.

From: HOULLIER Francis FTRD/DMI/CAE <[email-masked]>
Date: Thu, 25 May 2000 14:35:49 +0200

In fact, the real question is :
When a LNS receives an ICRP containing an assigned session Id  which is
already in use in a working session (in the same tunnel coming from the same
LAC), what MUST (or SHOULD, or MAY) this LNS do ?

Francis HOULLIER
FTR&D / DMI / SIR
42 rue des Coutures BP 6243 
14066 CAEN CEDEX

E-mail : [email-masked]
Tel : 02 31 75 91 65
Fax : 02 31 73 56 26

---

From: "David Wong" <[email-masked]>
Date: Thu, 25 May 2000 11:12:18 -0400

Hi, Francis. Did you mean an ICRQ instead of an ICRP?

On page 62 of the RFC (section 7.4.2), there is a state transition table. The
last line of the table applies to the established state. If an ICRQ, ICRP, or
ICCN is received by the LNS, then it must send a CDN and clean up and go back to
the idle state.

"HOULLIER Francis FTRD/DMI/CAE" <[email-masked]> on
05/25/2000 08:35:49 AM

To:   "'Barbara Nichel'" <[email-masked]>, "HOULLIER Francis
      FTRD/DMI/CAE" <[email-masked]>, [email-masked]
cc:    (bcc: David Wong/Bos/Teradyne)

Subject:  RE: Question about incoming calls, number 2.

Francis HOULLIER
FTR&D / DMI / SIR

---

From: "Barbara Nichel" <[email-masked]>
Date: Fri, 26 May 2000 08:59:50 +0200

Hi Francis,

looking the state transition table (7.4.2 LNS Incoming Call States), I think
that the case you are referring to,
could match this one:

LNS state:     IDLE
Event:         Receive ICRQ, not acceptable

=> next LNS state:  IDLE
     Action:        Send CDN, Clean up.

The result is that also the existing (and working) session with the same Session
ID offending
you will be closed.
Personally I think that such a situation is a symptom o malfunction, so I would
clean up the entire tunnel.

Regards,
          Barbara

---

From: Barney Wolff <[email-masked]>
Date: Fri, 26 May 2000 10:14 EDT

This whole discussion seems to have ignored the l2tp reliable delivery
mechanism, which reasonably ensures that a mere retransmission will
not even be seen by the state machine.  Getting a packet from the
right addr/port, to the right addr/port, with the right tunnel id,
and a sequence that will be accepted, and yet is not from your real
peer - all that implies an active attacker who can both sniff and
inject packets.  But that's exactly the threat that only IPsec or
an equivalent can counter.

Barney Wolff  <[email-masked]>

---

From: "Verma, Rohit (US - Chicago)" <[email-masked]>
Date: Fri, 26 May 2000 10:01:38 -0400

I don't think you should do a blind cleanup because you could get a packet
from an LNS that put a bad Tunnel Id in the packet and you will end up
losing all connection with the good LNS.
My suggestion will be to discard a packet that is out of state.

Regards

Rohit Verma
Deloitte Consulting
180, N. Stetson Avenue
Chicago, Illinois 60601
Phone: 312-374-2475

-----Original Message-----
From: Barbara Nichel [mailto:[email-masked]]
Sent: Friday, May 26, 2000 8:00 AM
To: HOULLIER Francis FTRD/DMI/CAE; [email-masked]
Subject: RE: Question about incoming calls, number 2.

Hi Francis,

LNS state:     IDLE

=> next LNS state:  IDLE

The result is that also the existing (and working) session with the same
Session
ID offending
you will be closed.
Personally I think that such a situation is a symptom o malfunction, so I
would
clean up the entire tunnel.

Regards,
          Barbara

---

From: HOULLIER Francis FTRD/DMI/CAE <[email-masked]>
Date: Fri, 26 May 2000 17:56:13 +0200

Thanks all for your help.
To close the discussion, I will send a CDN when I receive that wrong ICRQ.
Close the whole tunnel does not match with the Control connection states.

Francis HOULLIER
FTR&D / DMI / SIR