Re: [GROW] draft-sriram-route-leak-protection-00
Jacob, Please see comment inline below. Sriram 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 signature. If an AS asserts that the route can no longer be advertised up, It simply removes the first attribute along with its signature. Since the first attribute must be signed by the originator, no one else can add it back. The assertion no one else can add it back is not true. In your proposal, as I understand it, only the origin AS is signing the first attribute to its neighbor (i.e. second AS). Therefore, after an AS along the path removes the first attribute along with the origin's signature, a subsequent adversary AS can always cut and paste that thing back. Please let me know if I misunderstood something. (Note: We carefully avoided this kind of cut and paste problem in Path Signing in BGPSEC by requiring each AS to sign to the next AS in the AS path.) Sriram Now, an AS that considers itself a provider of the advertised route to the peer from which it received the advertisement can filter on the presence of the second attribute and the lack of the first to prevent the leak. The advantage of this solution is that it will not expose the customer-provider relationship to any customers. --Jakob ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-sriram-route-leak-protection-00
ok. How about: Each AS signs it as having passed it along, just like the BGPSEC. Then after one AS removes it, a subsequent AS cannot add it back. --Jakob -Original Message- From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov] Sent: Tuesday, July 29, 2014 10:10 AM To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@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 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 signature. If an AS asserts that the route can no longer be advertised up, It simply removes the first attribute along with its signature. Since the first attribute must be signed by the originator, no one else can add it back. The assertion no one else can add it back is not true. In your proposal, as I understand it, only the origin AS is signing the first attribute to its neighbor (i.e. second AS). Therefore, after an AS along the path removes the first attribute along with the origin's signature, a subsequent adversary AS can always cut and paste that thing back. Please let me know if I misunderstood something. (Note: We carefully avoided this kind of cut and paste problem in Path Signing in BGPSEC by requiring each AS to sign to the next AS in the AS path.) Sriram Now, an AS that considers itself a provider of the advertised route to the peer from which it received the advertisement can filter on the presence of the second attribute and the lack of the first to prevent the leak. The advantage of this solution is that it will not expose the customer-provider relationship to any customers. --Jakob ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-sriram-route-leak-protection-00
ok. How about: Each AS signs it as having passed it along, just like the BGPSEC. Then after one AS removes it, a subsequent AS cannot add it back. Jacob, Sorry, but that still doesn't work. The signature validation would break. Say, the update received at AS3 is P [AS2 AS1], where AS1 is the origin. Let us say, AS2 removed the signed attribute (that you proposed), and sent the update to AS3. Then AS3 will not be able to validate AS1's signature, because AS1's sig covered the removed attribute. Sriram --Jakob ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-sriram-route-leak-protection-00
I'm not proposing to include it in the BGPSEC signature, It would be a separate signature. Once AS2 removes it, it removes the attribute and its signature chain. The BGPSEC attribute and its signature chain is a different signature chain and not removed. The second attribute I proposed will be covered by the BGPSEC signature chain and not removed. Jakob, OK, you are proposing a separate signature chain besides the BGPSEC sig chain. But any signature chain must continue end-to-end across the whole AS path. Because, if a signature chain is allowed to be removed at any point in the path, then it becomes vulnerable to cut and paste attack. Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], where AS1 is origin. Let us say, AS2 removed your proposed first attribute and the associated signature, and forwarded the update to its customer AS3. Now AS3 forwards the update to its customer AS4. AS4 can somehow learn that AS1 sent the first attribute to AS2 and signed it, and it can somehow get that whole 'goop' (i.e. the attribute and the sig of AS1). Then AS4 can add back the 'goop', and forward the update to its *upstream provider* AS5, and AS5 would be fooled and oblivious of the leak. (Note: Again think of the reason why partial path signatures are disallowed in BGPSEC. The same principles should apply here too with any other proposed sig chain.) Sriram --Jakob ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-sriram-route-leak-protection-00
Jakob,
OK, understood.
But I still have these additional concerns/questions about your proposed method:
1. People think having one signature chain in updates is bad enough.
You are proposing two signature chains.
2. How do you address the issue when an AS that is not the originator
Wants to signal to a peer that the update should not be propagated
Laterally to another peer or to an upstream provider
(I.e., update can only be forwarded to customers).
What tagging or attribute can you use to enable this if you were to extend
your method?
Please see what Method 2 does ('10' tag), slide 8 in my presentation:
http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf
3. The reason for your proposed method is that you wanted
ASes not to have to disclose peering relationships.
My method (the draft we are discussing) does not require that explicitly.
Sure, you can infer something from the tagging.
But even in your approach, if there were Routeviews/RIPE-RIS like
collectors,
That collected the signed updates, then it is easy to tell who stripped the
First attribute and towards which neighbor.
So there is an implicit discernable peering disclosure there too.
Sriram
-Original Message-
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; i...@ietf.org; grow@ietf.org
Subject: Re: [sidr] draft-sriram-route-leak-protection-00
No it wouldn't.
For AS4 to put the goop back in, it needs to add the signatures of AS2 and 3 to
the goop chain. The chain of ASNs in the new signature chain needs to be the
same AS chain as in the BGPSEC.
--Jakob
-Original Message-
From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
Sent: Tuesday, July 29, 2014 1:52 PM
To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@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 signature.
Once AS2 removes it, it removes the attribute and its signature
chain.
The BGPSEC attribute and its signature chain is a different
signature chain and not removed.
The second attribute I proposed will be covered by the BGPSEC
signature chain and not removed.
Jakob,
OK, you are proposing a separate signature chain besides the BGPSEC
sig chain.
But any signature chain must continue end-to-end across the whole AS
path.
Because, if a signature chain is allowed to be removed at any point in
the path, then it becomes vulnerable to cut and paste attack.
Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],
where AS1 is origin.
Let us say, AS2 removed your proposed first attribute and the
associated signature, and forwarded the update to its customer AS3.
Now AS3 forwards the update to its customer AS4.
AS4 can somehow learn that AS1 sent the first attribute to AS2 and
signed it, and it can somehow get that whole 'goop' (i.e. the
attribute and the sig of AS1).
Then AS4 can add back the 'goop', and forward the update to its
*upstream provider* AS5, and AS5 would be fooled and oblivious of the
leak.
(Note: Again think of the reason why partial path signatures are
disallowed in BGPSEC.
The same principles should apply here too with any other proposed sig
chain.)
Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-sriram-route-leak-protection-00
There is no need to send this attribute to a collector.
If a provider respects his customer's wishes to
privacy, he will strip the attribute before sending it
to a collector.
The worst thing is sending only one prefix per update and
having to sign it differently for each AS you send it to.
Compared with that, another signature chain is a drop in the bucket.
Maybe we can combine ideas.
Take your RLP attribute and sign it in another signature chain.
Each AS adds its bits and signs it again.
First AS to remove it means propagate to customers only
You still need the The 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; grow@ietf.org
Subject: RE: draft-sriram-route-leak-protection-00
Jakob,
OK, understood.
But I still have these additional concerns/questions about your
proposed method:
1. People think having one signature chain in updates is bad enough.
You are proposing two signature chains.
2. How do you address the issue when an AS that is not the
originator
Wants to signal to a peer that the update should not be
propagated
Laterally to another peer or to an upstream provider
(I.e., update can only be forwarded to customers).
What tagging or attribute can you use to enable this if you were
to extend your method?
Please see what Method 2 does ('10' tag), slide 8 in my
presentation:
http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf
3. The reason for your proposed method is that you wanted
ASes not to have to disclose peering relationships.
My method (the draft we are discussing) does not require that
explicitly.
Sure, you can infer something from the tagging.
But even in your approach, if there were Routeviews/RIPE-RIS
like collectors,
That collected the signed updates, then it is easy to tell who
stripped the
First attribute and towards which neighbor.
So there is an implicit discernable peering disclosure there too.
Sriram
-Original Message-
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz
(jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; i...@ietf.org; grow@ietf.org
Subject: Re: [sidr] draft-sriram-route-leak-protection-00
No it wouldn't.
For AS4 to put the goop back in, it needs to add the signatures of
AS2 and 3 to the goop chain. The chain of ASNs in the new signature
chain needs to be the same AS chain as in the BGPSEC.
--Jakob
-Original Message-
From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
Sent: Tuesday, July 29, 2014 1:52 PM
To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@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 signature.
Once AS2 removes it, it removes the attribute and its signature
chain.
The BGPSEC attribute and its signature chain is a different
signature chain and not removed.
The second attribute I proposed will be covered by the BGPSEC
signature chain and not removed.
Jakob,
OK, you are proposing a separate signature chain besides the
BGPSEC
sig chain.
But any signature chain must continue end-to-end across the whole
AS
path.
Because, if a signature chain is allowed to be removed at any
point in
the path, then it becomes vulnerable to cut and paste attack.
Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],
where AS1 is origin.
Let us say, AS2 removed your proposed first attribute and the
associated signature, and forwarded the update to its customer AS3.
Now AS3 forwards the update to its customer AS4.
AS4 can somehow learn that AS1 sent the first attribute to AS2 and
signed it, and it can somehow get that whole 'goop' (i.e. the
attribute and the sig of AS1).
Then AS4 can add back the 'goop', and forward the update to its
*upstream provider* AS5, and AS5 would be fooled and oblivious of
the
leak.
(Note: Again think of the reason why partial path signatures are
disallowed in BGPSEC.
The same principles should apply here too with any other proposed
sig
chain.)
Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
[GROW] draft-sriram-route-leak-protection-00
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 signature. If an AS asserts that the route can no longer be advertised up, it simply removes the first attribute along with its signature. Since the first attribute must be signed by the originator, no one else can add it back. Now, an AS that considers itself a provider of the advertised route to the peer from which it received the advertisement can filter on the presence of the second attribute and the lack of the first to prevent the leak. The advantage of this solution is that it will not expose the customer-provider relationship to any customers. --Jakob ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
