See my reply below, but all in all, I think it would be a good idea
to either find a working group or create a list with security,
transport and inter-domain routing people and people who actually
implement this stuff and work on this to make it as good as it can be
without losing sight of the goal of providing something that's better
than we have today that can be implemented in the short term.
On 5-okt-2006, at 17:46, Steven M. Bellovin wrote:
My perspective:
...
I don't know that I agree with the details of your scenario, but
that's
irrelevant to my larger point: it isn't the implementation that
decides,
it's people.
Sure. If people want to do this in the manner that you describe, who
am I to object to that, unless I'm a customer. Obviously I can't
speak on behalf of anyone else, but I'm pretty certain that my
scenario is closer to what most people in the commercial BGP speaking
world do than the one that you described. However, my scenario
doesn't fit well with the mechanism outlined in the draft.
I also agree that it's better that everything be completely
automated. As
the I-D says, this is advice on an interim solution until we can
engineer
and deploy something better.
Yes, you've said this before. However, I don't find the draft as it
is now acceptable, because it can make operational problems persist
for much longer than they would in the absense of this mechanism.
I've outlined a solution to this, which, in my opinion, wouldn't
delay implemenation of the mechanism. Yes, it would mean adding some
BGP exchanges, but since implementation of the mechanism as outlined
in the draft already requires touching the TCP-MD5 code and the
addition of new configuration options, I don't think this is much of
an extra burden.
Alternatively, there's Fred's suggestion, which doesn't require
touching BGP although some details need to be worked out to make sure
there are no ill side effects.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf