I’m behind on mail but Sriram suggested I pay attention to this, so here’s a drive-by comment, and if this comes up in SIDROps in Chicago I’ll do my best to attend and participate in the discussion there.
Being pragmatic, I understand that the risk is low for exceeding the max size without extended message support based on the average AS-path length, but I have concerns about the suggested solution that treats unsigned updates as a fallback path for updates that would otherwise be too large. First, I don’t believe that there is any construct within the current BGPSec setup that allows for this sort of mixed mode where most updates are signed but some subset are not. Normally it’s something negotiated on session establish - either BGPSec is supported by both neighbors, or it is not - and the BGP machinery handles updates accordingly. So likely the document would need some additional guidance on how that mixed mode is supposed to work. I think it’s pretty straightforward since there is already a defined process for stripping signatures and sending unsigned updates, but there’s sufficient grey area that I am not comfortable leaving this “as an exercise for the implementer” since it needs to properly interoperate. And if what is being suggested is that one update being too large drops the entire session back to unsecured mode, that seems even worse. More generally, I have expressed concern in the past (including quite publicly at NANOG) about “failing open” and the impacts of this model. While it’s definitely the lower-risk method when we’re dealing with something as critical as routing updates, it has the net effect of creating situations where the very benefit gained by deploying the technology is negated because any number of problems can cause fallback to the unsecured model that is effectively the same as having not deployed in the first place. The deployment threshold for things like this is usually that the net improvement in protection has to be worth the increased overhead of deployment and maintenance. I have been having trouble making the argument that OV and PV fall on the right side of that line due to the amount of places where things fail open by design. Some of those concerns are addressed by work in progress to move away from rsync and address other potential failure cases, but the potential for what amounts to a silent failure where some subset of routes on a session that I expect to be secured suddenly are not seems high in this case, and thus I don’t see this as an acceptable tradeoff. Given the headwinds for deployment of path validation - it requires a certain level of hardware support (CPU/Memory) to deploy at real scale, software features that haven’t been implemented yet, etc., I don’t see a delay while we get extended message support sorted as any really serious deal-breaker. Realistically, vendors and operators will be better served if this set of features can be implemented as a group to minimize the amount of touching and re-touching the same area of code and certifying and deploying multiple code versions to get everything. In other words, if I were deciding on a deployment timeline, I’d plan to wait until a critical mass of features is available either way, so whether that waiting happens now or later, the result is the same, and the better focus would be to get Extended Messages moved through the process with all possible haste instead of trying to pull BGPSec back for late-stage changes to reduce its dependency on the former. Wes George > On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) <[email protected]> > wrote: > > Hi! > > [Speaking as AD] > > The requirement for Extended Messages has been in the BGPSec draft since the > beginning (at least the WG -00 version). Changing it now would mean a > significant deviation in the process – but not impossible. > > Before committing to supporting any change to the document, I would like to > see changes discussed in the sidr WG list. You may even be able to convince > the sidrops Chairs to give you some time in Chicago to discuss in person. We > would need the WG to reach consensus for such a change. > > > [Speaking as WG Participant] > > I think that a possible path forward is to take any reference to the Extended > Messages document out, and simply put text similar to this in (from Sriram’s > message): > > “BGPsec update size is subject to a maximum BGP update size. The maximum size > at present is 4096 bytes [RFC4271], and it may be extended to a larger size > in the future. If the sending router determines that adding its Secure_Path > Segment and Signature Segment causes the BGPsec update to exceed the maximum > size, then it will convert the BGPsec update to an unsigned traditional BGP > update [using the procedure in Section 4.4] and send the unsigned update. > (Note: Please see related discussion in Section 7.)” > > I would even just mention the “maximum message size” (with no specific > numbers) and leave out mention of any future changes. This way the BGPSec > documents (1) don’t depend on the Extended Messages document, and (2) they > depend on whatever BGP can do. If/when Extended Messages are settled and > implemented then BGPSec can make use of them (as can any other application > using BGP). > > > Thanks! > > Alvaro. > > > > > > > > > On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" > <[email protected] <mailto:[email protected]>> wrote: > > > Alvaro replied to me in detail.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
