It's actually a good question, because it highlights that we don't even think
about this anymore.
Perhaps https://tools.ietf.org/html/draft-newman-network-byte-order-01
should be advanced to RFC.
A: Big Endian.
Regards,
Jakob.
-Original Message-
From: sidr On Behalf Of Alberto Leiva
Se
#x27;t have to accommodate knobs.
>
> Regards,
> Keyur
>
> Sent from my iPhone
>
>> On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) wrote:
>>
>> However it SHOULD be possible to
>> configure an implementation to send or accept the community when
>&
. A second example is
documented in [I-D.ietf-sidr-route-server-rpki-light].
Thanks,
Jakob.
> -Original Message-
> From: Chris Morrow [mailto:morr...@ops-netman.net]
> Sent: Friday, March 03, 2017 8:38 PM
> To: Randy Bush
> Cc: Jakob Heitz (jheitz) ; Chris Morrow
D NOT be used."
Thanks,
Jakob.
> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Friday, March 03, 2017 8:05 PM
> To: Chris Morrow
> Cc: Montgomery, Douglas (Fed) ; Alvaro Retana (aretana)
> ; Jakob Heitz (jheitz)
> ; draft-ietf-sidr-origi
Thanks. This is the part I was looking for:
> I would suggest one keep/use the locally computed validation state,
> not the signaled state.
Jakob.
> -Original Message-
> From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov]
> Sent: Friday, March 03, 2017 1:56 PM
&g
I assume that the ext-comm passes policy.
Thanks,
Jakob.
> -Original Message-
> From: Keyur Patel [mailto:ke...@arrcus.com]
> Sent: Friday, March 03, 2017 12:43 PM
> To: Jakob Heitz (jheitz) ; The IESG
> ; IETF-Announce annou...@ietf.org>
> Cc: draft-ietf-sidr-ori
f the router sending the extended-community
is using a different validation method, not RPKI.
Thanks,
Jakob.
> -Original Message-
> From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov]
> Sent: Friday, March 03, 2017 11:36 AM
> To: Alvaro Retana (aretana) ; Jakob Heitz (jhe
What happens if a BGP speaker validates a route in its own RPKI database
and finds it to be either Valid or Invalid (not NotFound) and also receives
the extended community that specifies a different validation state?
I don't see that condition covered in the draft.
I would say to ignore the extend
Found it.
https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08
Thanks,
Jakob.
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, January 20, 2017 4:55 PM
To: sidr@ietf.org
Subject: [sidr] EE cert to RTR
Is there a protocol to get the public
Is there a protocol to get the public key in an EE cert to the router?
Something like https://tools.ietf.org/html/rfc6810
needed to verify BGPSEC signatures.
Thanks,
Jakob.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
e RLP was added" bit in the BGPSEC signature.
Something like that?
--Jakob
> -Original Message-
> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Tuesday, July 29, 2014 4:05 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; g...@ietf.org
&
alapudi.sri...@nist.gov]
> Sent: Tuesday, July 29, 2014 1:52 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; g...@ietf.org
> Subject: RE: draft-sriram-route-leak-protection-00
>
> >I'm not proposing to include it in the BGPSEC signature, It would
> be a separate
posed will be covered by the BGPSEC signature chain
and not removed.
--Jakob
> -Original Message-
> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Tuesday, July 29, 2014 12:31 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; g...@ietf.org
>
0 AM
> To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; g...@ietf.org
> Subject: RE: draft-sriram-route-leak-protection-00
>
> Jacob,
>
> Please see comment inline below.
>
> Sriram
>
> >Add a new attribute that means "this route may be advertis
In GROW, at the mike, I proposed another solution:
Add a new attribute that means "this route may be advertised up".
This attribute must be signed by the originator of the route.
Add a second attribute that means "The first attribute was added"
This attribute must be included in the BGPSEC signat
o
prevent
the majority of route leaks without leaking customer relationship information.
--Jakob.
-Original Message-
From: Geoff Huston [mailto:g...@apnic.net]
Sent: Friday, November 22, 2013 3:21 PM
To: Jakob Heitz
Cc: Christopher Morrow; g...@ietf.org g...@ietf.org
Subject: Re: [GROW]
ot; and
> "invalid," but if all address space which no-one actually
> claims is open
> for whatever use anyone wants, then are we really making any
> progress in
> any meaningful way?
There is a difference.
Invalid: someone is certified to own it and someone ELSE is originating.
Unknown: No one is certified owner.
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
capability codes will soon be in short supply. Use a bit set in your capability
to indicate the "sub capabilities".
--
Jakob Heitz.
On Dec 6, 2012, at 8:47 PM, "Randy Bush" wrote:
>> Just noticed that two capabilities are defined in the draft. They
>> act
r or peer, then human intervention
is required before accepting it.
This way, human intervention occurs before the problem, not after.
What happened to that proposal?
Was it Brian Dickson?
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.i
Thanks John. That's the comment I was fishing for.
--
Jakob Heitz.
> -Original Message-
> From: John G. Scudder [mailto:j...@juniper.net]
> Sent: Tuesday, October 23, 2012 2:06 PM
> To: Jakob Heitz
> Cc: Hannes Gredler; sidr wg list
> Subject: Re: [sidr] origi
The issue is: once it's signed, it can't be removed. (you could always add
another one, but that would change BGP significantly).
"origin" does not seem to be an attribute subject to change.
--
Jakob Heitz.
On Oct 23, 2012, at 8:40 AM, "Hannes Gredler" wrote:
&
t; Number of pages: 6
>> URL:
>>
>>
>>
>> http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set
>> Htmlized:
>> http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00
>>
>> Abstract:
>> RFC 6472 (i.e., BCP 172) recommends not using AS_SET and
>> AS_CONFED_SET in BGP. This document updates RFC 4271 and
>> proscribes the use of the AS_SET and AS_CONFED_SET types of
>> the AS_PATH in BGPv4. This is done to simplify the design
>> and implementation of BGP and to make the semantics of
>> the originator of a route more clear. This will also
>> simplify the design, implementation, and deployment of
>> ongoing work in the Secure Inter-Domain Routing Working Group.
>>
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
only needed across trust boundaries.
More is unnecessary complexity.
--
Jakob Heitz.
On Jun 15, 2012, at 9:50 PM, "Randy Bush" wrote:
> bgpsec and confederations
>
> allow me to try to state clearly for the list
>
>When an update enters the first AS in
ation does not stop anyone from announcing an update.
It only requires the first AS in that update to be the
owner of the prefix.
Path validation prevents anyone from announcing an update unless
it was sent to them by an authorised AS. And they are authorised,
because it was sent to them by an authorised AS and so on, back
to the authorised originator.
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
here is no reason they can not be different.
>
> and here i thought that detecting that they differ, as an attack, is
> the core goal of as-path validation.
I thought it was to prevent an AS from
announcing an update that it was not authorised to.
An entirely different thing.
>
he name of this attribute makes for awkward prose since it has
> no natural singular. How about calling it BGPSEC_Path_Signature
> instead? Or Signed_Path or Signed_AS_Path sans brand name
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Might it be possible to create the key pair on the router?
Then you don't have to move the private key to the router,
You move the public key off the router. Much easier.
--
Jakob Heitz.
On Friday, May 04, 2012 6:54 PM, Christopher Morrow <> wrote:
> On Fri, May 4, 2012 at 9:37
that's also flawed.
You should be able to sign anything that you can.
Suppose you receive it from an ibgp peer that sourced it but didn't sign it.
--
Jakob Heitz.
On May 2, 2012, at 7:21 AM, "Sriram, Kotikalapudi"
wrote:
> John Scudder asked the following ques
know about it and use this knowledge to help
in the decision.
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
speaker.
>
> The above still doesn't deal with common deployment considerations
> such as as-override, replace-as and remove-private. I see there's a
> thread about
> proxy signing and perhaps that discussion is over there. I'll
> hopefully get
> to it in a few days.
>
> (And if you're not familiar with those three features and their
> deployment scenarios, please take some time to become familiar. Not
> dealing with them will be a significant deployment hurdle.)
>
> -- Jeff
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow <> wrote:
> On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz
> wrote:
>> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote:
>>
>>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk
>>&g
2 AS paths will create the opportunity for an error if they differ
and we don't want to go around the error-handling block again.
I agree with Robert. Today, there are many tools that interact
with BGP messages. If the AS_PATH disappears, they will all break.
--
Jakob Heitz.
___
B's router ignores AS_PATH
How can you assume this?
--
Jakob Heitz.
On Apr 8, 2012, at 9:07 AM, "Sriram, Kotikalapudi"
mailto:kotikalapudi.sri...@nist.gov>> wrote:
Andrew,
There isn't a reason for the problem as you point out to arise.
Your analysis assumes that
Let's just require that BGPSEC capable routers
also support 4 byte AS. Then we don't need to worry
about AS4_PTH.
--
Jakob Heitz.
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Shane
Amante
Sent: Thursday, March 29, 2012
Any place that does not receive a new BGP update can not be helped. Even with a
beacon.
Therefore, a freshness indicator in the BGP update itself is enough to
invalidate less fresh updates.
Only freshen the BGP update when you actually have a dispute with your old
provider.
--
Jakob Heitz
Could we not put a freshness indication into the BGP update?
Then everyone that receives the new update would know to invalidate the less
fresh paths.
Here is the key point:
The new update will reach everywhere that it needs to go.
Won't it?
No expiry time needed.
--
Jakob
of course, we would need to reinvent the AS_SET to go along with it, but this
time, enumerating each exact path.
Definitely unwieldy.
--
Jakob Heitz.
On Mar 29, 2012, at 9:10 AM, "Jeffrey Haas" wrote:
> On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote:
>&g
including sidr
--
Jakob Heitz.
On Mar 28, 2012, at 11:57 PM, "Jakob Heitz" wrote:
> This can be done.
> Like I said before: aggregate the signatures of the paths being aggregated.
> String all the signed paths together (after wrapping them with a header), add
> your
The issue is SIDR can not aggregate multiple paths.
Solutions I can think of:
1. Aggregate the signatures of the paths being aggregated.
2. Don't aggregate, but send both paths.
Should SIDR work on path aggregation?
Are there other possibilities?
--
Jakob Heitz.
-Original Me
I don't know. I'm just throwing ideas around.
However, it appears that inter AS multipath
has a lot of problems.
--
Jakob Heitz.
-Original Message-
From: Paul Jakma [mailto:p...@jakma.org]
Sent: Wednesday, March 28, 2012 6:10 AM
To: Jakob Heitz
Cc: rob...@raszuk.net;
-path?
--
Jakob Heitz.
-Original Message-
From: idr-boun...@ietf.org [mailto:idr-boun...@ietf.org] On Behalf Of Robert
Raszuk
Sent: Tuesday, March 27, 2012 1:57 PM
To: Tony Li
Cc: i...@ietf.org List
Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath
Hi Tony,
>> * P
https://datatracker.ietf.org/meeting/83/agenda/sidr-drafts.pdf
link on agenda page is broken
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
would be up
to the network operator. By default, it would not be
considered at all.
--
Jakob Heitz.
-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
Christopher Morrow
Sent: Thursday, March 22, 2012 6:26 PM
To: rob...@raszuk.net
Cc: sidr@ietf.org
Monday works for me.
Friday not.
--
Jakob Heitz.
-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Murphy,
Sandra
Sent: Monday, March 19, 2012 2:37 PM
To: sidr@ietf.org
Subject: [sidr] possible additional meeting times
The routing ADs have
against which validation has not been run (no validation at
all or some knob turned off) should not be marked Valid. that would
be a lie. it should be marked NotFound.
It isn't quite NotFound either. How about a new value: NotChecked.
--
Jakob
The essence IMO:
If A sends a packet to B,
then A must trust A's provider and B's provider
and by extension, their providers and so on.
A does not trust other customers of those providers
and does not want his packet transiting any of them.
Now, design the routing to make that happen.
I stand corrected. Good idea.
If I understand it right, the presence of a BGPSEC signature
AND the absence of a provenance signature signals that
the prefix has left the set of AS's that are contracted
to provide it reachability.
--
Jakob Heitz.
> -Original Message-
>
That's like making the British drive on the right: you can not incrementally
deploy.
--
Jakob Heitz.
On Nov 22, 2011, at 8:51 AM, "Brian Dickson"
wrote:
> On Tue, Nov 22, 2011 at 8:45 AM, Randy Bush wrote:
>
>>
>> do you expect it to be covered b
> Basically, if you have BGPsec enabled with a given peer, you might get
> a combination of signed and unsigned from that peer - but for a given prefix,
> you MUST only get one or the other. Invalid-sig != unsigned.
>
> Accepting unsigned as a "fast" short-cut is insane, frankly.
Why?
BGPSEC does
When S sends a packet to D, that packet should traverse
only ASs that S trusts OR that D trusts. If the packet
traverses an AS that NEITHER S NOR D trusts, then a route
leak has occurred.
I would generally avoid using packet flow models as a way to describe
BGP security issues...
The ultimate goa
> -Original Message-
> From: christopher.mor...@gmail.com
> [mailto:christopher.mor...@gmail.com] On Behalf Of Christopher
> Morrow
> Sent: Sunday, November 20, 2011 10:06 PM
> To: Jakob Heitz
> Cc: Danny McPherson; sidr wg list
> Subject: Re: [sidr] Route Leaks
of ASs trusted
by its originator, Brian's "transit" bit turns off.
--
Jakob Heitz.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf
> Of Danny McPherson
> Sent: Wednesday, November 16, 2011 8:23 PM
> To: sidr wg list
> -Original Message-
> From: Russ White [mailto:ru...@riw.us]
> Sent: Tuesday, November 15, 2011 8:40 PM
> To: Shankar K A
> Cc: Jakob Heitz; sidr@ietf.org
> Subject: Re: [sidr] Burstiness of BGP updates
>
>
> > But strictly speaking, IMO we should only ac
> -Original Message-
> From: Russ White [mailto:ru...@riw.us]
> Sent: Tuesday, November 15, 2011 7:32 PM
> To: Jakob Heitz
> Cc: sidr@ietf.org
> Subject: Re: [sidr] Burstiness of BGP updates
>
>
> > The only utility I can see is in protecting reachabili
anyone
stealing passwords. To me, all this talk of BGP validation
preventing hacks is a load of fantasy.
The only utility I can see is in protecting reachability.
The only problem I can imagine with installing an unsigned
route is that the destination becomes unreachable. If it
was unreachable to begin
h
the signature.
I am saying to put that signature into a separate
connection, so as not to delay the higher urgency
regular updates.
--
Jakob Heitz.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf
> Of Russ White
> Sent: Tuesday, Novem
> From: George, Wes [mailto:wesley.geo...@twcable.com]
> Sent: Monday, November 14, 2011 7:04 PM
> To: Jakob Heitz; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
>
.
Basically, in the large majority of cases, a signature does not
change the bestpath.
--
Jakob Heitz.
> -Original Message-
> From: George, Wes [mailto:wesley.geo...@twcable.com]
> Sent: Monday, November 14, 2011 5:37 PM
> To: Jakob Heitz; Randy Bush
> Cc: Sriram, Kotika
The difference is that today's updates all have the same urgency.
BGPSEC is not urgent. It doesn't matter if you don't receive a signature for a
few minutes.
An UNREACH is not signed.
--
Jakob Heitz.
On Nov 14, 2011, at 6:26 AM, "Randy Bush" wrote:
>> It wil
signed one. It is simply "NotFound" instead of "Valid".
If you put the BGPSEC traffic into a separate non-urgent
session, this spruce goose might just get off the ground.
--
Jakob Heitz.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun..
If the router has other work, it can simply stop reading the tcp socket. That
would put the tcp into persist state and the sender will stop sending. This is
only possible if the beacons are in a separate tcp session.
--
Jakob Heitz.
On Nov 11, 2011, at 5:02 PM, "George, Wes" wrote
Don't forget, BGPSEC sends one prefix per update.
Current traffic is 2 to 3 prefixes per update.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf
> Of Eric Osterweil
> Sent: Thursday, November 10, 2011 10:46 AM
> To: Christopher Morrow
> Cc: Srira
so for other updates.
I think beacons should be transmitted in a TCP session
separate from the normal BGP traffic, so as not to delay
that.
--
Jakob Heitz.
> -Original Message-
> From: Eric Osterweil [mailto:eosterw...@verisign.com]
> Sent: Wednesday, November 09, 2011 12:3
Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3
beacons per day.
--
Jakob Heitz.
On Nov 8, 2011, at 5:00 AM, "Sriram, Kotikalapudi"
wrote:
>>
>> ooc, in regards to the above: is there any detailed analysis of how much
>> extra overh
On Nov 4, 2011, at 3:41 PM, "Brian Dickson"
wrote:
> Once a route crosses a peer connection or goes "downhill", it can no
> longer go "uphill"
> or cross another peering link.
Why can it not cross a peering link?
--
Jakob Heitz.
_
ld be route leaks:
> A - B - C
Why is this a leak?
> A <- B -> C
To me, this (and anything that contains it) is the only leak.
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
l dictate how to deal with it.
An AS sets the "down" bit to indicate its wish that
the announced prefix stay within the customer's bounds.
As it is signed, it can not be changed further down
the path.
--
Jakob Heitz.
On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote:
gt; i call this the lazy customer. they probably pay me to one or more of
> provision the circuit, configure their cpe, ... i might as well
> provision their certs and roa.
Will you sign his announcement too?
If he doesn't implement sidr on all his routers yet,
he will
split it more.
However, I could sub-allocate 10.0.666.0/24 to Randy and need split nothing :)
--
Jakob Heitz.
On Sep 30, 2011, at 7:35 AM, "Randy Bush" wrote:
>>>> my read of 10.0.0.0/16-16 is an exact match
>>>> and 10.0.0.0/16-32 is a subtree match (&#x
10u to validate an incoming prefix.
How long to validate an incoming path?
How long to generate/sign an outgoing path?
To one neighbor? To all neighbors?
--
Jakob Heitz.
On Sep 12, 2011, at 7:33 AM, "Randy Bush" wrote:
>> Q2: Is it well rooted in the historical measurem
real measurement and
> modeling. until i, or someone whose methods i trust does so, all is
> conjecturbation.
Do you trust this?
http://www.ietf.org/proceedings/81/slides/sidr-2.pdf
--
Jakob Heitz.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
By doing "converge first verify later", the router can be made cheaper.
However, there is still the cost of the RPKI and the cost of
running/maintaining it.
My guess is that will bury the cost of the routers.
Just a guess, Randy.
--
Jakob Heitz.
On Sep 9, 2011, at 9:22 AM, "Rus
in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
--
Jakob Heitz. x25475. 510-566-2901
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
, a question for you Rob. Will your customers pay the premium for BGP
security?
--
Jakob Heitz.
On Sep 7, 2011, at 5:05 AM, "Rob Shakir" wrote:
> On 11 Aug 2011, at 22:40, George, Wesley wrote:
>
>> Danny said,
>> "Periodic updates of the entire routing
A push model is just an idea.
It is highly likely to have lots of problems.
I haven't thought much about it.
Has it come up before and was it discredited?
Is it worth developing?
--
Jakob Heitz.
> -Original Message-
> From: Sandra Murphy [mailto:sandra.mur...@sparta.c
Beaconing 3,600,000 paths (from RIB size preso) every 8 hours
is 125 updates per second on average. More than a few percent extra load.
--
Jakob Heitz.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On
> Behalf Of Danny McPherson
> Sen
ather than waiting for them to ask.
--
Jakob Heitz.
On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" wrote:
>
> On 8/9/11 9:42 PM, "George Michaelson" wrote:
>
>>
>> On 10/08/2011, at 11:34 AM, Danny McPherson wrote:
>>
>>
a change in path. It is more like an attribute.
--
Jakob Heitz.
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On
> Behalf Of Montgomery, Douglas
> Sent: Monday, August 01, 2011 12:02 PM
> To: Randy Bush; t.petch
> Cc: sidr@ietf
78 matches
Mail list logo
