Hi Stephen,
This is really great explanation. I did try to find this in some papers
and your slides but I could not.
So it confirms that even if we use "worse case" BGP update advertised by
customer to provider (1 hop only case) it will fit within 4K limit
easily. Of course for any subsequent advertisement we need increase the
message size and this is where the draft-ymbk-bgp-extended-messages
addresses the issue.
One sentence in your reply is still not clear:
If on users RSA, each signature would be at least 1K bytes, and might
be 2K bytes, depending on the key length size chosen. So, a 20-hop
path could yield a 20-40K set of sigs, independent of the other path
security data.
- What is the maximum key length possible and how big would be the RSA
signature with such key length ?
- What are the other path security data and what their size might be
min-max.
Many thx again,
R.
At 1:13 PM +0200 4/14/11, Robert Raszuk wrote:
no. it is telling the edge site, your paying customer, that they
can secure their prefix without upgrading hardware.
Can anyone in IDR or SIDR demystify for us here what securing BGP
really requires (certificates, signatures, attestations you name
it) if to secure a single prefix originated by customer site
requires more then 4K of BGP message size ?
BGPSEC calls for each AS hop along a path to sign AS path info.
Although the average path length is a bit less than 4 hops, there are
some very long paths that appear in FIBs, e.g., over 20 hops. The
desire to increase the max UPADTE size (from the current 4K limit) is
intended to accommodate very long paths. The principle contributor to
the size increase is the digital signature. If on users RSA, each
signature would be at least 1K bytes, and might be 2K bytes,
depending on the key length size chosen. So, a 20-hop path could
yield a 20-40K set of sigs, independent of the other path security
data.
The good news is that many long paths contain repeated AS#s, which
could be collapsed into a single signature. But, that optimization
has not yet been explored. Also, if we were to use DSA or ECDSA as a
signature algorithm, instead of RSA, the signature size could drop to
128 or 256 bytes, from 1-2K, a savings of a factor of 4-8. Still, a
20-hop path, with no repeats, might not fit in a 4K UPDATE, with all
of the other secruity data.
Hope that explanation helps.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
