North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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; d=gmail.com; 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.
not so much of an issue for Juniper, [Cisco, Alcatel]
Juniper architecture separates forwarding and control
hard to change keys
requires bouncing sessions
easy attacks against MD5
in the protocols (BGP, LDP, etc)
--too much of a headache
better TCP authentication
enhanced TCP auth option
Hitless key rollover
key chains configured on peer systems
time based key rollover
Enhanced Authentication Option
Kind - Length T/K Alg ID Res Key ID
contains a tolerance parameter up to 64 keys
each key contains
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
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]
if calculated MAC matches received MAC, accept the packet
auth error procedure
do NOT send indication to originator
(doesn't adjust TCP counters)
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
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
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
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.