North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: key change for TCP-MD5
- From: Barry Greene (bgreene)
- Date: Sat Jun 24 06:10:27 2006
- Authentication-results: sj-dkim-2.cisco.com; header.Fromemail@example.com; dkim=pass (sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1012; t=1151143657; x=1152007657;c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; firstname.lastname@example.org; z=From:=22Barry=20Greene=20\(bgreene\)=22=20<email@example.com>|Subject:RE=3A=20key=20change=20for=20TCP-MD5;X=v=3Dcisco.com=3B=20h=3Drw9sj7sVfmM2t65cWYy3EoOQFf8=3D; b=E+I2x62B9q9tzsoSPWy3IAPy/S9PELsYPHm/aLwSz/2SXjEroPW/Fn4e5L1QwNONq3YoCT8K24lcyRyeJQKqpV1A/ONT2nfXPNlFwMO/KwNief9xs1XK23MzhnlLS9EV;
> 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.
There is no push from the operators to look at AH check or the SPI check
in before the receive path punt. The push was to get something the
lowest common denominator engineering in the NOC can handle with a BGP
key roll. Hence draft-bonica-tcp-auth.
Build on the operator's requirements.
Build on experience with similar techniques.
Three vendors agree - all with working code.
> 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.
This is a major path. Everything from recoloring the packets coming into
your network to BCP38 to new tricks. But that is a different