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

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Tue, 13 Jun 2006 17:01:02 -0700

> Those modifications are already underway or implemented in 
> the primary protocol of interest (BGP). These modifications 
> reflect (IMO) an error in protocol design: TCP connectivity 
> was never intended to reflect path viability for routing. 
> Interpreting TCP disconnects as a path failure - which is the 
> only reason to flush the associated routes - is thus an error 
> which it is appropriate to correct.

But why is it your job to correct your perception of a design error that
the operators have no desire to change? 

Operators submitted their design and expectation requirements to three
vendors. Those vendors went off, explored a variety of options, and came
up with a proposal (draft-bonica-tcp-auth-04.txt). The Operators then
said "good, make it happen." 

Now all I'm seeing from all parts of the IETF is "this is the wrong way
to do it cause it does not fit how we perceive the Internet to be
operated." I'm puzzled.

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2006 17:11:12 -0700

> the operators have no desire to change? 

We're the standards community; if there's an error in one standard (BGP)
that creates a problem for another (TCP/MD5 needing to rekey
mid-session) then it is we who resolve that contradiction.

> said "good, make it happen." 

That's between vendors and operators; if you want the IETF involved, you
need to expose that loop to the community as per below.

> to do it cause it does not fit how we perceive the Internet to be

We're equally puzzled as to why IPsec isn't sufficient as an
alternative, since this is precisely what it was designed to do. Perhaps
that's because we haven't been presented with the operator's
requirements - which, BTW, need to be in the form of _WHAT_ they need,
not _HOW_ to accomplish it. We haven't been presented with that yet; to
the extent that we have seen glimpses of their requirements, we still
don't understand why a TCP solution is required, or if so why rekeying
inband is required.

Further, I'm personally puzzled at the use of time-based keys - which
add a notion of time that TCP doesn't have (TCP has timeouts, not time),
and are not how other rekeying systems work (e.g., IKE).

Answers to those would be a start.

Joe