[Gen-art] Gen-ART review of draft-ietf-ancp-mc-extensions-14
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ancp-mc-extensions-14.txt Reviewer:Christer Holmberg Review Date: 31 January 2014 IETF LC End Date:22 January 2014 IESG Telechat date: 6 February 2014 Summary:I have no issues with the document. It is well written, and is ready for publication. Major issues: - Minor issues: - Nits/editorial comments: - Regards, Christer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
Hi Vijay,
Apologies for the tardiness, comments inline.
On 24 Jan 2014, at 20:58, Vijay K. Gurbani v...@bell-labs.com wrote:
On 01/24/2014 10:44 AM, Varun Singh wrote:
Nits: - S6, In some situations, returning very detailed error
information (e.g., over-range measurement or measurement
unavailable) using this report block can provide an attacker with
insight into the security processing. I am not sure what you mean
by security processing here --- maybe you meant the byte discard
block leaks privacy of the user?
It is not necessarily privacy of the user, but a situation when the
receiver reports a packet as discarded and If the packet was
carefully crafted by an attacker, they infer something about the
security processing of the endpoint.
Varun: It was not immediately clear to me that your threat model when
you discuss this included the attacker mounting an active attack, but
regardless, the larger question of what you mean by security
processing remains --- who is doing the processing and how is the
security impacted?
If an attacker crafts a packet and sends it to the victim, who discards
it, then the attacker gets a XR Bytes Discarded report block, and at
best the attacker knows that the packet was discarded due to either
early arrival or late arrival (the 'E' bit). What is the security
processing insight that we are worried about here?
In this particular case, we are worried about a side channel attack.
The attacker sends a late arriving packet (timestamp in the past)
to the receiver and if the receiver sends a discard report with the
same number of bytes as the payload of the injected packet, the
attacker may infer that no security processing was performed.
If it observes no discard report, it may infer that security procedures
were performed on the packet.
Furthermore, if the attacker is capable of mounting an attack such that
it can inject arbitrary packets to the victim, then the attacker is
either in a session with the victim (a session the victim can stop
at any time), or the attacker has usurped the channel between the
victim and the original participant that the victim was conversing
with. In both cases, I suspect that the damage done is more than the
attacker just getting back discard report blocks.
Agree, this kind of attack can be mounted by any endpoint passively monitoring
the session
along the path and since RTP is sent over UDP, the attacker can mount the above
attack.
AFAIR the wording of the paragraph is adapted from other drafts
discussing discarded packets (RFC7097 and RFC7002) and with input
from sec-dir. That being said, if the wording can be made more clear,
I'm happy to incorporate the proposal.
I would have had the same questions of rfc7097 or rfc7002 if I had been
chosen to Gen-ART review them :-)
I think you need to motivate your threat model in S6 to determine the
mitigation strategies where SRTP/SAVPF will help. You can discuss this
I think one of the reasons not to explicitly write about the threat model is
because
there are several reason to use and not use SRTP/AVPF. they are covered in
ietf-avt-srtp-not-mandatory, and implementors should read that document
to make up their mind.
I hope the chairs can clarify on how to proceed.
with your chair or your friendly sec-dir personnel and if they
indicate that no threat model is needed, then please go ahead with the
draft. Gen-ART reviews are advisory in nature anyway. However, since
I was confused on reading the section and remain so after our brief
email exchange, I think some text added on the motivation may be helpful
to future readers (and implementers) of the extension.
Thank you again for the feedback.
Cheers,
Varun.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
On 01/31/2014 08:25 AM, Varun Singh wrote:
Hi Vijay,
Apologies for the tardiness, comments inline.
Varun: No worries. More inline.
In this particular case, we are worried about a side channel attack.
The attacker sends a late arriving packet (timestamp in the past) to
the receiver and if the receiver sends a discard report with the same
number of bytes as the payload of the injected packet, the attacker
may infer that no security processing was performed. If it observes
no discard report, it may infer that security procedures were
performed on the packet.
Ah, so you can trivially solve this problem by describing the attack in
the draft, much as you do above.
I think one of the reasons not to explicitly write about the threat
model is because there are several reason to use and not use
SRTP/AVPF. they are covered in ietf-avt-srtp-not-mandatory, and
implementors should read that document to make up their mind.
My reading of draft-ietf-avt-srtp-not-mandatory is that it does not
absolve RTP extension authors from talking about security, rather it
exhorts them to talk about the specific security problems exhibited
by their proposed extension and furthermore, elaborate how to address
such concerns.
I hope the chairs can clarify on how to proceed.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Assignments for the 2014-02-06 Telechat
And some late additions: Joel Halpern draft-ietf-tls-applayerprotoneg-04* Scott Brim draft-ietf-avtcore-clksrc-09** Jean On 1/30/14 7:46 PM, A. Jean Mahoney wrote: Hi all, The following reviewers have assignments: ReviewerLC end Draft Brian Carpenter 2013-12-23 draft-ietf-soc-overload-control-14** Christer Holmberg 2014-01-22 draft-ietf-ancp-mc-extensions-14 Dan Romascanu 2013-09-30 draft-ietf-p2psip-rpr-11* Dan Romascanu 2013-12-11 draft-ietf-stox-core-09* Dan Romascanu 2013-11-27 draft-ietf-clue-telepresence-requirements-07* Elwyn Davies2013-09-24 draft-ietf-insipid-session-id-reqts-09* Francis Dupont 2013-12-09 draft-ietf-rtgwg-cl-requirement-15* Francis Dupont 2013-09-30 draft-ietf-p2psip-drr-11* Joel Halpern2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-13* Joel Halpern2013-12-11 draft-ietf-stox-presence-07* Martin Thomson 2014-02-04 draft-ietf-alto-protocol-25** Robert Sparks 2014-01-31 draft-crocker-id-adoption-05** Scott Brim 2013-12-31 draft-farrell-perpass-attack-05* * Earlier draft reviewed ** Already reviewed I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ And the assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://wiki.tools.ietf.org/area/gen/trac/wiki/ Jean --- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 2014-01-31
Hi all, The following reviewers have assignments: Reviewer LC end Draft - Brian Carpenter 2014-02-07 draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 Christer Holmberg 2014-02-07 draft-ietf-roll-trickle-mcast-06 * Dan Romascanu 2014-02-11 draft-ietf-pwe3-iccp-13 Francis Dupont2014-02-12 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 Joel Halpern 2014-02-12 draft-ietf-mpls-forwarding-06 Meral Shirazipour 2014-02-14 draft-ietf-l2vpn-vpls-mib-14 * Second LC I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ And the assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html The standard template is included below. Thanks, Jean --- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-farrell-perpass-attack-05 Reviewer: Scott Brim Review Date: 2014-02-01 IETF LC End Date: 2013-12-31 IESG Telechat date: 2014-02-06 Summary: This draft is ready for publication as a BCP. Major issues: Minor issues: Nits/editorial comments: Two comments: First, there are good arguments for publication as Informational , but since it incrementally adds to BCP 72, it should be incorporated there, so BCP is slightly better. Second, the only significant difference from -04 was the removal of and be prepared to justify their decisions. There was a lot of discussion that led to this, and some concern that the statement on architectural considerations is not strongly enough worded without it. However, see the previous paragraph (both paragraphs are below). I believe that these two paragraphs, taken together, do what is desired. Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new pervasive monitoring considerations section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question is pervasive monitoring relevant to this work and if so how has it been considered? In particular, architectural decisions, including which existing technology is re-used, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making these architectural decisions. Getting adequate, early review of architectural decisions including whether appropriate mitigation of PM can be made is important. Revisiting these architectural decisions late in the process is very costly. Scott ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
On 1/31/2014 8:55 AM, Scott Brim wrote: First, there are good arguments for publication as Informational , but since it incrementally adds to BCP 72, it should be incorporated there, so BCP is slightly better. It does? It does not say it does. So that linkage is something the reviewer is creating. At the least, a claim that it does add to BCP 72 invites further debate about the nature and implications of the update. Again, making this a BCP confuses the nature of the document with those that give substantive operational guidance. This document does exactly what it should: It defines the topic and it says the IETF considers the topic important. It calls for practices, but doesn't -- and shouldn't -- define them. The job of providing substantive details about IETF practices associated with the topic will come later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
Thanks Scott. In the interest of being clear about my position, I support publication of 04 but do not support publication of 05. I think all the discussion that is useful has happened and all that remains is the consensus call from the sponsoring AD. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-art telechat review of draft-ietf-insipid-session-id-reqts-09
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-insipid-session-id-reqts-09 Reviewer: Elwyn Davies Review Date: 31 January 2014 IETF LC End Date: IESG Telechat date: 06 February 2014 Summary: Ready. Thanks to the authors for addressing LC comments. Major issues: None Minor issues: None Nits/editorial comments: One nit escaped: s3.1, para below Fig 1: s/and are by not exhaustive:/and are not exhaustive:/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-13
This revision address all of my comments and is ready for publication as a Proposed Standard. Yours, Joel On 1/30/14, 8:46 PM, A. Jean Mahoney wrote: Joel Halpern2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-13* ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review: draft-ietf-stox-presence-07
This document is still ready for publication as a Proposed Standard. Yours, Joel On 1/30/14, 8:46 PM, A. Jean Mahoney wrote: Joel Halpern2013-12-11 draft-ietf-stox-presence-07* ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review: draft-ietf-tls-applayerprotoneg-04
This document is still ready for publication as a Proposed Standard. Yours, Joel On 1/31/14, 11:34 AM, A. Jean Mahoney wrote: Joel Halpern draft-ietf-tls-applayerprotoneg-04* ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art review of draft-yourtchenko-cisco-ies-09
Kathleen, All, Apologies for jumping in here, but I wasn't privvy to the earlier discussion to which you allude. Summary: This draft extends RFC3954, but is specific to Cisco. No, this draft does not extend RFC 3954. RFC 3954 specifies the NFv9 Protocol and the associated Information Model. The model is extensible, and I own the netflow-police hat for reviewing, approving, and actioning NFv9 extensions. The IPFIX Protocol (RFC 7011) has its own Information Model (RFC 7012, IANA) which is also extensible upon application to IANA, subject to expert review by IE-doctors (RFC 7013). The yourtchenko-cisco-ies draft extends the IPFIX Information model. Per section 6 of the draft, IANA Considerations: This document specifies several new IPFIX Information Elements in the IPFIX Information Element registry The IPFIX Information Model was initially based upon the NFv9 Information Model. Indeed, the two are generally considered to be synonymous. The extensions which are being added to the IPFIX model seek to retain that synonymity by describing NFv9 elements which were not known or defined at the time RFC 3954 was written. These can be adopted into the IPFIX Information Model to retain compatibility, rather than defining equivalent IPFIX elements with different IDs from NFv9 and thus complicating life for every netflow collector. Note that this is not a change to either the NFv9 or IPFIX protocols. P. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art review of draft-yourtchenko-cisco-ies-09
Hi Paul, In that case, please update the abstract and introduction to make the intent of the document clear. It would be helpful for the reader to understand the intent as they start reading the document. The discussion referenced was posted to i...@ietf.orgmailto:i...@ietf.org. I think folks are addressing that discussion, so there is no need for me to jump into it. Here is a link that should pull up all the messages on this draft in the last month across all mailing lists: https://mailarchive.ietf.org/arch/search/?q=yourtchenkoqdr=m Best regards, Kathleen From: Paul Aitken [mailto:pait...@cisco.com] Sent: Friday, January 31, 2014 4:17 PM To: Moriarty, Kathleen; gen-art@ietf.org; i...@ietf.org; draft-yourtchenko-cisco-ies@tools.ietf.org Cc: ayour...@cisco.com; bcla...@cisco.com; draft-yourtchenko-cisco-...@tools.ietf.org Subject: Re: Gen-art review of draft-yourtchenko-cisco-ies-09 Kathleen, All, Apologies for jumping in here, but I wasn't privvy to the earlier discussion to which you allude. Summary: This draft extends RFC3954, but is specific to Cisco. No, this draft does not extend RFC 3954. RFC 3954 specifies the NFv9 Protocol and the associated Information Model. The model is extensible, and I own the netflow-police hat for reviewing, approving, and actioning NFv9 extensions. The IPFIX Protocol (RFC 7011) has its own Information Model (RFC 7012, IANA) which is also extensible upon application to IANA, subject to expert review by IE-doctors (RFC 7013). The yourtchenko-cisco-ies draft extends the IPFIX Information model. Per section 6 of the draft, IANA Considerations: This document specifies several new IPFIX Information Elements in the IPFIX Information Element registry The IPFIX Information Model was initially based upon the NFv9 Information Model. Indeed, the two are generally considered to be synonymous. The extensions which are being added to the IPFIX model seek to retain that synonymity by describing NFv9 elements which were not known or defined at the time RFC 3954 was written. These can be adopted into the IPFIX Information Model to retain compatibility, rather than defining equivalent IPFIX elements with different IDs from NFv9 and thus complicating life for every netflow collector. Note that this is not a change to either the NFv9 or IPFIX protocols. P. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-radext-ieee802ext-10 Reviewer: Ben Campbell Review Date: 2014-01-31 IETF LC End Date: 2014-02-04 Summary: This draft is almost ready for publication as a standards track RFC. I have a small number of minor comments that may be worth considering prior to publication. Major issues: None Minor issues: -- 2.1, last paragraph: Does the last sentence imply Allowed-Called-Station-Id actually should (or SHOULD) not be used in non-wireless scenarios? (I note that the Network-Id-Name section talks about how 802.1X NID-Names should not be included in Called-Station-Id, but rather put in Network-Id-Name. Does that apply here as well? -- 2.2, last paragraph: Since a NAS will typically only include a EAP-Key-Name Attribute in an Access-Request in situations where the Attribute is required to provision service, if an EAP-Key-Name Attribute is included in an Access-Request but is not present in the Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject. Is there a backwards compatibility issue? What if a NAS sends the field to a server that doesn't implement this draft? Is there an assumption that a NAS that supports this draft will only work with a server that also supports it? Or more to the point, is the ...typically only include...where required... strong enough to require a normative SHOULD? Seems like this would discourage the inclusion of EAP-Key-Name in the non-typical case of it _not_ being required. Is that the intent? Nits/editorial comments: -- section 2.8: It might be worth expanding EAPoL ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
On Friday, January 31, 2014, Sam Hartman wrote: Thanks Scott. In the interest of being clear about my position, I support publication of 04 but do not support publication of 05. I don't know why you object 05. I think all the discussion that is useful has happened and all that remains is the consensus call from the sponsoring AD. The AD should read all comments from the community of practical statements and AD to follow/sponsor reasonable statements/discussions or policies, not sponsoring best future plan as best current practice ( it may be initial plan for BCP). IMHO, the AD powers are not to be used against reasonable engineering discussions/requests only if that AD has done sound reasonable engineering replies. AB ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
