Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please

From: "Bora Akyol" <[email-masked]>
Date: Fri, 27 Jan 2006 12:34:42 -0800

The problem is that the other end of the connection is not necessarily
**my router**.

You have to synchronize your keys etc with a partner outside the
organization.

Clearly, this is easier than the general IPSEC key distribution problem,
but
still not easy when done in large scale.

Out of curiousity, how often do you change the TCP-MD5 keys in your
routers?
Do you use the same key for all BGP peers to the same peering AS?

Thanks

> -----Original Message-----
> From: Jeroen Massar [mailto:[email-masked]] 
> Sent: Friday, January 27, 2006 12:31 PM
> To: Bora Akyol
> Cc: David Ward; [email-masked]
> Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please
> 
> Bora Akyol wrote:
> > Can you please qualify "easily"?
> > 
> > Just like the TCP-MD5, the distribution of keys, management, 
> > synchronized rollover etc, become similar issues with IPSEC, no?
> 
> You mean to say that you still type every line of the 
> configuration file in your router!? :) Indeed it gives some 
> pains but a management utility for your router will take most 
> of those away.
> 
> Having an extra line for the configuration statements that 
> IPSEC brings is not much different from having the management 
> utility generate that line you needed to generate for the 
> TCP-MD5 option...
> 
> 
> Next to the IPSEC option, (maybe I missed out on this one) is 
> the option for checking the TTL, thus that it is still 255 
> already done? That would also already save quite some 
> trouble, at least it limits hijacking/rst's etc, if they are 
> possible, to the same subnet when spoofed packets could be 
> directed to the RE.
> 
> Greets,
>  Jeroen
> 
> 

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

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 27 Jan 2006 23:24:43 +0100

> You have to synchronize your keys etc with a partner outside the

Isn't that like in every situation? When it is your own network it is
indeed all in your own hands, but then you also have way more control of
the infrastructure itself.

> but still not easy when done in large scale.

Currently, with or with MD5 you will have a few fields (ip address, asn
etc) in an email, just add a couple of fields specifying those values.
It ain't that tough.

> Out of curiousity, how often do you change the TCP-MD5 keys in your

TCP-MD5 has more flaws than uses in our situation.
(If one is able to spoof packets on the subnet they can easily send
false TCP-MD5 packets and up goes the load on the RE)

In our case we give remote peers access to a website (ssl'd ;) where
they can login to and change their details without telling us. Thus
add/remove peers, change IP's etc. Of course this means that we do have
change management and before the change gets committed an engineer will
approve the change but it makes a number of things much easier. Indeed
we make it the other parties problem to set it up. In case where
somebody has a similar system one could take turns to do it.
In case you are wondering, yes that management system supports
configuring IPSEC, but not all platforms correctly support it
unfortunately, next to the overhead being quite great in some situations
and quite unnecessary in most others.

You could also work with emails or other forms for this of course,
making it automated simply makes your life easier and isn't that what we
are doing all this work for? :)

As an example, public system, for AS8298 (GRH) we have a fully automated
system which doesn't even ask engineers to commit, it does it directly;
the interface gives a user the right to make/remove/change peers for the
ASN and prefixes (based on IRR data) he is trusted for. Thus they stick
a new route6 in the RIPE IRR, tries to add peer, management tool checks
route6 object if it belongs to one of his authorized ASN's and allows
it. Presto, no work for us except for the initial approval ;)

PS: Maybe netconf could come into play here to standardize some way of
exchanging these informations?

> Do you use the same key for all BGP peers to the same peering AS?

No, per-peer a different key, otherwise it would be very silly.
The management interface enforces this policy.

Greets,
 Jeroen