Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication

From: Ron Bonica <[email-masked]>
Date: Mon, 3 Aug 2009 19:26:24 -0400

Folks,

RFC 2026 defines a HISTORIC RFC as follows:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.

I think that TCP-MD5 fits that definition.

The HISTORIC nomenclature doesn't mean that there is no longer an
installed base. It just means that something more recent is available.

                            Ron

Iljitsch van Beijnum wrote:
> On 29 jul 2009, at 12:48, Lars Eggert wrote:
> 
>> at the meeting, the question came up which status TCP-MD5 should  
>> have after TCP-AO is published. Specifically, whether it should be  
>> obsoleted by TCP-AO and/or if it should be reclassified as Historic.
> 
> First of all, I'd like to see some operational experience with TCP-AO.  
> Don't throw away your old shoes until you know whether the new ones fit.
> 
> Second, it's not like TCP-MD5 isn't being used. As such, "historic"  
> wouldn't apply. "Deprecated", maybe.
> 
> Third, why is it exactly that we can't simply move from MD5 to IPsec  
> to protect BGP sessions??
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Aug 2009 17:56:11 +0200

> installed base. It just means that something more recent is available.

I still think it's premature to change the status of RFC 2385 before a  
replacement is widely available operationally.

And yes, that can take a decade, see 32-bit AS numbers.

Iljitsch

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 4 Aug 2009 10:26:45 -0600

I believe the rfc2385 should be modified.

http://www.ietf.org/rfc/rfc2385.txt
4.1
   A connectionless reset will be ignored by the receiver of the reset,
   since the originator of that reset does not know the key, and so
   cannot generate the proper signature for the segment.  This means,
   for example, that connection attempts by a TCP which is generating
   signatures to a port with no listener will time out instead of being
   refused.  Similarly, resets generated by a TCP in response to
   segments sent on a stale connection will also be ignored.
   Operationally this can be a problem since resets help BGP recover
   quickly from peer crashes.

An authenticationless reset MUST be ignored by the receiver of the reset.
The originator of that reset knows the key associated with their bgp neighbor and SHOULD use the key to generate 
an authenticated reset if that session has been terminated for some reason.
This means, for example, that connection attempts by a TCP which is generating
signatures to a port with no listener could be refused with a authenticated reset instead of being timed out.
Operationally this would be an improvement over the current standard since resets help BGP recover
quickly from peer crashes.

The current rfc compliant behavior doesn't make authenticated reset work, it makes ALL RESETS fail.
We could just as well have a flag that says ignore resets for bgp. It would have the same value as today's rfc compliant router implementations.

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, August 04, 2009 9:56 AM
> To: Ron Bonica
> Cc: [email-masked]; [email-masked] IESG
> Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Aug 2009 09:36:04 -0700

Lars Eggert wrote:
> Hi,
> 
> at the meeting, the question came up which status TCP-MD5 should have
> after TCP-AO is published. Specifically, whether it should be obsoleted
> by TCP-AO and/or if it should be reclassified as Historic. A related
> issue I came across while trying to form an opinion of the former issue
> is if the publication of TCP-AO means that we can lift the Standards
> Variance for TCP-MD5 introduced by RFC4728. (I'm CC'ing the IESG because
> of this latter point, because that Standards Variance came from the SEC
> and RTG areas.)

I think you mean RFC4278.

Because TCP-AO is intended to replace TCP MD5, and because TCP MD5 is
considered less than desirable, it seems reasonable to both put forward
AO as draft-standard and declare TCP MD5 historic at the same time.

If TCP MD5 were safer, we might consider leaving it as-is, but at this
point I think we're really trying to push the deployed both away from
TCP MD5 and towards AO, so both steps seem useful together right now.

And although, in some sense, all new protocols might be sent out first
as experimental, that is not the default process for standards developed
in the IETF per se, nor is it useful in this particular case, IMO. There
is no experiment desired or intended. There are no backward
compatibility issues, nor are there interaction issues with other
protocols. The only current component for which there is any question is
NAT support, which might be an experimental extension if published
separately.

Joe

---

From: "Chaks Chigurupati (chaks)" <[email-masked]>
Date: Tue, 4 Aug 2009 09:48:42 -0700

One minor comment - Please see inline for [Chaks]

> Behalf Of Smith, Donald
> Sent: Tuesday, August 04, 2009 9:27 AM
> To: 'Iljitsch van Beijnum'; 'Ron Bonica'
> Cc: [email-masked]'; [email-masked] IESG'
> The originator of that reset knows the key associated with 
> their bgp neighbor and SHOULD use the key to generate an 
> authenticated reset if that session has been terminated for 
> some reason.
> This means, for example, that connection attempts by a TCP 
> which is generating signatures to a port with no listener 
> could be refused with a authenticated reset instead of being 
> timed out.

[Chaks] If the listener is not around, it is very likely that the
listener has withdrawn from TCP the knowledge about the 
various keys associcated with the neighbors. OR, TCP itself might have
purged that info as such info is usually "attached" to the listen
socket. So, it may not be possible for TCP to generate an authenticated
reset in the absence of a listener.

Chaks

> Operationally this would be an improvement over the current 
> standard since resets help BGP recover quickly from peer crashes.
> 
> 
> 
> We could just as well have a flag that says ignore resets for 
> bgp. It would have the same value as today's rfc compliant 
> router implementations.
>

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 4 Aug 2009 11:20:34 -0600

> From: Chaks Chigurupati (chaks) [mailto:[email-masked]] 
> Sent: Tuesday, August 04, 2009 10:49 AM
> To: Smith, Donald; Iljitsch van Beijnum; Ron Bonica
> Cc: [email-masked]; [email-masked]
> Subject: RE: [tcpm] status of TCP-MD5 after TCP-AO publication
> 

In ever implementation I have seen there is a shared secret in the BGP configuration.
It might mean "searching" the bgp configuration to find the neighbor's route ID and grab the shared secret associated with that router ID but that plus the incoming packet information (src_port, dst_port, sequence_numbers...) is enough to provide an authenticated reset. 

One issue here is that the reset would probably not be generated by the asic on the line card as it is in many cases today. So this would probably lead to a hit on to the cpu or npu (slow path). Some routers ignore authenticated resets which per the current version of the rfc can be viewed as rfc compliant:(

---

From: "Chaks Chigurupati (chaks)" <[email-masked]>
Date: Tue, 4 Aug 2009 10:28:03 -0700

> From: Smith, Donald [mailto:[email-masked]] 
> Sent: Tuesday, August 04, 2009 10:21 AM
> To: Chaks Chigurupati (chaks); 'Iljitsch van Beijnum'; 'Ron Bonica'
> Cc: [email-masked]'; [email-masked]'
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Smith, Donald
> > > An authenticationless reset MUST be ignored by the 
> receiver of the 
> > > reset.
> > > The originator of that reset knows the key associated 
> with their bgp 
> > > neighbor and SHOULD use the key to generate an 
> authenticated reset 
> > > if that session has been terminated for some reason.
> > > This means, for example, that connection attempts by a 
> TCP which is 
> > > generating signatures to a port with no listener could be refused 
> > > with a authenticated reset instead of being timed out.
> > 
> various keys 
> > associcated with the neighbors. OR, TCP itself might have 
> purged that 
> > info as such info is usually "attached" to the listen 
> socket. So, it 
> > may not be possible for TCP to generate an authenticated 
> reset in the 
> > absence of a listener.
> 
> It might mean "searching" the bgp configuration to find the 
> neighbor's route ID and grab the shared secret associated 
> with that router ID but that plus the incoming packet 
> information (src_port, dst_port, sequence_numbers...) is 
> enough to provide an authenticated reset. 

[Chaks2] My comment was based on the implementations that I know of.
Ideally, you don't want TCP code to be aware of BGP or LDP configuration
whatsoever. You would expect the BGP and LDP processes to make these
neighbor specific passwords available to TCP via a setsockopt() on the
listen socket. If the listen socket goes away, so do these passwords as
far as TCP is concerned.

Chaks

> 
> One issue here is that the reset would probably not be 
> generated by the asic on the line card as it is in many cases 
> today. So this would probably lead to a hit on to the cpu or 
> npu (slow path). Some routers ignore authenticated resets 
> which per the current version of the rfc can be viewed as rfc 
> compliant:(
> 
> 
> > 
> > Chaks
> > 
> > > Operationally this would be an improvement over the 
> current standard 
> > > since resets help BGP recover quickly from peer crashes.
> > > 
> > > 
> > > 
> > > The current rfc compliant behavior doesn't make 
> authenticated reset 
> > > work, it makes ALL RESETS fail.
> > > We could just as well have a flag that says ignore resets 
> for bgp. 
> > > It would have the same value as today's rfc compliant router 
> > > implementations.
> > > 
> > > > I still think it's premature to change the status of RFC 2385 
> > > > before a replacement is widely available operationally.
> > > >

---

From: <[email-masked]>
Date: Wed, 5 Aug 2009 10:22:11 +0100

New solutions may only become widely deployed if there is some indication that the existing deployment is in some way obsolete/historic. If you are now saying we can't call the existing solution obsolete/historic until there is wide deployment of the new solution then we are in a Catch 22...

Toby
____________________________________________________________________ 
Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Iljitsch van Beijnum
> Sent: 04 August 2009 16:56
> To: Ron Bonica

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Aug 2009 11:38:51 +0200

On 5 aug 2009, at 11:22, <[email-masked]>  
<[email-masked]> wrote:

> New solutions may only become widely deployed if there is some  
> indication that the existing deployment is in some way obsolete/ 
> historic. If you are now saying we can't call the existing solution  
> obsolete/historic until there is wide deployment of the new solution  
> then we are in a Catch 22...

Despite people telling me it has been around for years, I have never  
encountered AO in the wild. And with IPsec as a mechanism to protect  
BGP being a huge failure because the vendors couldn't make it  
configurable (remember, configuring BGP is a full time job in many  
cases!) and 32-bit AS numbers taking a decade to appear on the scene,  
I am worried that making RFC 2385 historic quickly may leave some  
operators with no way to protect BGP sessions.

Don't forget that people can easily run 2 year old code and deployment  
in Quagga is complex due to the fact that the actual authentication  
happens in the kernel, so if a late model Cisco or Juniper has AO but  
no MD5 and an older model or a Quagga box only MD5 but no AO we're in  
worse shape than we are today.

Also remember that what the crypto people think is good operational  
practice has nothing to do with what really happens in practice,  
setting up MD5 once and never changing the password is what happens in  
49% of all cases (with no protection at all in 50%), and considering  
the amount of attacks happening this seems quite sufficient.

Actually the thing that worries me most about MD5 is that it allows  
for CPU exhaustion attacks, especially as implementations seem to  
authenticate first and do TCP sanity checking later and RFC 3682 never  
caught on because it doesn't autonegotiate. Not sure of AO helps  
against those attacks, but IPsec could through the anti-replay counter.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Aug 2009 12:57:30 +0300 (EEST)

I'll probably regret putting in my 5c, but..

> AO as draft-standard and declare TCP MD5 historic at the same time.

(I think you mean proposed standard, not draft standard.)

I support making TCP MD5 historic if when TCP-AO is being approved 
there exist at least a couple of implementations of TCP-AO.  Just 
making there is real commitment behind TCP-AO.  If it's important to 
vendors, they will have implemented it long before RFC status. 
Otherwise, we can keep TCP MD5 status as is.

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