Subject: [Idr] draft-sriram-route-leak-protection-00

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 28 Jul 2014 01:16:06 +0000

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 29 Jul 2014 17:09:50 +0000

Jacob,

Please see comment inline below.

Sriram

>Add a second attribute that means "The first attribute was added".

> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 29 Jul 2014 17:45:43 +0000

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:[email-masked]]
> Sent: Tuesday, July 29, 2014 10:10 AM
> To: Jakob Heitz (jheitz); IETF SIDR; [email-masked]; [email-masked]
> Subject: RE: draft-sriram-route-leak-protection-00
> 
> Jacob,
> 
> >If an AS asserts that the route can no longer be advertised up,  It
> >simply removes the first attribute along with its signature.
> 
> along with the origin's signature, a subsequent adversary AS can
> always cut and paste that thing 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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 29 Jul 2014 19:30:53 +0000

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 29 Jul 2014 19:38:47 +0000

Sriram,

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

> Sent: Tuesday, July 29, 2014 12:31 PM
> Then AS3 will not be able to validate AS1's signature, because AS1's
> sig covered the removed attribute.
> 
> Sriram
> 
> >--Jakob
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 29 Jul 2014 20:51:45 +0000

>I'm not proposing to include it in the BGPSEC signature, It would be a separate signature.

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 29 Jul 2014 21:06:55 +0000

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

> Sent: Tuesday, July 29, 2014 1:52 PM
> 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.
> Let us say, AS2 removed your proposed first attribute and the
> associated signature, and forwarded the update to its customer AS3.
> 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.
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 29 Jul 2014 23:05:22 +0000

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:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; [email-masked]; [email-masked]
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

> 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.
> *upstream provider* AS5, and AS5 would be fooled and oblivious of the 
> leak.
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Jul 2014 01:12:55 +0200

>     You are proposing two signature chains.

That to me has zero practical/real deployment relevance.

Cheers,
R.

On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi <
[email-masked]> wrote:

> 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
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 30 Jul 2014 00:01:56 +0000

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

> Sent: Tuesday, July 29, 2014 4:05 PM
> 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
> 
> 
> > 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.
> the
> > The same principles should apply here too with any other proposed
> sig
> > chain.)
> >
> > Sriram
> >