PDU Sequence assumptions vs. Jeff Haas comments #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sue's review of Mandatory PDUs sequence L3ND
Sequence is: Hello[0],TCP/TLS, OPEN[1]/Ack[3], ULPC [8]
Reduced: Hello[0], TCP/TLS, OPEN[1], ULPC [8]
Randy indicated PDU reduction if we remove the ACK.
Basic assumptions:
TCP/TLS was a reasonable way to handle reliable transport
Going from TCP to TLS - was a sliding scale of security and confidentiality
Hello/Howdy set problems with TCP/TLS set-up
Jeff's comments on assumptions:
Why?
1-a) one is putting strong security around the information discoverable in ARP/ND.
1-b) increase in the number of sockets since you need an extra socket just to exchange that you need another socket.
Unreliable multicast with timers is a better option than TLS.
Potential for dueling Hellos (see Issue with discussion).
Dueling Hello sequence:
The BGP statement deals with dualing TCP Sessions (two sessions starting with TCP syn). Yakov grew to dislike this part of BGP, and when he cloned BGP functions in LDP, he changed this part.
In LDP, multicast Hello messages carry the transport address.
The larger IP address in the transport address starts the LDP session.
For a single session, the Hello/Howdy performs the same function - even if hte scale is a problem. The following example gives the scaling issue.
router
mgt-board -----1K Ethernet interfaces
Let's start by a simple example:
In the CLOS environment, most Tiers are connected by 2 ethernets.
If a Top Tier connects to a node in tier below, then
Top-tier-box (intf-3) ---eth1----(intf-1) ----tier-2 box-a
The hello can be multicast on eth1 and eth2.
Does the tier box responds with Howdy to intf-3 and intf-4?
If so, there are two TCP/TLS sessions set-up.
If you expand this example, to 1000 tier-2 boxes, the number of TCP/TLS sessions is 2000 sockets.
This shows the TCP/TLS scaling issue is with the potential number of sockets.
Dueling TCP/TLS
For the dueling TCP/TLS in the CLOS examples, two boxes must both be trying to create L3ND two different ethernets.
box-1 (intf-3)---eth1---(intf1) box-2
box-1 (intf-4)---eth2---(intf2) box-2
For some reason, box-1 and box-2 both think they should be sending out L3 multicast hellos.
Box-1 sends out a Hello from loopback address, and
box-2 sends back a Howdy (unicast) box-1 loopback.
Box-2 sends out a Hello from lookback address, and box-1 send back a Howdy (unicast) to box-2 loopback.
box-1 starts a TCP/TLS session on eth-1 to box-2 Loopback/TCP port
Box-2 starts a TCP/TLS session on eth-2 with TCP box-1 loopback/TCP Port
The boxes are both setting up the TCP/TLS session to remote loopback.
Three questions:
My understanding: Can L3ND allow the sequence create 2 TCP sessions?
box-1 (intf-3)---eth1---(intf1) box-2
box-1 (intf-4)---eth2---(intf2) box-2
The answer is the text on page-9, section 6, states:
"If a HELLO is received from an IP address with which there is an established session for that API, the hello should be dropped."
box-1 127.1.1.1 ---eth-1---- box-2 127.1.1.3
TCP port L3ND TCP port for L3ND
If subsequently, eth-2 comes up, then the first connection wins the Hello.
If the eth-1 is not already up, when eth-2 is sending the Hello, then
this clause in section 6, does not stop the dueling TCP connection set-ups.
However, it does tighten the time frame.
At some point, one side will come up and recognize the second interface.
Does this mean the application, will terminate the TCP session?
If so, the following 2 clauses fixes the problem:
Clause 1) (page 10) If the TLS/TCP open fails, this should be logged and the parties MUST go back to the inital state and try hello.
Let me know if I have fixed this case.