Re: [sidr] [Idr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

Let's observe that mangling with AS_PATH is usually done for a reason .. to achieve reachability to some set of prefixes which otherwise would be dropped. So with this in mind a better question to think about from customer perspective is to choose either: - unsecure but reachable Internet

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

Randy, Thanks for the nicely articulated description of these elements of routing security work in SIDR. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] request for agenda items for interim meeting 6 Jun

Speaking as regular ol' wg member: Thanks for all of this John. Excellent thoughts. >Philosophically, the thing that makes me worry the most is that we're >cutting out one of BGP's fundamental elements and replacing it with one >which provides only a subset of its semantics. Specific things mi

Re: [sidr] request for agenda items for interim meeting 6 Jun

Roque, Yes, there has been some confusion about AS4_Path, I think my text in the protocol draft (both the current version, but especially in previous versions) is in part responsible for this. I agree that even if we included AS_Path in BGPSEC update messages BGPSEC speakers MUST support 4-b

Re: [sidr] register for 6 Jun interim meeting

The wiki page lists very few registrations for the interim meeting one week from today. Please do register if you intend to come. You should also register if you attend to participate remotely. Registration is by sending an email message to sidr-chairs+reg06062...@ietf.org. There is no registr

Re: [sidr] request for agenda items for interim meeting 6 Jun

[added IDR to cc] On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote: ... > About extensibility - as you say, any new segment type not built into > implementations would result in fatal errors. So any new segment type would > need to be built into implementations before use. The question then

Re: [sidr] Date and type of the next (end of June/early July) interim

Not many people have commented on Alexey's message. IETF process mandates that a face-face meeting be announced four week ahead, which is Friday 1 Jun, if we stay with face-face on 29 Jun. The subsequent meeting was proposed for 27 Jul, so keep that in mind as well. --Sandy ___

[sidr] are audio archive files for the ietf 83 sessions available?

Hi, I am looking for some detail on the IETF 83 Sidr discussions. It looked as if audio proceedings for IETF 83 were still online as there is html that says 'audio stream' next to the session times on http://tools.ietf.org/wg/sidr/minutes

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

> AS_PATH specifies the ASs through which the routing announcement has > passed. > >> Signed_AS_PATH is to verify the path that the update message takes. > and here i thought that detecting that they differ, as an attack, is the > core goal of as-path validation. Okay, I seem to be confus

Re: [sidr] request for agenda items for interim meeting 6 Jun

> >Right, and agreed (see "formally an attack" above). But to repeat my further >point, if the AS_PATH is present (even if not secured): "at least there's >scope for a >network operator on the receiving end to tolerate the validation failure and >use >the route anyway, if desired. In the case whe