Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

2006.06.05 NANOG-NOTES TCP authentication with Ron Bonica

  • From: Matthew Petach
  • Date: Tue Jun 06 05:27:04 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=VeJ9EX5WCjD6Fb4m+NH3JYe8HjEM8y52U+I4j0ckMpLA47yZATOjfmHovQPcHS9c2yjT/DP7ZnBO3s+dJK5Xbblp6Jl/4EZG7VN/nEgmVy1ZVAJB2vXAxTqH6H3LPv6cDhSoShV1cX7x83QRD9C5RiyATiNsMRmEtKf4eFM/pdg=

2006.06.05 Ron Bonica
slides are at

Authentication for TCP-based routing and management
protocols, from Juniper.

A joint presentation, Alcatel, Cisco, Juniper.

Starts at NANOG at Washington 2 years ago,
security BOF; someone said they would MD5 auth
if they could update keys without bouncing their

Suprisingly small number of people actually
using MD5 authentication.

many ops don't authenticate TCP based routing
RFC 2385 doesn't meet operator needs.

CPU utilization
not so much of an issue for Juniper, [Cisco, Alcatel]
Juniper architecture separates forwarding and control
Key management
hard to change keys
requires bouncing sessions
Weak cryptography
easy attacks against MD5

Alternative approaches
in the protocols (BGP, LDP, etc)
--too much of a headache

Chosen Approach:
better TCP authentication
enhanced TCP auth option
Hitless key rollover
key chains configured on peer systems
time based key rollover
key identifier
Stronger cryptography

Enhanced Authentication Option
Kind - Length T/K Alg ID Res Key ID

Key chain
contains a tolerance parameter up to 64 keys
each key contains
id [0..63]
auth algorithm
shared secret
start and end time, both for trans and receive

Sending system procedure
identify active key candidates
start-time <= system-time
end-time > system-time
if there are no candidates, log event and discard
outbound packet
If there are multiple candidates, select key with most
recent start-time for sending

Calculate MAC using active key
calculate over TCP pseudo header, TCP header, and TCP
by default, include TCP options
(if you set the T bit, ignore TCP options)
Format enhanced auth option
active key ID

Receiving system proc.
lookup key specified by TCP option
determine whether that key is eligible
startime <= system - tolerance
end time > endtime + tolerance
[not sure if that shouldn't be
  end time > system time + tolerance, actually.  --MNP]
Calculate MAC
if calculated MAC matches received MAC, accept the packet

auth error procedure
discard datagram
do NOT send indication to originator
(doesn't adjust TCP counters)

Config example:
see examples on slide deck, they went past too

Q: how many of us are authenticating IBGP sessions?
A: majority in the room are
Q: how many of us are interested in a better way
of handling key changes?
A: lots of people!

Q: Russ Bundy?: are you planning on taking this work
into IETF to publish through that path?
A: Yes, went to RPsec, RPsec2, and SAG working group
mailing lists.

Q: Randy Bush, IIJ, were there any simpler proposals?
Clearly this was designed for the IVTF.
A: None that weren't already rejected by the team

Q: Steve Bellovin, Columbia U.  No longer security
IAD. Why reject IKE and IPsec?  It does all this, plus
more (which isn't so good)
Why not tie algorithm to the key, get it out of the
header, get more bits for other uses?
A: actually, alg. could be taken from the key; that's
the type of comment they're looking for in the IETF;
one arg for putting it in option is that is a quick way
to check without calculating the MAC,
second Q: is more interesting; why not use IKE with
just auth. -- no need for confidentiality in this
case.  It was discussed, one idea was to just use IPsec
with preshared keys, but then you have same key
rollover system, and key negotiation.  Those are
all probably good ideas.  Would like to do this
as a first phase, allow for manual key rollovers,
and in a second phase, you can negotiate a key
for one-time use.
Q: but in IKE/IPsec, you can use preshared key
mode in IKE;
A: but in this case, you'd still
need a system like this to roll over the keys
since you want to be able to change keys on each
end asynchronously

Christopher Ranch: Made the right choices, thank

Q: Eric ? from cisco: why is this more complicated?
A: being able to have multiple keys and roll them
over.   There are networks that have used the
same key for 10 years since they don't want to
bounce their sessions.  You just can't do that
with IKE.
This is an operations driven requirement, that
it be hitless.

Q: Jared Mauch, NTT america: how does he go in and
take his iBGP session, roll to this system without
making the NANOG mailing list?
A: [no answer provided]

Q: Bora Kilf?, Broadcom: about IKE not being able to
roll keys without a hit; if you use IKE v1, you can
lose the IKE SA, have the IPsec SA, rekey your
IKE SA, and then rekey your IPsec SA.
He agrees with steve, looks like they're re-iventing
large parts of IKE/IPsec all over again.

Q: Gary? want to avoid colo meets; you want to be able
to re-set keys without having to coordinate people
in different timezones.

Encourage people to participate in SAG to discuss
this and provide feedback.

Research forum speakers up next.

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.