[91003] in North American Network Operators' Group
RE: key change for TCP-MD5
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jun 23 18:44:29 2006
Date: Fri, 23 Jun 2006 15:43:52 -0700
From: Owen DeLong <owen@delong.com>
To: "Barry Greene (bgreene)" <bgreene@cisco.com>,
Bora Akyol <bora@broadcom.com>, Ross Callon <rcallon@juniper.net>,
nanog@merit.edu
In-Reply-To: <C35ADD020AEBD04383C1F7F644227FDF01F45953@xmb-sjc-227.amer.cisco.com>
Errors-To: owner-nanog@merit.edu
--==========B7D40C9BC2F69294C754==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Why couldn't the network device do an AH check in hardware before passing
the
packet to the receive path? If you can get to a point where all connections
or traffic TO the router should be AH, then, that will help with DOS.
If you can limit what devices _SHOULD_ talk to the router and at least
define
some subset of that from which you demand AH on every packet, that helps but
isn't a complete solution.
Owen
--On June 23, 2006 11:49:33 AM -0700 "Barry Greene (bgreene)"
<bgreene@cisco.com> wrote:
>
>
>
>> If DOS is such a large concern, IPSEC to an extent can be
>> used to mitigate against it. And IKEv1/v2 with IPSEC is not
>> the horribly inefficient mechanism it is made out to be. In
>> practice, it is quite easy to use.
>
> IPSEC does nothing to protect a network device from a DOS attack. You
> know that.
>
> DOS prevention on a network device needs to happen before the TCP/Packet
> termination - not the Key/MD5/IPSEC stage. The signing or encrypting of
> the BGP message protects against Man in the Middle and replay attacks -
> not DOS attacks. Once a bad packet gets terminated, your DOS stress on
> the router kicks in (especially on ASIC/NP routers). The few extra CPU
> cycles it takes for walking through keys or IPSEC decrypt are irrelevant
> to the router's POV. You SOL if a miscreant can get a packet through
> your classification & queuing protections on the router and have it
> terminated.
>
> The key to DOS mitigation on a network device is to have many fields in
> the packet to classify as possible before the TCP/Packet termination.
> The more you have to classify on, the more granular you can construct
> your policy. This is one of the reasons for GTSM - which adds one more
> field (the IP packet's TTL) to the classification options.
>
> Yes Jared - our software does the TTL after the MD5, but the hardware
> implementations does the check in hardware before the packet gets punted
> to the receive path. That is exactly where you need to do the
> classification to minimize DOS on a router - as close to the point where
> the optical-electrical-airwaves convert to a IP packet as possible.
--
If it wasn't crypto-signed, it probably didn't come from me.
--==========B7D40C9BC2F69294C754==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFEnG6sn5zKWQ/iqj0RAmqgAJsGHUTx566cBWrZ8ZeMj+ezHPswVgCfUnea
S06Tnz2qLl0kOWdHHB+YoFk=
=6RtF
-----END PGP SIGNATURE-----
--==========B7D40C9BC2F69294C754==========--
