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 protected]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; [email protected]; [email protected]
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:[email protected]]
> Sent: Tuesday, July 29, 2014 1:52 PM
> To: Jakob Heitz (jheitz); IETF SIDR; [email protected]; [email protected]
> 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
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
