>> 3. In speaking to operators who were concerned about intentional >> leaks of routes to critical infrastructure, it seems that the tags >> should be secured so that a party anyone where on the net could >> verify which AS added the tag on transmission to specific peer, and >> verify if a tag had be modified or stripped in transit. > >I'm not sold on this property being essential, but it's certainly a >Nice To Have item. My reasoning on this is that the behavior of this >feature would be to inform a receiving peer that someone previously in >the as-path had suggested that it shouldn't be accepted at a given level of >the hierarchy. > >Rather than "maliciously" setting that property, they could have simply >not have propagated the route.
Jeff, Reading your last statement above, I feel there is a misunderstanding here. Take the example: Provider A ----[tag(A) = 'Not Up'] ----> Customer X ----[tag(A) = 'Unrestricted'; tag(X) = 'Unrestricted'] ---->Provider B Customer X is multi-homed and wants to maliciously leak the prefix update learned from Provider A to Provider B. Tags are added to the update on each hop and are transitive. Note that Customer X is maliciously changing the tag value set by Provider A. Customer X does not benefit merely by not propagating (as you suggested). Instead, Customer X benefits by maliciously modifying Provider A's tag from 'Not Up' to 'Unrestricted' while forwarding the update to Provider B. That is why securing the tag values (end-to-end) may be necessary. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
