Subject: [pim] TCP Connection ID

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 05:26:33 +0530

Hi,

Assume A and B have a PORT session established. Now A receives a PIM Hello message from B with a different Connection ID. What should it do? Should it kill the existing TCP session and establish a new one or should it ignore this change as long as the PORT session is up (i.e. PORT keepalives continue being exchanged).

I think it should be the latter, however this needs to be discussed and addressed in the spec.

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 09:52:58 -0800

> I think it should be the latter, however this needs to be discussed and addressed in the spec.

I remember planning to add text on this. I think the connection should
be taken down and re-established. If an administrator makes the decision
that connections should be terminated at a new IP address, then I would
say that should effect all connections. There may be reasons why do not
want the old IP address to be used anymore. If the old address becomes
unavailable, then the connection would later fail, but I think it's
better to switch immediately. Even if the old IP address remains valid
and the TCP connections can stay up, there may be reasons why one wants
to change addresses.

One example might be that you install a second link between two PIM
routers and you decide that you want to do connection sharing. You
might start out using just link-local addresses (a likely default
for IPv6), but would then need to change to global addresses.

Stig

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 23:53:10 +0530

> that connections should be terminated at a new IP address, 

Ok, then the router that changes the Connection ID MUST gracefully terminate the PORT session by closing the TCP socket. The onus should lie on the side that's changing the Connection ID, rather than the side that's receiving the PIM HELLO. Can you also add this to the draft?

Lets see how this helps (i.e. the sending side initiating the termination vis-à-vis the receiving side doing this). If it's the receiving side that decides to terminate the session based on a new Connection ID then we're making PORT vulnerable to attacks where a single malicious HELLO packet will bring down the PORT session? Also note that while we are currently using a link local mcast address for the HELLOs, we might in future use some other, and possibly a unicast address (for discovering routers multiple hops away). In that case spoofing HELLOs would become much simpler, and thus easier to attack PORT.

I would thus suggest that if we want to re-establish a PORT session then the sending side should initiate this. This means that the receiving side will not do anything if it sees that the connection ID has changed.

Cheers, Manav

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 10:41:38 -0800

> Ok, then the router that changes the Connection ID MUST gracefully terminate the PORT session by closing the TCP socket. The onus should lie on the side that's changing the Connection ID, rather th…

I think both of them should terminate it. The only bad thing I see
with doing it on the sending side is if a Hello is getting lost.
The other side may then try to reconnect to the old address.

Another issue I can think of is if somehow one router cannot
send packets from the previous IP address. Then it cannot do
a graceful termination.

> Lets see how this helps (i.e. the sending side initiating the termination vis-à-vis the receiving side doing this). If it's the receiving side that decides to terminate the session based on a new C…

I agree that may be a concern. But if you can spoof a Hello, you can
also send one without the PORT Option, forcing the connection to go
down. If you can send malicious PIM packets you can do a lot of
bad things.

> I would thus suggest that if we want to re-establish a PORT session then the sending side should initiate this. This means that the receiving side will not do anything if it sees that the connectio…

I think it should be back to the usual rules. It is based on who
has the highest ConnectionID. Once the connection is down, the
state could be the same as if it never was up.

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 10 Feb 2011 08:54:47 +0530

Stig,

> and the TCP connections can stay up, there may be reasons why one wants

If we tear down a connection because of hold-time, what will happen to the J/P learned from a given connection?

Thanks,
Bharat
 
> for IPv6), but would then need to change to global addresses.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 10 Feb 2011 09:42:33 +0530

Bharat,

> If we tear down a connection because of hold-time, what will 
> happen to the J/P learned from a given connection?

You clear that state in the HW.

Cheers, Manav

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 10 Feb 2011 09:43:40 +0530

Manav,

> You clear that state in the HW.

I agree that this will be logical to clear the state.

But sometime back, we were discussing that we can start a timer for each J/P and can let them time-out if no update comes either through native J/P or the connection gets re-established. Though I understand there are issues in doing that also.

Thanks,
Bharat

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 10 Feb 2011 10:02:40 +0530

Hi Bharat,
 
> But sometime back, we were discussing that we can start a 
> timer for each J/P and can let them time-out if no update 
> comes either through native J/P or the connection gets 
> re-established. Though I understand there are issues in doing 
> that also.

The idea behind doing that was to provide a hitless support for PORT, where we don't remove all the HW state if there is (i) a switchover to the redundant OR (ii) PORT crashes and comes back up before the J/P timers expire and it was able to preserve the state.

This should still be done, as long as PORT comes back up within the Hold Time. If it takes more than that, then the PORT neighbor is considered to be DEAD.

A lot of routing protocols use this technique to provide a graceful restart option where the restarted router MUST come back up before the Holdtimer on the other end expires. We need to do the same for PORT.

Cheers, Manav

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Feb 2011 10:19:42 -0800

> A lot of routing protocols use this technique to provide a graceful restart option where the restarted router MUST come back up before the Holdtimer on the other end expires. We need to do the same…

What the draft says now is:

    When a Transport connection goes down, Join/Prune state that was sent
    over the Transport connection is still retained.  The neighbor should
    not be considered down until the neighbor timer has expired.  This
    allows routers to do a control-plane switchover without disrupting
    the network.  If a Transport connection is reestablished before the
    neighbor timer expires, the previous state is intact and any new
    Join/Prune messages sent cause state to be created or removed
    (depending on if it was a Join or Prune).  If the neighbor timer does
    expire, only the upstream router, that has oif-list state, to the
    expired downstream neighbor will need to clear state.

So when the connection goes down (note that the rule is different if
PORT is unconfigured so that we are reverting to datagram mode), the
state is retained as long as the neighbor is alive.

I think it makes sense to not immediately remove state. The question
I have though is whether we should eventually remove the state even
if the neighbor is alive. We may not want state to stay there
permanently if somehow the PIM Hello's make it through but no working
TCP connection can be established.

When switching to datagram mode the draft says:

    There may be situations where an administrator decides to stop using
    PORT.  If PORT is disabled on a router interface, we start expiry
    timers with the respective neighbor holdtimes as the initial values.
    Similarly if we receive a Hello message without a PORT Capable option
    from a neighbor, we start expiry timers for all Join/Prune state we
    have for that particular neighbor.

I think we should do this in all cases when a PORT connection goes down.

Stig