IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-01-05. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: Benoit
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1025 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1033 EST Adjourned
(at 2017-01-05 06:00:03 PST)
draft-ietf-sidr-bgpsec-ops
Update: I noted when reviewing other sidr drafts on this telechat agenda that this draft treats 2119 keywords differently than the other drafts. That is, this draft explicitly excludes lower case versions of the 2119 keywords, while the other related drafts do not. Assuming that these drafts have the same target audience, I think that will be confusing to readers. I am okay with either approach; in fact I somewhat prefer excluding lower case versions. But I think consistency among a related group of drafts is more important. Just a few minor and editorial comments: -1, first paragraph: "It is thought...": Can you mention "who" thinks it? Otherwise that reads as "weasel words". -1, third paragraph: Please consider writing out "also known as" -4, first paragraph: I found "either" followed by "and/or" a bit confusing. I suggest simply dropping the word "either". -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended to offer permission, or describe reality? (The latter should not use a 2119 keyword.) -4, last paragraph: "a prudent operator will..." sounds like it might be worthy of a SHOULD. -6, first paragraph: "SHOULD/MUST only" constructions tend to be ambiguous. In this case, are we saying SHOULD only originated signed announcements, as opposed to unsigned announcements? Or as opposed to validating received assignments? If the latter, then the "need not validate" seems to weaken the SHOULD. -6, last paragraph: Can something be cited for the 84% assertion? -7, paragraph 6: This seems to say that signed paths MUST be signed. Does the "MUST be signed if sent to external BGP speakers" mean that the existing signature must not be stripped (as stated more weakly in the previous sentence), or does it mean the sender must re-sign the path? -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems like a statement of fact. -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as needed to understand this document. That suggests it should be a normative reference. -
Thanks for creating a document to begin to pen the upcoming gotchas of BGPsec. I have a couple small comments. Section 3. "All non-ROA considerations in the section on RPKI Distribution and Maintenance of [RFC7115] apply." Apart from the sentence being stylistically terse (which I don't really care about), If you follow this as a reading list and hit section 3 of RFC7115 it leaves the reader wondering what considerations apply exactly. May I suggest: " The considerations for RPKI objects (Certificates, Certificate Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), Trust Anchor Locators (TALs) [RFC6490], cache behaviours of synchronisation and validation from the section on RPKI Distribution and Maintenance of [RFC7115] apply. Specific considerations relating to ROA objects do not apply to this document" Forward apologies if that sounds pedantic. This is surely early days of BGPsec adoption and use. I have personal opinions about how adoption will go and what will be learnt or discovered along the way. So I do share Stephen's observation about painting one's self into a corner.
Quick question: I'm by far not an expert here, but I remember that there used to be some concerns that it is practical not possible to disable BGPsec once enabled. If that's (still) true, should this be mentioned here?
I reviewed -12 but I think all these comments are as (ir)relevant as ever;-) - general: given where we are with deployment I wonder would it be a good idea if this document explicitly said sometthing to the effect that "it's early days, this is what we think is the BCP but that may change over time, so while we think doing this is right, be careful to not paint yourself into a corner when doing this." - intro: this seems to say: first do rpki and only when that's finished start on bgpsec - is that really what's meant? The rest of the document makes me doubt that. I think what you maybe meant was "Any specific ASN needs to have setup RPKI for itself before it can speak BGPsec." - intro, 3rd para: where are the "special operational considerations" explained? A reference would be good. If there's no good reference, I'm not clear why saying this is useful. (Actual operators might find this clear of course, in which case, please ignore me.) - section 2: this refers to the BGPsec overview which refers back to this document, but says that this is informational rather than a BCP. Just noting that in case there's confusion and that's not just a typo or a case of the overview not having been updated. I expect the fix is to change the text in the overview. - section 5: What does "fully BGPSEC enabled" mean exactly? That could be referring to signing or to validation of signatures (with or without hard fails) or to never emitting unsigned or accepting unsigned announcements or to some combination of the above. It might be better to avoid use of such a term in order to avoid having to define it for now. (This relates also to the mail subsequent to Mirja's comments.) - section 7: MED could do with expansion and a reference. - section 7: I'm not clear what you mean by "RPKI version skew." You could explain that or maybe use another basis to explain why R0 and R1 might disagree, e.g. revocation status info availability or freshness maybe. - section 8: "forward signed to R" is a bit opaque (for me anyway, before I read the protocol draft). Maybe better to explain this a bit more. - I-D nits complains about some easily fixable things (about which I do not care:-)
Roni Even's Gen-ART review comments are worth checking -- did not see a response yet.
I support Stephen's comments.
Again, thanks for a very readable document. I did have one question - I saw that you're chatting about the same paragraph with Alissa, but I'm wondering if "the transitive closure of a client's customers" has a precise meaning. I know what a customer is, at the hand-waving level, but I'm not sure how I would know whether any particular case fit that description, at the corner-case level. Is "customer" being used a shorthand for another term that isn't depending on an economic transaction? (If this was "the transitive closure of a client's clients", for instance, I would know what that meant - and I'm not at all suggesting that's correct, only offering it as an example of the kind of thing I'm asking about)
= Section 5 = "Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers' customers' customers' etc." "MUST ... if and only if" is a strange construction. I'm assuming what is meant here is that Route Reflectors MUST NOT enable BGPsec unless there are eBGP speakers in their client cone -- that might be a more sensible way to phrase this since clearly enabling BGPsec isn't required for anyone. Also, for a normative requirement I think it would be better to be specific rather than saying "etc." (e.g., "a client's customers or customers thereof" or something like that). "Additionally, outsourcing verification is not prudent security practice." Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis though? I know this paragraph is not talking about that but since use of a trusted cache was mentioned in the protocol draft, this struck me as a slight discrepancy.
draft-ietf-sidr-bgpsec-pki-profiles
Thanks for addressing my discuss points. OLD COMMENTS below, I didn't edit 'em... - section 2: I think this is a bit badly written: "The use of BGPsec Router Certificates in no way affects RPKI RPs that process Manifests and ROAs because the public key found in the BGPsec Router Certificate is used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these)." Do you mean that there's no way that an entity can confuse a Manifest, ROA, CSR or BGPsec update so there's no issue with which public keys are used to verify the signatures on those data structures? - section 3: As noted in my comments on the BGPsec protocol, it'd be better to call out the SKI here if you don't add the direct ref to 6487 to the BGPsec protocol draft.
A few strictly editorial comments: - IDNits complains about some undefined references. - Abstract: Why is the phrase "(to routers within an Autonomous System)" in parentheses? -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader.
I'm posting a No-Objection, but I think Dale is correct in raising the remaining issues. Commenting those below: > 3.1.1. Subject > > However, each > certificate issued by an individual CA MUST contain a Subject name > that is unique to that CA context. > > E-mail from Sean Turner on 22 Dec 2016 says: > > I think this is just a case of a missing "CA" in front of the word > "context" so tweaking it to: ".... that is unique to that CA > context". The certs only need to be unique on a per CA basis the > subject name does not need to be unique across the whole of the > RPKI. The combination of issuer+subject+serial # plus all the > parent certs provides the uniqueness. > > However, there doesn't seem to be a standard meaning of the phrase > "CA > context". I can't find any occurrences in any RFC or in any I-D > other > than draft-ietf-trans-threat-analysis-NN. Is a good question. > It seems to me that the best solution is to put a cleaned-up version > of Sean's statement "The combination of issuer+subject+serial # plus > all parent certs provides the uniqueness." into the draft, as that is > admirably clear. (Unless, of course, there is a standard PKI phrase > for that requirement, in which case that could be used.) For > instance: > > However, the combination of subject name, serial number, issuer, > and certification path must be globally unique. That would be clearer for me, assuming that is what was actually meant, of course :-) > 3.3. BGPsec Router Certificate Validation > > The validation procedure used for BGPsec Router Certificates is > identical to the validation procedure described in Section 7 of > [RFC6487] (and any RFC that updates this procedure), as modified > below. For example, in step 3: "The certificate contains all > field > that must be present" - refers to the fields that are required by > this specification. > > This picks up the changes from Sean Turner's e-mail of 22 Dec 2016 > except it omits changing "that updates this procedure" to "that > updates that procedure", which seems to me to necessary to make the > wording correct. I think that’s right. > step 3: "The certificate contains all field that must be present" > > This doesn't match the text in RFC 6487, despite claiming to be > quoted: > s/all field/all fields/ and s/must/MUST/. Right. > 7. IANA Considerations > > No IANA allocations are request of IANA, ... > > I think this should be "No IANA allocations are requested of IANA", > or > probably better "No allocations are requested of IANA". > > E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar > comment on the IANA considerations and he suggested the first > option.", but no change has been made. OK
Following along with Stephen's discuss thread.
draft-ietf-sidr-bgpsec-protocol
I have a couple of fairly straightforward things I'd like to briefly discuss... (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the public key is a bad plan, for all the usual reasons. Why is it ok for that to be hardcoded here when it could change if/when new alg choices are made for the RPKI? If it is not too late then I think you should add a length or alg field to that. If it is too late to do that, then are we really ok that you will need to rev the BGPsec version number in order to get rid of all sha-1 code from your implementation? That seems like a bad plan for a new protocol. (2) Figure 8: It seems to me to be an error to omit the signer's ASN from the signed data and only have that included in the signer's certificate. Why is that intimate level of binding to the RPKI desirable? There may well be reasons but I'm not seeing 'em, and I am recalling that it took a chunk of effort to make CMS less dependent on X.509 for similar reasons (meaning identifying signers exclusively via cert issuer and serial in that case). I would expect that there could be demand to have some level of independence between BGPsec and RPKI for at least internal uses such as those noted in the spec already. (3) section 8: Is there a potential exposure here in that a relying party who emits e.g. certificate status checks or cert retrieval queries for an RPKI cert they've not previously seen is exposing something about the set of paths its traffic is likely to follow. (This is similar to why we have OCSP stapling in the web.) IIRC the RPKI specs may cover this but I suspect it'd be worth noting here as well even if so as this represents exposing something about BGP announcement content to off-path parties which I think is new for BGP. Is that a new thing for BGP? (I think the new aspect to the attack is that a bad actor who has already compromised some AS could more easily spot that traffic from the relying party's AS is likely to transit the compromised AS.)
- (Non actionable comment really aimed at the IESG and not the authors/WG...) I'm kinda sad that even today we don't appear to have learned to value deploy-ability more highly. I fear that BGPsec and RPKI will suffer a similar lack of deployment as seen with S/MIME and DNSSEC and for possibly similar reasons (complexity, not starting with modest improvements, requiring a number of parties to change before seeing benefits). I hope I'm wrong about that, but equally, if I'm not and RPKI/BGPsec deployment turns out to be very very slow, (as opposed to the optimistic, "just slow";-) then I also hope the IESG at that time will be willing to consider alternatives - it's too easy for the IETF to just get stuck when a technology like this fails to deploy. But maybe I'm wrong and this'll all be fine and will be widely deployed and used in a few years. - Figures 2 and 5 present the fields in different orders. That seems like a bad idea. - 3.2: The reference to the pki profile doc is not precise enough, the string "key identifier" does not occur in that draft - it's in RFC6487, 4.8.2. - 4.1, last para: is the distinction between an "internal peer" and "iBGP peer" sufficiently clear to routing folk? For me they sound similar but I assume it's ok. - 5.2, I think you need to say something to the effect that every Secure_Path MUST have a signature with an algorithm that is supported. As I read the text, the algorithm as stated here could be read to not require that. E.g. the para before the bullets on p25 could be read to mean "drop all stuff involving unsupported algs and then continue to process the rest of the stuff." - section 7: WRT non-deterministic signature algorithms, I think it'd be useful to note here that all such algorithms require good random number generation on the signer's system and that failing in that respect can expose the signer's private key. IMO deterministic signature schemes are better for this reason but the need for a good RNG is I think a real operational issue worthy of note.
First, thanks for a well written document! A few question on the design; not to propose changes but I would like to learn the reason why the design is as it is: 1) Why do you need to send two different negotiation capabilities for each direction instead of just using two flags in the same capability? And similar why don't you just announce multiple address families in the same capability (using variable length)? 2) Why are the Secure_Path elements and Signature_Block blocks not aligned but in two different lists (given there is and one to one mapping)? Wouldn't it be easier to just update one length field (at a fixed position) and attached the new information at the end? Or to ask the question differently: why is the format as shown in figure 8 not used in the message itself (->this is related to Suresh's question)? Questions on operation: 1) section 5 says "a BGPsec speaker MAY temporarily defer validation of incoming BGPsec update messages". Does this mean it has to remember its state before applying the update message such that is can revert to this state if it later detects that die update message was not valid? Or what action is supposed to happen if the update message is detected as not valid later on 2) sec 4.2 says "Next, the BGPsec speaker generates one or two Signature_Blocks." Are you sure it's at max 2? I guess this depends on the expected update cycles of the algorithm compared to the devices. Given update cycles for devices can be very slow and updates for algorithm can be fast if any security problems are detected, I wouldn't recommend to limit this to two. 3) In relation to the comment above, I'm not a big fan of the algo migration strategy in section 6.1. I understand the problem that all router on the path need to potentially support the algo. However, you do have an negotiation phase. So why don't you the advertise the signing algorithm in the negotiation capabilities? In this case the sender could at least choose to only send the one(s) that is/are also supported by the receiver or not use BGPsec at all if there is no match. However, I also understand that it is probably to late to change anything now and if there is wg consensus, I'm fine with that... 4) section 8.1 says "the recipient of a valid BGPsec update message is assured that the update propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_Path attribute." Is that true? It is assured that at least these ASes have been crossed but there might have been others on the path that did not sign the BGPsec_Path attribute, no? 5) Is it really necessary to create registries for "BGPsec Capability" and "BGPsec_Path Flags"? Given this is a really small number of bits/flags, I think new RFCs that update this RFC are enough to define a new use for these so far unused bits. Further, editorial proposals: 1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved') 2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1
* Section 2.1
The IANA registry at
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml may be a better reference for AFIs than RFC4760.
* Section 4.2
Is there a specific reason that the signature construction algorithm orders the
fields in the way it does? It does look pretty complicated to parse out and
arrange the fields this way from the BGPsec packet that was received.
Something like the following seems much simpler to calculate
+------------------------------------+
| Target AS Number |
+------------------------------------+ ---\
| Signature Segment : N-1 | \
+------------------------------------+ \
... |
+------------------------------------+ |
| Signature Segment : 2 | |
+------------------------------------+ |
| Signature Segment : 1 | \
+------------------------------------+ > Data from
| Secure_Path Segment : N | / N Segments
+------------------------------------+ |
... |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| Prefix |
+------------------------------------+
as the segment fields and signature fields are naturally grouped together in
the packet. Is there a difference in cryptographic strength between these two
constructions?
I share some of the concerns about deployability, but have nothing new to add to that conversation. Otherwise I just have a few minor comments: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops excludes non-capitalized versions of 2119 words. (That is to say, it treats them as their normal English equivalents.)] - 5.2, step 2: I'm almost sure I've missed something here, but if I understand correctly, previous sections talked about how a peer can propagate a BGPsec_Path attribute without modification. Will that cause a problem in this step if the immediate peer propagated an unmodified BGPsec_Path that came from a different AS? - 8.4, last paragraph: The text describes a replay attack, and delegates the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an informational reference; it seems like it should be normative.
+1 to the comment from Suresh about order. I though that something like what he proposed will minimize memcopies and possibly use of memory why hashing. So I am also curious to know answer to his question. Otherwise the document is very well written and it was a pleasure to read!
Perhaps I'm just having a good day, but this is one of the clearest BGP-related specifications I can remember reviewing. Thanks for that, and especially for the background on design decisions. I did have questions on two points (which are spread across multiple sections). I started out wondering why Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. isn't a MUST, but Section 7 explains this In Section 2.2, is was stated that a BGPsec speaker SHOULD announce support for the capability to receive BGP extended messages. Lack of negotiation of this capability is not expected to pose a problem in the early years of BGPsec deployment. However, as BGPsec is deployed more and more, the BGPsec update messages would grow in size and some messages may be dropped due to their size exceeding the current 4K bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec speakers negotiate the extended message capability within a reasonable period of time after initial deployment of BGPsec. Perhaps that's worth a forward pointer? (or maybe even dragging this paragraph forward from Section 7) I'm looking at BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero. (That is, pCount is only to be set to zero in cases such as route servers or AS Number Migration where the BGPsec speaker's peer expects pCount to be set to zero.) and wondering why that's not a MUST. If I'm understanding this correctly (which is theoretically possible), the BGPsec speaker is telling its peer that it's not participating as a transit AS, but the peer thinks it should be. Is there anything intelligent that the peer can do with the update? Section 7 refers to this SHOULD, while adding a few more SHOULDs. A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) with a transparent AS is expected to set pCount = 0 in its Secure_Path Segment while forwarding an update to a peer (see Section 4.2). Clearly, such an IXP SHOULD configure itself to set its own pCount = 0. As stated in Section 4.2, "BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero." This means that a BGPsec speaker SHOULD be configured so that it permits pCount =0 from an IXP peer and never permits pCount = 0 from a peer that is not an IXP. Again, I'm curious about why a BGPsec speaker wouldn't do this. Is that obvious, to those skilled in the art? I'm looking at Section 8.4, which adds some more background. The mechanism of setting the pCount field to zero is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. However, entities other than route servers could conceivably use this mechanism (set the pCount to zero) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker drops incoming update messages that set pCount to zero but come from a peer that is not a route server. However, note that a recipient of a BGPsec update message within which an upstream entity two or more hops away has set pCount to zero is unable to verify for themselves whether pCount was set to zero legitimately. So, the reason this is a SHOULD, and not a MUST, is because a recipient two or more hops away can't be sure pCount was set appropriately? But doesn't the SHOULD increase the chances to propagate an update with an inappropriate pCount?
- I share various people's concerns about the deployability of this protocol, but I realize this is where the WG ended up after many years of work so fingers crossed, I guess. - Fig 2: Shouldn't the signatures in Sig Block 2 have different identifiers (e.g., X2, Y2) than those in Sig Block 1? - Sec 6.1: "(likely a small number of years)" -- given how hard these things are to predict, is it wise to include this text here? - I was surprised not to see an example message or two in this document.
draft-ietf-avtext-avpf-ccm-layered
- MRST, MRMT, SRST - expand on 1st use please, not sure if there are more of those too - Just checking: I assume when "repairing" something, that requires the same security properties be maintained or re-established and that there's no bidding down attack here that e.g. a middlebox could mount here?
- Section 5: s/dependent from each other/dependent on each other/ - Section 6: The formulation "the authors' current understanding" seems a bit out of place for a document that is a product of a WG/the IETF; perhaps "based on current information" or some such would be better.
draft-ietf-idr-large-community
Brilliant. Thank you!
One question: Since the Global Administrator field could also be not an ASN, would it be useful to say something about what should be done if an unknow value is received (ignore, remove, log an error...)?
The first sentence of section 6 seems to delegate at least some security considerations to RFC 1997. That RFC's security considerations entirely comprises the statement that the RFC does not discuss security. (This would have been a DISCUSS, but I gather from discussion of the genart review that the authors intend to remove the sentence.)
Of course we shall approve this document and make it an RFC! Thanks for the work. However, I do agree with Robert Spark's Gen-ART comments re: the first sentence of the Security Considerations section. I'd either remove the sentence, add pointers to other RFCs with actual security implications content, or reformulate to ".... has similar security properties as RFC 1997 (even if those were not documented in that RFC)".
Thanks John for an excellent shepherd writeup.
I see from the abstract: "The attribute is suitable for use with four-octet
ASNs." I also see this text, which doesn't mention four-octet ASNs
The Global Administrator field is intended to allow different
Autonomous Systems to define BGP Large Communities without collision.
This field SHOULD be an Autonomous System Number (ASN), in which case
the Local Data Parts are to be interpreted as defined by the owner of
the ASN. The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295
[RFC7300]) is NOT RECOMMENDED.
What if the ASN is two bytes, we use padding? How?
Even if we would say: "This field SHOULD be an four-octet Autonomous System
Number (ASN)", it doesn't preclude inserting a two-octet ASN in the Global
Administrator field. Isn't it better to specify how?
From RFC 6793:
Currently assigned two-octet AS numbers are converted into four-octet
AS numbers by setting the two high-order octets of the four-octet
field to zero. Such a four-octet AS number is said to be mappable to
a two-octet AS number.
===============================
After some discussion on the idr list.
My reasoning has been:
either you mention that two-octet ASN can be represented in four-octets
(RFC6793) or you mention: suitable for all ASNs (2 or 4)
It's so obvious to you guys in your community.
Ok, it seems that we're going in circle here.
You guys understood my issue. It was DISCUSSed. I believe the draft should be
clearer, but this is not DISCUSS-level point any longer. Moving to a COMMENT,
and trusting the responsible shepherd and AD.
For the record, John's proposal solveds my issue.
OLD:
The attribute is suitable for use with four-octet
Autonomous System Numbers
NEW:
The attribute is suitable for use with all Autonomous System Numbers
including four-octet Autonomous System Numbers
High-time we did this thanks. I think the network reviewers suggestion to leave in the implmentation status is a fine one. it does naturally capture only a moment in time. but since it points to useful examples of implmentation that's good.
draft-ietf-i2rs-yang-network-topo
I agree with both of Kathleen's DISCUSS points.
I agree with Kathleen's discuss points and have one more aspect to offer that I hope you include in that discussion: This model I think will lead designers to only think about the nodes that are supposed to have access to traffic. (See also below about broadcast media.) The model will generally not capture the reality that some other nodes can also actually see or influence traffic and I think that will lead to vulnerabilities not being recognised. I don't have a good suggestion for how to fix that problem but I do think you ought mention it as a security consideration, e.g. something like: "For models such as these - the real world network may allow additional communications or links that are not represented in the model and such links may enable vulnerabilities that are liable to be missed when considering only the model. These models don't really capture the security or privacy aspects of the network." - 4.2 and generally: It is not clear to me how to represent broadcast media (e.g. radio) nor how IP multicast would be reflected in this model. I assume those can be done but as a bit of a hack. - nit: 6 authors and 4 contributors. I wish people (esp chairs) would just enforce the 5 author guideline and say why that's inappropriate in the few instances in which that is the case.
Stewart Bryant's Gen-ART comments are worthwhile to look at. Did the authors see them?
Reading this document one more time, some more editorial comment
-
OLD:
At the same time, where data specific to a network type does comes
into play
NEW:
At the same time, where data specific to a network type does come
into play
- The figure shows two Service Functions - X1 and X2 - mapping onto a
single L3 network element; this could happen, for example, if two
service functions reside in the same VM (or server) and share the
same set of network interfaces.
You meant X1 and X3, mapping to the same Y2 L3 network element, right?
- please expand ROADM
- There are multiple slightly different definitions of the datastore in the
different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the
latest one) and mention the reference.
- YANG definition "YANG: A data definition language for NETCONF"
I would use:
YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network
management protocols [RFC7950]
- OLD:
The abstract (base) network model is defined in the network.yang
module. Its structure is shown in the following figure. Brackets
enclose list keys, "rw" means configuration data, "ro" means
operational state data, and "?" designates optional nodes. A "+"
indicates a line break.
NEW (cut/paste from RFC8022 and
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09]
o Brackets "[" and "]" enclose list keys.
o Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.
o Abbreviations before data node names: "rw" means configuration
(read-write), "ro" state data (read-only), "-x" RPC operations or
actions, and "-n" notifications.
o Symbols after data node names: "?" means an optional node, "!" a
container with presence, and "*" denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
Note that you have two instances of this.
- Final comment: the security considerations should be better aligned with
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as replied to
Kathleen's DISCUSS.
Thanks for your work on this draft. I have a couple of things I'd like to discuss that may require some additional text, but should be easy to resolve. 1. Privacy considerations - I don't see any listed and the YANG module include a few identifiers as well as ways to group devices. I think privacy considerations need to be added for use of this module. 2. Security - the network topology and inventory created by this module reveals information about systems and services. This could be very helpful information to an attacker and should also be called out as a security consideration. The access and transport of this information is covered though in the considerations, just listing this threat would be helpful. Thank you.
Just a nit: Several places in the text make reference to the network.yang or network-topology.yang models. It would be nice to put a reference to the section where there are defined.
seems worthwhile that the misref draft-ietf-i2rs-ephemeral-state be converged with this one for publication. don't expect that's a big deal.
draft-ietf-curdle-dnskey-eddsa
I am a little suprised to read this: "A sufficiently large quantum computer would be able to break both. " What's sufficiently large in terms of quantum comupting? Is it really already necessary to say this? And here: "Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe." What's perfectly safe? However no need to change anything... was just wondering.
draft-ietf-idr-deprecate-30-31-129
Stop them before they kill again. Imho, while we're not doing it here, we should probably provide advice to implementers or even revisit how we allocate them on how to do this safely in the future cause squatting on code points is definite minefield here.
draft-ietf-sidr-as-migration
I will note that progressing this as Standards track does presume that BGsec will also progress as Standards track, or that there will be a downref from PS to Experimental.
I agree with Kathleen (and others) in terms of timing on seeing this particular document. What is the time-line for seeing BGPSec at the IESG now that the in-WG discussion regarding its status has concluded?
Similar to other comments, not sure why this is being progressed now. If progress with BGPsec (or after), would help to ensure alignment and avoid the need to update the metadata later (Section 8 RFC Editor note). As BGPsec has a pointer to this draft (seems a bit strange for it to have a pointer to it's update) - why not include the appropriate text in BGPsec itself to support. And then this draft would not need to "update" and both documents could simply reference each other.
(The deferral of this draft until the bgpsec protocol draft is on the agenda resolves my comment about timing.) From a strictly style perspective (that is, you can take this or leave it), I find the heavy use of present continuous tense confusing to read.
Per Wassim Haddad's Gen-ART review (thanks!), there seems to be a word missing here: "Route Origin Validation as defined by RFC 6480 [RFC6480] does not modification to enable AS migration, ..."
I think the Abstract & introduction are too brief. A lot of concerns might have been avoided with a little more explanation up front. I removed my discuss points as expanding the abstract to include more details in the introduction that appear in the security consideration section isn't really discussable, but would help the draft IMO. Comments are left, I didn't comb through them, so take or leave the ones that have not been addressed. Thank you. --- Standards Track *is* right for this document, but it takes a little to understand that while the document doesn't make any changes to the protocol, it does describe how implementations use the protocol to deliver a specific function. --- Some rewording of the introduction could go a long way in helping with document clarity: Possibly: "This document describes how ASN migration may be performed securely using the RPKI and BGPSec mechanisms. It defines the implementation behavior during ASN migration, but does not define any changes to the BGPSec protocol." *Note - if the last part remains true --- 1.2 refers to "private ASNs" and this term is well understood. But the referenced RFC 1930 doesn't use that term. It uses the term "Reserved AS Numbers" and describes them as "reserved for private use". --- Section 2 has "...merging two or more ASNs..." I think it is ASes that are being merged. Ditto "...is not enabled between the ASNs..." --- Section 3 has Since they are using methods to migrate that do not require coordination with customers, they do not have a great deal of control over the length of the transition period as they might with something completely under their administrative control I can't parse this. If the methods do NOT require coordination with customers, surely the methods are wholly under the control of the operator. Is there a typo: s/do not require/require/ ? Or is there some other message? --- Section 3 As solutions were being proposed for RPKI implementations to solve this transition case, operational complexity and hardware scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network have been carefully considered. As worded (passive voice) it demands a citation. Possibly it is meant to say that operators have carefully considered this. Maybe that the SIDR WG has done the consideration. --- Section 3 It would be helpful to add a final sentence saying what this section goes on to do. I think it examines the basic functions of RPKI to determine whether they already handle ASN migration and to identify any issues that might arise when an ASN changes. --- 3.1 Route Origin Validation as defined by RFC 6480 [RFC6480] does not need a unique solution to enable AS migration, as the existing protocol and procedure allows for a solution. That doesn't read too well to me at least, do you mean something like: Route Origin Validation as defined by RFC 6480 [RFC6480] does not need modification to enable AS migration, as the existing protocol and procedure allows for a solution as follows. --- 3.1 In the scenario discussed, AS64510 is being replaced by AS64500. s/discussed/discussed in RFC 7705/ --- There are some abbreviations that will need to be expanded (e.g., ROA) --- 3.2.1 has... However, there is currently no guidance in the BGPSec protocol specification [I-D.ietf-sidr-bgpsec-protocol] on whether or not the forward-signed ASN value is required to match the configured remote AS to validate properly "currently" looks unlikely to change at this stage given the status of draft-ietf-sidr-bgpsec-protocol. So, either - make the changes to draft-ietf-sidr-bgpsec-protocol while you can or - change this text to reflect reality as... "However, there is no guidance..." --- 3.2.1 s/remote as 64510/remote AS 64510/ s/local as 64510/local AS 64510/ --- 3.2.1 It took me several attempts to parse... Assuming that this mismatch will be allowed by vendor implementations and using it as a means to solve this migration case is likely to be problematic. Did you mean: If we assume that this mismatch will be allowed by vendor implementations and that using it as a means to solve this migration case, then we are likely to see problems when implementations disallow the mismatch. --- 3.2.2 However, if the updates are left intact, this will cause the AS Path length to be increased, which is undesirable as discussed in RFC7705 [RFC7705]. On reading this I thought: "Undesirable is OK for a short transition period," but I went and read 7705. There, in the introduction, it says "it is critical that the ISP does not increase AS_PATH length during or after ASN migration". So I would s/is undesirable/must be avoided/ (Note: Section 4 has this as MUST NOT.) --- The text before the bullets in section 4 should... s/listed in no particular order:/listed in no particular order. BGPSec:/ Then "BGPSec" can be deleted from the first bullet. --- In section 5... Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPSec implementation to address this use case. I know what this is saying, but it is a bit skewed since implementations are not normally in scope for our specs. Perhaps... Since that PE has been moved to AS64500, this described a new behavior for implementations to forward-sign AS64510 with pCount=0. --- Section 5 This document proposes applying a similar technique Too late! If this is to be an RFC on the Standards Track then This document describes how to apply a similar technique --- Section 5 has (see section 4.4 of the above-referenced draft) Really? Too tired to actually include the reference? But by the time this document is published the reference will be an RFC and this text will be left dangling. ---- 5.2 The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration implementation only. s/implementation/scenario/ --- I always love it when the Acknowledgements section thanks one of the authors :-) --- Section 8 This has happened before, but it usually leads the IESG to say "Hang on, why don't you just fix the protocol spec?" At the least, the Abstract and Introduction need to include the right text that would be present for an "Update". That is: what document is updated and what change is made. --- Section 9 Is "reasonably secure" should be replaced with something more accurate. Maybe this will come with the new text Sandy is working on. this is not fundamentally altering the existing security risks for BGPSec. That seems to say "...is somewhat (or marginally) altering..." which doesn't sound good. --- I hope the more detailed review is helpful. I still need to look at BGPsec to feel more comfortable with this one.
draft-ietf-ospf-ttz
Questions on IANA section (not an OSPF expert, so please excuse me if I misunderstood something): - Don't you have to register both LS types 9 and 10 somehow? - And do the "Types for new TLVs in the new TTZ LSA" create a new registry or is this an existing one? Other minor comments: - What's a DR? Please spell this out! - There is only little normative language used in this doc. Potentially some more normative language could make things clearer. However I don't have concrete proposals what to change and I believe the most important parts are in normative language. So there is no urgent need to change anything but maybe another check would be good to make sure normative language is used where needed.
Thank you for working on this important spec. I would like to recommend its approval, but before that I had a request for a clarification, inspired by Orit Levin's Gen-ART review. In Section 5.1, what specifically is the requirement regarding OSPF TTZ/TTZID uniqueness. It just says "unique within a network". For instance, if I have TTZID 17 under Area 0 and Area 223 among the same set of routers implementing multiple Areas simultaneously, is that allowed? Or are different Areas automatically different networks? Can you specify an algorithm or rule, or make the current wording more precise?
Other comments from Orit are also worth noting.
I had some high-level context that took a while to build, but after I got through the following comments, I found the document clear to read for a non-OSPF guy. Thank you for that. The Introduction gives a fairly clear idea of what a TTZ is useful for, but the Abstract doesn't say anything about that. If we still think that people read Abstracts separately from RFCs, it would be useful to add a one-sentence summary naming the use cases that you've already identified for the Introduction. Perhaps something like "Topology Transparent Zones" allow network operators to restructure the areas in their network, and provide services while the reorganization is taking place, with fewer disruptions." But you folks would know best. I'm curious why A TTZ ID is a 32-bit number that is unique for identifying a TTZ. The TTZ ID SHOULD NOT be 0. is not a MUST. Could you give an example of why that would be a good idea? I found A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. very helpful, but it doesn't appear until the top of page 7. Perhaps it would be useful to put this into the Introduction (and, maybe even the Abstract). I had been wondering whether that was true from the beginning of the document, so it seems useful to say so much earlier.
draft-ietf-manet-olsrv2-sec-threats
I'm no expert on OLSRv2, and this may be the clearest security threats doc I've seen. Thanks for that!
I have two things I'd like to discuss to see if changes are needed or not: (1) Neither this nor RFC7186 seem to consider battery depletion attacks. Why is that ok? (2) 6.2: HMAC is *not* a digital signature mechanism. While loose terminology may be ok elsewhere, in this case, you shouldn't do that as it can lead to wrong conclusions. Digital signatures do provide origin authentication of sorts, but MACs do not, especially if keys are shared. It is not clear to me that some of the claims in 6.2.x of attacks being mitigated are in fact correct, given shared secrets. (Note: It could be that the claims are correct, I didn't have time to check back on all the vulnerability definitions, sorry. But I'd like to check, given the defective terminology.)
I found Elwyn Davies' Gen-ART review very useful (and in-depth). Have the authors seen it, and have they drawn conclusions from it or the discussion that ensued on the list? I found some of the answers enlightening.
Below is cut/pasted Victor Kuarsingh's OPS DIR review. Summary: The document analyzes currently assessed (known) security threats for the OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc Network (MANET). The document points to reference documents such as RFC7186, RFC7183, RFC7188 and RFC7181 and expands on the explanation of security vulnerabilities and how such vulnerabilities can be mitigated by currently documented security mechanisms. Text updates (suggestions / recommendations) are provided below the general feedback. General Comments and Feedback: Overall the document does cover the intention described per the abstract (summarized above). Descriptions of the vulnerabilities seem consistent with documents such as RFC7186 and RFC8183 which already cover detailed explanation of similar material. A few comments are noted in the in-line text overview below (some NITs / suggestions on wording), and a preference for avoiding such conventions which use taxonomy like "fresh", "lie" with preference for other options like "recent", "incorrect/ erroneous " may be better suited for such a document. Given this document is attempting to provide a incremental analysis of the security threats vs. how such threats fair with known security mechanisms in place, I would recommend that the a slight incremental bit of text (in-line or separate table) to show which mechanisms are purely related to implementation level protection (i.e. software written to enable protocol function) vs. deployment level options. It appears most of the protections are implementation level, but there seems to (at least) two examples of mitigations which may be deployment level (e.g. it was noted about IP forwarding on Linux boxes as well as wormholes which create [potentially undesirable] direct comm paths between participating nodes.). I think noting surveillance related activity for compromised hosts may also be useful to discuss in section 6 (hard to detect, but a potential threat). Other then that, I find the document useful as an analysis which discusses how the known threats are potentially mitigated by known mitigations. There are a few more editing items that can be found, but that can be addressed by the RFC editor. Section Review of - Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) Abstract - ok Introduction 1. P2 <old> operating with the assumption, that participants can be "trusted" to behave in a non-destructive way, is utopia. <suggested> operating with the assumption, that participants can be "trusted" to behave in a non-destructive way, is utopian. P4 <old> A first step towards hardening against attacks disrupting the connectivity of a network, is to understand the vulnerabilities of routing protocol, <suggested> A first step towards hardening against attacks disrupting the connectivity of a network, is to understand the vulnerabilities of the routing protocol, 1.1. OSLRv2 Overview P1 <old> They are described in the below with sufficient.. <suggested> They are described in the sections below with sufficient.. 1.1.1. Neighbour Discovery Good 1.1.2 MPR Selection Good 1.2 Link State Advertisement OK 1.3 OLSRv2 Attack Vectors ** use of honestly, lie, etc **. 2. Terminology ** for compromised router, it’s possible that only surveillance is the goal (may not actually send erroneous or incorrect information) ** . This may not be detectable, but dangerous none-the-less. 3. Topology Map Acquisition OK 3.1 Attack on Jittering OK 3.2 Hop-Count and Hop-limit Attacks OK 3.2.1 Modifying the Hop Limit OK 3.2.2 Modifying the Hop Count OK 4. Effective Topology OK 4.1 Incorrect Forwarding ** IP forwarding can also be turned of on commercial routers as well via config - quite easily ** Likely ops level mitigation needed. 4.2 Wormholes ** comment on section above. ** 4.3 Sequence Number Attacks P1 <comment> Not sure the word “fresher” in the sentence “long paths or other delays, is not allowed to overwrite fresher information” is the best choice. Technically, the latter arriving message due to delay/etc is fresher from the receivers point of view, but less desirable given the delay or path. 4.3.1 Message Sequence Number <comment> similar to above comment, perhaps “recent” is a better word to use vs. “Fresh” in the sentence “”Routers will retain this larger ANSN as "the most fresh information" and …”” 4.4 Indirect Jamming OK 5. Inconsistent Topologies OK 5.1 Identity Spoofing OK 5.2 Link Spoofing OK 5.2.1 Inconsistent Topology Maps due to Link State Advertisements 6. Mitigation of Security Vulnerabilities for OLSRv2 OK 6.1 Inherent OLSRv2 Resilience OK 6.2 Resilience by using RFC7183 with OLSRv2 OK 6.2.1 Topology Map Acquisition OK 6.2.2 Effective Topology OK 6.2.3 Inconsistent Topology
The SecDir reviewer makes a good point on the draft not covering delays and that replay mechanisms will defend against the attack described in different ways. The review is linked off the draft. Please ket me know if there is a reason to not add this threat or if you have text to propose to address it. Full review: https://www.ietf.org/mail-archive/web/secdir/current/msg07028.html Relevant section for convenience: "One issue that I did not see discussed in the draft would be for the attacker to effectively delay packets. For example, the attacker captures packets while jamming to prevent some stations from receiving packets. The attacker can collect a sequence of traffic and replay at a later time, with different timing and in a different location. Not all replay mechanisms will defend against this attack int he same way. Sequence number validation (which appears to be allowed in 7183) may not be as effective as timestamps, depending upon the time skew allowed. The document does discuss timestamps , but I think it should probably make the following clearer: There are several places in sections 4 and 5 where the document says something like "This kind of attack can be mitigated using integrity check mechanisms". I think in most of these instances replay protection is also important. One solution would be to remove these instances and just relay on section 6.2 which has a better description of the available protections. Since it seems that the integrity check could be deployed with just sequence number instead of timestamps it might be good to mention that it is important to include and verify timestamps for replay protection."
it's worth noting that inconsistent topology through Identity spoofing is actually a common enough misconfiguration in addtion to something that can be done deliberately. as for example when a configuration is copied repeatedly.
draft-adid-urn
If these IDs were included in media (as metadata) or emitted from user agents in clear, then they might assist a network attacker in re-identifying a person in which case it might be worth saying to not do that. If, OTOH, these identifiers are not intended to be incorporated into media objects, then saying that would be good.
Would it be worth mentioning in the Security Considerations section that the metadata associated with the Ad-ID should not contain any personal identifiable data?
-1, 2nd paragraph, "(over the air, on-line, over the top,
mobile, place based)":
Is that an exhaustive list, or just some examples? Also, I assume the term
"over-the-top" means online ads from a party other than the access network
provider. If that's the intent, the distinction doesn't seem useful for the
purposes of this document.
In Section 7.2 of the latest draft: [Ad-ID-INTRO] Ad-ID Identifiers are an eleven character UTF-8 string except for From the description on the website, it doesn't look like any of this characters is non-ASCII. If that is true, it would be better to change UTF-8 to ASCII. If UTF-8 is true, then you need to clarify whether you mean "Unicode character" or "octet", because they will have different length when encoded in UTF-8. High Definition (HD) or Three-Dimensional (3D) codes, which have an H or D in the 12th character.
The information with the Ad-ID-INTRO reference (in 7.2) seems out of place because it is not really a reference per se; maybe include the same text in the Introduction.
I would have thought "on-line" and "over the top" were the same thing -- might be worth clarifying.