Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Wed, 14 Jun 2006 08:08:36 -0700

> > You may or may not be right regarding this issue. However, 
> the point 
> > is moot. For better or worse, that decision was made years 
> ago and BGP 
> > became the infrastructure upon which interdomain routing is based. 
> > This isn't about to change any time soon.
> 
> It is already changing, if it hasn't already - the relevant 
> IDs are cited in my draft.

Where? I don't see that nor conversations which lead me to believe there
is movement to push for a major change on massive consensus and working
code with our SP routing protocol practice today.

If there is some WG discussing this, please clue me in.

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 08:20:53 -0700

> If there is some WG discussing this, please clue me in.

...
This problem has already been addressed in extensions to BGP and BGP
   for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04].
...
   [Re05]    Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for
             BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (work
             in progress), Aug. 2005.

   [Sa04]    Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen,
             "Graceful Restart Mechanism for BGP," draft-ietf-idr-
             restart-10 (work in progress), June 2004.

The latter was an unfortunately old reference; there was a -11 version
issued in May 2006, and a new version issued just 2 days ago:

draft-ietf-idr-restart-12 	Graceful Restart Mechanism for BGP 	 Srihari
Sangli 	idr 	12-Jun-06

I encourage you to visit the IDR WG and ask them this question. Also
OSPF as per below, if of interest.

Some others missed in the first version of the draft (it was a -00 ;-):

RFC4167 Graceful OSPF Restart Implementation Report  	A. Lindem 	October
2005 	ASCII 	  	INFORMATIONAL

RFC3623 Graceful OSPF Restart  	J. Moy, P. Pillay-Esnault, A. Lindem
November 2003 	ASCII 	  	PROPOSED STANDARD

RFC3478 Graceful Restart Mechanism for Label Distribution Protocol  	M.
Leelanivas, Y. Rekhter, R. Aggarwal 	February 2003 	ASCII 	  	PROPOSED
STANDARD

draft-holla-ospf-update-graceful-restart-01 	Update to OSPF Graceful
Restart procedure 	Ashok Holla 	individual 	10-Mar-06

draft-ietf-ospf-ospfv3-graceful-restart-04 	OSPFv3 Graceful Restart
Padma Pillay-Esnault, Acee Lindem 	ospf 	8-May-06

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 08:20:53 -0700

...

Joe

---

From: Ron Bonica <[email-masked]>
Date: Wed, 14 Jun 2006 11:49:04 -0400

Joe,

I don't think that Graceful Restart will be available in call cases. For
example, it is likely to be unavailable on eBGP sessions between
providers and their customers.

                                   Ron

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 09:06:49 -0700

> providers and their customers.

Why? Why would TCP-Auth be accepted where graceful restart isn't?

A technical argument would be useful here, but if this is a marketing
prediction, it isn't.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jun 2006 21:38:35 +0300 (EEST)

> A technical argument would be useful here, but if this is a marketing

Enabling Graceful Restart can cause black holes and loops under valid 
and rather common scenarios (e.g., power loss, forwarding plane 
crash).  It has been designed in such a fashion that it cannot be 
enabled by default due to these bad effects, the users must know what 
they are doing. [1]

As such, major router vendors do not enable graceful restart by 
default.  It is not clear to me whether major router vendors enable 
graceful restart helper-mode by default.  Helper mode is required for 
GR to be used.

Hence, you have two dependencies:
  - you explicitly enable GR yourself and face the consequence,
  - your peers have enabled GR helper mode.

>From that perspective, it seems natural that vendors and operators 
would prefer a self-contained solution.

[1] I made an IETF Last call comment about this.  The text was 
improved slightly in -11 but as the applicability and usefulness of GR 
seemed to be felt to be out of scope from interoperability 
perspective, these issues were not further discussed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 11:52:31 -0700

Given the questions about graceful restart, as well as the potential
need to use TCP-SA for applications for which restart or handover would
be difficult, would the following change suffice:

   >> TCP STATUS MUST allow TSAD entries for ongoing TCP connections
                 ^^^^ (changed from MUST NOT)
   (i.e., not in the CLOSED state) to be modified.

and append:
   (excepting fields that identify the connection, which MUST NOT
   be modified).

This way the user level (user to TCP) can modify the TSAD entries while
a connection is in progress. This allows out-of-band protocols
(including timer mechanisms) to rekey the endpoints - or even change the
algorithm or key length; all that happens is that packets in transit or
using the previous key/alg/length fall on the floor for a while until
both ends match. That 'while' should be short enough not to cause TCP
to disconnect even with really poor coordination, AFAICT.

IMO, this is a simple, contained modification, and pushes rekeying
outside TCP (where it belongs, like initial key establishment IMO).

Also, I do not see a need to add a key ID inband or OOB to make this happen.

That's basically a one-word change to the requirements; it's a few
paragraphs of change to the text, and it then allows TCP-SA to support
dynamic rekeying.

Thoughts?

Joe