IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-05-20. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
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
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
Telechat:
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
Telechat:
3.3.2 Returning Items
3.3.3 For Action
Telechat:
Telechat:
Telechat:
1257 EDT break
1302 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
[Discussion of Retreat logistics]
1410 EDT Adjourned
(at 2010-05-20 08:30:15 PDT)
draft-ietf-sip-ipv6-abnf-fix
I found the use of RFC 2119 "MUST" in Sections 3.1 and 3.2 a bit odd. I think you could have used "are replaced" instead of "MUST be replaced" since your document *is* the implementation of the documentation. But it not important enough to worry about.
Should RFC3261 be corrected by Errata, as well?
The Gen-ART Review by Suresh Krishnan on 17-May-2010 raises a point
that deserves a response:
The draft also fixes the ABNF for IPv4 addresses i.e. the
<IPv4address> rule but is silent about why it is doing so.
I think I understand why it is being fixed but I would like
the authors to clarify.
Note to myself and Peter: The problem of matching of different textual forms of IPv6 addresses might affect other URI schemes.
This I-D says: Accordingly, this document updates RFC3261 as follows: the <IPv6address> and <IPv4address> production rules MUST be deleted from RFC3261 and MUST be replaced with the production rules of the same name in RFC3986 (and reproduced above.) These changes, when made to RFC3261, will make <hexpart>, <hexseq>, and <hex4> production rules obsolete. Thus this document also mandates that the <hexpart>, <hexseq>, and <hex4> production rules MUST be deleted from the ABNF of RFC3261. What does it mean that certain production rules MUST be deleted from RFC3261? Isn't that RFC immutable once published? I think it would be clearer to say that those production rules MUST be deleted from any specification that obsoletes RFC3261, and that this specification updates RFC3261 accordingly.
This is nitpicky, but I think you should point to [1] in the first sentence of the security consideration: This document does not introduce any security considerations in addition to those described in [1].
draft-ietf-csi-send-cert
This is an excellent document and I am planning to post a Yes vote
on it. However, there was one detail that I wanted to draw your
attention to:
The inclusion of the owner authorization value indicates that the
certificate has been issued for allowing the node to use the
address(es) or prefix(es) that are mentioned using the X.509
extensions for IP addresses and AS identifiers [RFC3779]
The definition of "owns" is imprecise. What exactly are you allowing
nodes to do, if they have this flag on in the certificate? I *think*
you mean that a host can assign the address and send/receive traffic
on it, and be able to respond to NSes about that address. This is
to enable the SEND certificate-based host security.
But what would prefix ownership mean, and how would it be different
from the router advertisement key usage flag?
1) section 7 TBAs raised by others. also the example in A uses TBA.
1) section 5 is missing a verb, I think - "an end user could local SEND deployment" 2) expand ULA on first use.
The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns
about changes from RFC 3971; if these changes are intentional it
would be very desirable to add a section on changes from RFC 3971.
1. In Section 4, second paragraph, this document says, "SEND
certificates MUST include the IP Resources extension for IPv6
Address." And, Section 6.3.1 of RFC 3971 says, "Router
Authorization Certificates are X.509v3 certificates, as defined
in RFC 3280, and SHOULD contain at least one instance of the
X.509 extension for IP addresses, as defined in RFC 3779."
Is the transition from "SHOULD" to "MUST" intended?
2. In Section 4, second paragraph, this document says, "Certified IPv6
address space SHOULD be expressed using either addressPrefix or
addressesOrRange elements." And, Section 6.3.1 in RFC 3971 says,
"The X.509 IP address extension MUST contain at least
one addressesOrRanges element" as well as "The X.509 IP address
extension MAY contain additional IPv6 subnet prefixes, expressed
as either an addressPrefix or an addressRange." I suspect these
should be the same.
In Section 7, there are several to-be-assigned values. They have
been assigned:
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
7. Extended Key Usage Values
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
Who owns this OID arc and who is going to assign the three values below:
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp TBA1 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp TBA2 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 }
?
5. Deployment Models In this scenario, the deployment of SEND MAY be done independently of the existence of deployment in the upper RPKI hierarchy (i.e. an end user could local SEND deployment without the need of RPKI deployment in Missing verb after "could". its ISP). This model MAY include ULA addresses. Please expand the ULA acronym on first use. It looks like the document needs an Informative reference to RFC 5781 (due to use of rsync URIs in the example).
Richard Barnes identified two issues that I consider particularly important, and
would like to
see addressed before publication. These issues are paraphrased
below:
Section 5 identifies two deployment models. The text implies (by omission)
that deployments
must choose between these models. In fact, a hybrid deployment
is both possible and likely.
In the hybrid deployment model most resources would
be certified under the global RPKI, while
some (e.g., ULAs) are certified under
local TAs.
In Section 7, the paragraph beginning "The inclusion of ..."
It would be helpful for the document to specify how prefix matching should be
done when validating these extensions. Which of the following should the RP use?
-- Exact matching,
-- Subset matching (RA within cert), or
-- The
subset/intersection algorithm defined in RFC 3971.
What prefix should the RP be matching against from SEND, per EKU? E.g., for id-
kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs
the router emits. It may be useful to refer to the ROA validation document
[draft-ietf-sidr-roa-validation].
(1) Please review the secdir review in its totality. I realize this came in
late, but I think there
are a number of comments that would improve the
document. The review is available at:
http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html
(2) In section 4, last sentence:
Certified IPv6 address space
SHOULD be expressed using either addressPrefix or addressesOrRange
elements.
I re-read the syntax in 3779, and I don't quite understand what is intended
here. I don't
think there is another choice in the end. Is the point that
either a prefix or a range is
acceptable?
(3) Section 4 refers to an earlier version of sidr-res-certs, and the section
numbering has
changed. Specifically, the sections 3.9.10 and 3.9.11 are now
4.9.10 and 4.9.11. (There may
be others.) If you are making other edits,
updating the version number and section
references might be a good idea.
I support the comments about the need to assign the TBS values in the conditions that the document has no IANA actions.
I sent these during IETF LC, and I believe the author is incorporating text to
address them. They have been renumbered and I added a new #4 and #5. I will
clear once a new version is posted or an RFC editor is included:
#1) I would like to see an ASN.1 module added to the document. That way we can
import the EKUs. Here's what I'm looking for (something similar was done in
draft-ietf-sip-eku):
-----
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-send-cert-extns(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arc
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
-- Extended Key Usage Values
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
END
-----
#2) You also need to register the OID for the ASN.1 module. I assume you're
going to try to get them out of the PKIX arc?
#3) In the last paragraph of Section 7 you describe what the certificate-using
application might require.
3.a) It says that including the EKU extension is a MAY, but the first paragraph
says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph
is correct the 1st MAY needs to be a MUST in the last paragraph.
3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then
shouldn't value also be required? That is, make the second MAY a MUST in the
last paragraph.
3.c) Was there discussion about support for the anyExtendedKeyUsage OID from
4.2.1.12 of RFC 5280?
3.d) You should look at draft-ietf-sip-eku for what they say about processing
their EKU. Those rules are helpful to implementers.
#4) Two additional security considerations are needed:
1) Why algorithm agility isn't needed
2) Why it's okay to use SHA-1
#5) draft-ietf-sidr-arch-09 is a normative reference. It is expired and bound
for informational. Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC
is necessary for this DOWNREF.
draft-ietf-csi-send-name-type-registry
We obviously need to add the SKI option to the name types.
However, the document claims to create a registry for the name types
in SEND. This is incorrect for two reasons:
1. It was already created in RFC 3971, Section 11:
"This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated by
using Standards Action [3]. The current values for this field are
1 DER Encoded X.501 Name
2 FQDN"
Even if IANA might possibly have missed the creation of the actual
registry, the right remedy is not to write another RFC, it would be
to correct the IANA registry.
2. The registry actually already exists:
http://www.iana.org/assignments/icmpv6-parameters
which says:
"Registry Name: Trust Anchor option (Type 15) Name Type field
Reference: [RFC3971]
Registration Procedures: Standards Action
Registry:
Value Description Reference
----- ------------------------------------ ---------
1 DER Encoded X.501 Name [RFC3971]
2 FQDN [RFC3971]"
As a result, the current draft should be updated to merely extend the
registry with new values, not to define the registry policy or create
the registry.
I would like the registry update to add reserved and experimental
values, though. It would also be useful if text from, say, RFC 5494
on the use of experimental code points would be included.
I would also like to change the registration policy from Standards
Action to Standards Action or IESG Approval. We have had multiple
cases where it was useful to be able to grant an exception through
IESG decision.
Abstract "This document request to IANA the creation and management of a registry for this field." is grammatically incorrect ====== In Section3 the table fragment Name Type 3 SHA-1 Subject Key Identifier (SKI) Should have the same table headings as the table in the IANA section ====== In the IANA considerations section "New assignments of Name Type field Is through Standards Action." is not grammatically correct, and "Name Type field" should surely be "SEND Name Type field ICMP TA option", though an SLA may be appropriate. In the table: "SHA-1 Subject Key Identifier (SKI) (Section 3)" should probably be SHA-1 Subject Key Identifier (SKI) (Section 3 of RFCxxx)
I support Jari's discuss about the registry already existing.
Section 4., paragraph 3: > | 253-254 | Experimental use | It would be good to add some guidance about how these experimental values are envisioned to be used.
The document should have an Informative reference to RFC 5226 from the IANA Considerations section.
I support jari's discuss position on registry existence.
I sent these during IETF LC. I believe the author is going to make changes, and
I will clear these DISCUSS positions once a new version or RFC editor note has
been submitted. I renumbered them because some other comments were addressed.
#1) Sec 2: Add the following to the final paragraph:
Consequently, this document updates section 6.4.3 and 6.4.5 of [RFC3971].
#2) Sec 3: I was kind of expecting to see something like the following (so it
looks a lot like RFC 3971 and you don't have to repeat what's in RFC 3971):
3. SEND SKI trust anchor option Name Type field
3.1 Updates to 6.4.3 of RFC 3971
Add the following under Name Type:
3 SHA-1 Subject Key Identifier (SKI)
Add the following under Name:
When the Name Type field is set to 3, the Name field contains a
160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit
string of the subject public key, as described in Section
4.2.1.2 of [RFC5280].
3.2 Updates to 6.4.5 of RFC 3971
Add the following to the penultimate paragraph as the penultimate
sentence:
If the TA option is represented as a SHA-1 SKI, then the SKI must
be equal to the SKI extension in the trust anchor's certificate
calculated as described in [draft-ietf-sidr-res-certs-17].
I sent these during IETF LC. #1) Abstract: r/This document request to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI)./This document requests that IANA create and maintain a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). #2) Sec 2: r/This document request to IANA the creation and management of a registry for this field./This document requests that IANA create and maintain a registry for this field. #3) Sec 3: You point to both RFC 5280 and sidr-res-certs for how to compute the SKI. Shouldn't you just be point to one (i.e., sid-res-certs)? That is r/Section 4.2.1.2 of [RFC5280]/[draft-ietf-sidr-res-certs-17] #4) Sec 3.1 (or wherever it ends up): r/then the SKI must be equal/then the SKI MUST be equal #5) To future proof this document it would be good if it just registered values for SHA-224, SHA-256, SHA-384, and SHA-512.
draft-ietf-marf-base
I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here? what happens if a Recived- Date and an Arrival-Date bith exist, and are different?
The introduction says: > > This memo seeks to define a standard extensible format by creating > the "message/feedback-report" [MIME] type for these reports. > Two points. First, this specification defines the message/feedback- report. Please drop "seeks to". Second, the new MIME type is one part in the overall email feedback report, but talking about this one piece before talking about multipart/report in the introduction lead me to a different expectation. That incorrect expectation is corrected in the subsequent paragraph. A top-down ordering here would have helped me. Section 3.1 says: > > o "Version" indicates the version of specification that the report > generator is using to generate the report. The version number in > this specification is set to "0.1". [NOTE TO RFC EDITOR: This > should be changed to "1" at time of publication.] > Note that "0.1" is not valid under the Version ABNF definition.
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 does not indicate that a marf processor should expect to see unknown fields.
Cleared.
I support Tim's DISCUSS positions.
draft-ietf-avt-rtp-gsm-hr
Section 5.2 How likely is it that a future specification will want to assign meaning to the other FT setting? If it is likely, you may want to consider a registry. --- Section 7.1 There are two instances of "RFC XXXX" in this section. I assume you want the RFC Editor to insert the number of this RFC when published, and that you want this reflected in the work done by IANA. A note to this effect in the document as -- RFC EDITOR AND IANA please blah, blah would be helpful. Or put it in the ballot write-up.
7.1. Media Type Definition The media subtype name contains "-08" to avoid potential conflict with any earlier drafts of GSM-HR RTP payload types that aren't bit compatible. This text really belongs to the following section, which you left empty: [...] Interoperability considerations:
one nitpick - 4855 specifically identifies payload formats that could be used to hide data as a security risk. I believe that this format provides very limited opportunities for data hiding, since the amount of data is fairly small and significant amounts of data would likely be audible (and not very effectively hidden!) Perhaps a sentence or two in security considerations would be good - it would demonstrate that all aspects of 4855's security considerations were considered.
Just some minor edits: Sec 3: r/network provides with mobile/network provides mobile Sec 3: r/is one of the speech codecs that are used in/is one of the speech codecs used in Sec 3: Should recommended and should in the last paragraph be capitalized?
draft-ietf-syslog-dtls
This is an excellent document and I was ready to post a Yes vote
on the ballot. However, there is one detail. The document says:
When mapping onto different
transports, DTLS has different record size limitations. The
application implementer SHOULD determine the maximum record size
allowed by DTLS protocol running over the transport in use. The
message size SHOULD NOT exceed the DTLS maximum record size
limitation of 2^14 bytes. To be consistent with RFC 5425, in
establishing a baseline for interoperability, this specification
requires that a transport receiver MUST be able to process messages
with a length up to and including 2048 octets. Transport receivers
SHOULD be able to process messages with lengths up to and including
8192 octets.
This guidance seems quite weak in terms of avoiding excessive
fragmentation. Or am I misunderstanding how DTLS records map to
UDP packets? I am assuming its a 1-1 mapping, but maybe I'm
mistaken.
In any case, the document should say something about tuning applications
and configurations to avoid excessively long packets due to
inefficiencies and other problems that fragmentation may cause.
Nit...in the following text from section 5.1: Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. use either 0 or 2 commas around "such as UDP or DCCP".
I support Jari's and Tim's DISCUSSes. Section 8., paragraph 1: > IANA is requested to assign a registered UDP and DCCP port number for > syslog over DTLS. The same value as for syslog over TLS (6514) is > requested. Do you also want the same service name (i.e., syslog-tls) for 6514/udp and 6514/dccp?
I am not a security expert so I would like to discuss with the Security ADs
whether this work shouldn't also discuss (automatic) key management in the
context of RFC 4107.
Please consider the proposed change in the Gen-ART Review by
Miguel Garcia on 17-May-2010:
In Section 5.3, the last sentence of the first paragraph reads:
"When the DTLS handshake has
finished, the transport sender MAY then send the first syslog
message."
I think what you really want to say is:
"The transport sender MUST NOT send any syslog message before the
DTLS handshake has successfully completed."
5.4.1. Message Size There is no upper limit for a message length per se. As stated in [RFC4347], each DTLS record MUST fit within a single DTLS datagram. When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. Why is this "SHOULD NOT" and not a "MUST NOT"? The quoted requirement from [RFC4347] doesn't seem to give any excuses.
There seems to be an essential disconnect between the conformance rquirements
and the
deployment guidance in this specification
The second paragraph of Section 6 Congestion Control states:
DCCP has congestion control. For this reason the syslog over DTLS
over DCCP option is recommended in preference to the syslog over the
DTLS over UDP option.
However, in Section 5.1, Transport
DTLS can run over multiple transports. Implementations of this
specification MUST support DTLS over UDP and SHOULD support DTLS over
DCCP [RFC5238].
For alignment with Section 6, it would seem that "MUST support DTLS over DCCP"
would
be more appropriate.
Given that disclosure is one of the primary threats described in Section 4, shouldn't the security considerations prohibit the use of cipher suites with NULL encryption?
draft-ietf-softwire-ipv6-6rd
COMMENTS: some RFC2119 keywords are not capitalized; I think it would be clearer if they were. (lots of "may" that might be better as "might") idnits in verbose mode reported a number of problems, but that might be the result of my saved version from the datatracker. Please check using the verbose options for idnits.
Please consider the minor issues raised in the Gen-ART Review by
Pete McCann on 17 May 2010.
Section 7:
The configured values for these four
6rd elements are identical for all CEs and BRs within a given 6rd
domain.
...
6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a
given 6rd domain.
Taken together, these statements seem to imply that there can only be
one BR for a given domain, or at least that all CEs must be configured
to have the same set of BRs. I note that in section 7.1.1 it is
possible to provision more than one BR address. Can this set be
different for different CEs? I can imagine a situation where
different CEs are homed on different BRs.
Section 9.2:
In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
MUST validate the source address of the encapsulated IPv6 packet with
the IPv4 source address it is encapsulated by according to the
configured parameters of the 6rd domain.
This seems to say that the CE should match the source IPv4 address of
the BR to the source address of the encapsulated IPv6 packet, when
receiving traffic from a BR. I assume that isn't what you meant.
7. 6rd Configuration
For a given 6rd domain, the BR and CE MUST be configured with the
following four 6rd elements. The configured values for these four
6rd elements are identical for all CEs and BRs within a given 6rd
domain.
IPv4MaskLen The number of high-order bits that are identical
across all CE IPv4 addresses within a given 6rd
domain. For example, if there are no identical
bits, IPv4MaskLen is 0 and the entire CE IPv4
address is used to create the 6rd delegated
prefix. If there are 8 identical bits (e.g., the
Private IPv4 address range 10.0.0.0/8 is being
used), IPv4MaskLen is equal to 8.
This might be obvious to other readers, but it wasn't obvious to me until
I saw the example at the end of Section 7.1.1: you should say that
the IPv4MaskLen high-order bits are stripped from the IPv4 address before
constructing the corresponding 6rd delegated prefix.
6rdPrefix The 6rd IPv6 prefix for the given 6rd domain.
6rdPrefixLen The length of the 6rd IPv6 prefix for the given
6rd domain.
Does this include the IPv4 part? I don't think it does, but you should clarify.
I support issues 11) and 12) in Dave's discuss. With regard to 11), is there any scenario where the BR IPv4 address needs to be reachable from outside the SP's 6rd domain?
The following comment made by Joel Jaeggli in his OPS-DIR review should be addresed: Once a mapping between ip4 addresses and /64 or shorter prefixes is established within a service provider, it's not going away for a long time. If used with frequency by ISPs (and customers of ISPS that use them as lirs) this will soak up sufficient ipv6 address space to move the requirements for direct assignments and ISP/LIR operations around considerably. This proposal if widely deployed therefore has impact on current prefix assignment policies for ipv6 in the RIRs.
draft-reschke-webdav-post
Hi, a few comments: 1) I really dislike the style, with "Note:" and "Note that" strewn throughout. Just write it.
This is pretty nitty, but I'd like to see the reference after HTTP/WebDAV and XML in the security considerations: OLD: Security considerations applicable to HTTP/WebDAV and XML apply for this specification as well, namely, [RFC4918] (Section 20) and [RFC3470] (Section 7). NEW: Security considerations applicable to HTTP/WebDAV [RFC3744] and XML [XML] apply for this specification as well, namely, [RFC4918] (Section 20) and [RFC3470] (Section 7).
draft-housley-cms-content-constraints-extn
1. Introduction The CMS SignedData [RFC5652] construct is used to sign many things, including cryptographic module firmware packages [RFC4108] and certificate management messages [RFC5272]. Similarly, the CMS AuthenticatedData and CMS AuthEnvelopedData constructs provide authentication, which can be affiliated with an originator's static public key. CCC information is conveyed via an extension in a This is the first use of the CCC acronym, so it should be expanded here (not not 2 pagraphs below). certificate or trust anchor object that contains the originator's or signer's public key. Is the extra complexity of having absenceEqualsUnconstrained worth it?
[Updated to remove #1, but added a new #2]
2) Can you provide an alternate grouping in section 4 so the things that are
done multiple times are set apart from the thing that is done once per CMS path.
I believe this will make things clearer.
[Updated: Removed original 12. Two new comments.] Here are my comments on this draft: 13) In this I-D the reference for ASN.1 in '97, but in PKIX/SMIME New ASN.1 it's '02. 14) Sec 3.1: r/if the certification path is valid for a signed CMS object/if the certification path is valid for a given context.
draft-turner-encryptedkeypackagecontenttype-algs
Section 2 needs to specify a content-encryption algorithm. Based on
the other choices in this document, the mandatory-to-implement
content-encryption algorithm ought to be AES-CBC with a 128 bit key.
Section 3 specifiesd a key-encryption algorithm, when a content-
encryption algorithm is required. Based on the other choices in this
document, the mandatory-to-implement content-encryption algorithm
ought to be AES-CBC with a 128 bit key.
draft-turner-encryptedkeypackagecontenttype
draft-ietf-netlmm-mip-interactions
I have some clarifications I'd like to see in the Security Considerations
section.
I don't know exactly what this text means:
Scenarios A.1 and B described in Section 3 do not introduce any
security considerations in addition to those described in [pmipv6-
draft] or [RFC3775].
Does it mean do not identify any security issues?
Des scenario A2 identify any security issues?
Do the solutions in section 4 introduce any security considerations?
Nit, in section 3.1: s/regardless/regardless of/
Nit, in section 3.2, list item 3: s/access when/access where/
Also, can you reword "delay in the mobility signaling sent
may imply adverse situations"; maybe "delay in the receipt
mobility signaling may result in undesirable situations"?
Still in section 2, in the last bullet of list item 4, I don't understand
"the threat described in [RFC4832] is worse"; worse than what?
Please consider the comments from the Gen-ART Review by Enrico
Marocco on 12 May 2010. The review can be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-ietf-netlmm-mip-interactions-06-marocco.txt
(1) The security considerations seem incomplete:
(A) there was considerably more detail in the security considerations for one of
the five
IDs combined into this draft. See:
http://tools.ietf.org/html/draft-giaretta-netlmm-mip-interactions-00#page-21
These issues seem to be relevant. Perhaps this text should be incorporated?
(B) The text states that there were no new security considerations for Scenarios
A.1 or B.
Does the subsequent text pertain to A.2? It would be good to clarify
this.
(2) The security considerations refer to [pmipv6-draft] but this does not appear
in the
references section. It looks like that should be RFC 5213.
(1) Section 3.2, list item 4 bullet 3
s/binging/binding/
(2) The final sentence in Section 5 (Security Considerations) is considerably
weaker than the
text in Section 3.2, list item 4 bullet 4.
From section 3.2:
Based on this
consideration, the threat described in [RFC4832] is worse as
it affects also hosts that are using the LMA/HA as MIPv6 HA
and are not using PMIPv6.
From section 5:
Note that the compromised MAG threat described in [RFC4832]
applies also here.
I suggest that the text in the security considerations be strengthened...
I support Tim's DISCUSS positions.
Some nits:
Section 3, second sentence:
OLD
This document does not
^^^^
only focus on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but it investigates
^^
also more complex scenarios where the protocols are more tightly
^^^^
NEW
This document not
only focuses on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but also investigates
more complex scenarios where the protocols are more tightly
Section 3, page 9, line 4:
OLD
depicted in the figure. However, the LMA and HA can be also
^^^^^^^
NEW
depicted in the figure. However, the LMA and HA can also be
draft-ietf-radext-tcp-transport
This Discuss is related to Tim's Discuss. This text:
"Bare" TCP transport MAY, however, be used when another method such
as
IPSec [RFC4301] is used to provide additional confidentiality and
security.
Should experience show that such deployments are useful,
this specification
could be moved to standards track.
is confusing. Why would experience with
"bare" TCP or IPSec TCP cause draft-ietf-radext-tcp-transport to progress to
Standards Track?
Similarly, from the Abstract:
It [draft-ietf-radext-tcp-transport-06.txt] is not intended
to define TCP as a transport protocol for RADIUS in the absence of
TLS.
while several of the motivations for RADIUS over TCP in section 1.1 are not
specific to RADIUS with TLS.
Agree with Tim's DISCUSS. Section 27, paragraph 13: > It is not intended > to define TCP as a transport protocol for RADIUS in the absence of > TLS. The document title is "RADIUS Over TCP". It's surprising to then see that abstract say that it is not intended to define RADIUS over TCP... Suggestion: Rename document to "Radius over TLS"? Section 1., paragraph 1: > While > there are a number of benefits to using UDP as outlined in [RFC2865] > Section 2.4, there are also some limitations: Lack of congestion control is surely a limitation? Section 1.1., paragraph 2: > In scenarios where RADIUS proxies exchange a large volume of packets > (10+ packets per second), it is likely that there will be sufficient > traffic to enable the congestion window to be widened beyond the > minimum value on a long-term basis, enabling ACK piggy-backing. I don't understand what this paragraph means to say. The TCP congestion window opens already at much lower rates than 10+ pps. Also, how is this at all related to ACK-piggybacking? Section 1.1., paragraph 5: > These problems disappear if a 4096 application-layer payload can be > used alongside RADIUS over TLS. Since most TCP implementations > support MTU discovery, the TCP MSS is automatically adjusted to > account for the MTU, and the larger congestion window supported by > TCP may allow multiple TCP segments to be sent within a single > window. Even those few TCP stacks that don't do PMTUD can already support arbitrary payloads (just with slightly less efficient packetization). Section 2.6.1., paragraph 5: > As noted previously, RADIUS packets SHOULD NOT be re-transmitted to > the same destination IP and numerical port, but over a different > transport layer. Where does it say that? The second paragraph of Section 2.6 says that they MAY be retransmitted over a new connection (which is different from a SHOULD NOT). Also, "transport layer" here is unclear - do you mean "transport connection" (= use a different TCP connection) or do you mean "transport protocol" (= use UDP)? Section 2.6.2., paragraph 2: > Unlike UDP, TLS is subject to issues related to Head of Line (HoL) > blocking. This occurs when when a TLS segment is lost and a > subsequent TLS segment arrives out of order. While the RADIUS server > can process RADIUS packets out of order, the semantics of TLS makes > this impossible. This limitation can lower the maximum packet > processing rate of RADIUS over TLS. s/TLS/TCP/ in this paragraph Section 2.6.4., paragraph 6: > After applying the above rules, there are still situations where the > previous specifications allow a packet to be "silently discarded". > In these situations, the TCP connections MAY remain open, or MAY be > closed, as an implementation choice. However, the invalid packet > MUST be silently discarded. In order to reduce connection-setup overheads, wouldn't it make sense to RECOMMEND the connection stay open?
Please consider the comments from the Gen-ART Review by Glenn
Kowack on 18 May 2010. The review can be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-ietf-radext-tcp-transport-06-kowack.txt
This is a good document, but there are a few issues that should be addressed
before publication.
(1) The document is inconsistent regarding the applicability of this protocol.
From the Abstract, where "It" refers to this document:
It is not intended
to define TCP as a transport protocol for RADIUS
in the absence of
TLS.
but the last paragraph in the Introduction states:
"Bare" TCP transport MAY, however, be used when another method such
as IPSec [RFC4301] is used to provide additional confidentiality and
security. Should experience show that such deployments are useful,
this specification could be moved to standards track.
(2) In a related point, the next to last paragraph in the Introduction states:
Since "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required. As a
result the use of "bare" TCP transport (i.e., without additional
confidentiality and security) is NOT RECOMMENDED, as there has been
little or no operational experience with it.
Why isn't this a "MUST NOT be used without TLS, IPsec, or other secure
upper layer"?
(3) The security considerations should include a statement along the same lines
as discussed in (2) - e.g., MUST NOT be used unless TLS or IPsec is used in
conjunction.
draft-ietf-avt-rtcp-guidelines
I have just one small comment on this well written document. Even though the Guidelines section immediately follows the Issues section, I think it would be good to state explicitly "Don't do anything mentioned as an Issue in the previous section" as a Guideline. For example, "Commands are issued, rather than hints given" is an Issue, while I don't think any of the Guidelines warn against creating an extension that requires a command-action architecture.
Congratulations on the reference to RFC 1925.
This is a discuss-discuss; I am not asking for any changes in the document.
I would know whether the wg considered BCP rather than Informational? If there
is sufficient support in the community, I would think the guidelines provided
here
should have that status...
draft-ietf-mpls-tp-framework
(with editorial updates)
Before approving this document I would like to make a few clarifications
concerning the following in Section 3.14 Network Management:
> The Network Management System (NMS) is used to
provision and manage an end-to-end connection across a network where
some segments are created/managed by, for example, Netconf [RFC4741]
or SNMP [RFC3411] and other segments by XML or CORBA interfaces.
Maintenance operations are run on a connection (LSP or PW) in a
manner that is independent of the provisioning mechanism. An MPLS-TP
NE is not required to offer more than one standard management
interface.
1. From section 1.1 we get that using an NMS for provisioning is just one
option, another being the usage af an CLI. Consequently I think that this
section should say 'The Network Management System (NMS) can be used' rahter than
'The Network Management System (NMS) is used '
2. Mentioning XML here is quite
inconsistent - it's a language to represent information and not a protocol or
framework for management as SNMP, Netconf, or CORBA. Netconf is already working
with XML actually. I suggest to drop mentioning XML here.
3. I suggest to re-
write the last sentence as a positive statement:
s/An MPLS-TP NE is not
required to offer more than one standard management interface./An MPLS-TP NE is
required to offer at least one standard management interface for interoperable
management./
I'm just asking for a reference: The 1st sentence in the security considerations is: The introduction of MPLS-TP into transport networks means that the security considerations applicable to both MPLS and PWE3 apply to those transport networks. Can we add references for MPLS and PWE3? Maybe RFC 3031 for MPLS and RFC 3985 for PWE3? So it reads: The introduction of MPLS-TP into transport networks means that the security considerations applicable to both MPLS [RFC3985] and PWE3 [RFC3301] apply to those transport networks.
draft-ietf-6lowpan-routing-requirements
I agree with Adrian's DISCUSS.
I am particularly concerned with
"Here, 'Routing' is not equivalent to IP routing, but includes the
functionalities of path computation and forwarding under the IP layer."
In the IETF "Routing" has a well known meaning, and if this document proposes
something else, it needs a new term.
I have a few questions: Section 4., paragraph 15: > * Classes of Service: > For mixing applications of different criticality on one > LoWPAN, support of multiple classes of service may be required > in resource-constrained LoWPANs and may require a certain > degree of routing protocol overhead. I'm not sure I see why. QoS support typically involves end-to-end transport functions and more complex *queueing*, but not routing *protocol* overheads. Could you explain? Section 4., paragraph 17: > b. Node Parameters: Isn't queuing strategy and queue buffer size also a parameter? Section 4., paragraph 21: > * Traffic Pattern: > This parameter affects routing since highly loaded nodes > (either because they are the source of packets to be > transmitted or due to forwarding) may contribute to higher > delivery delays and may consume more energy than lightly > loaded nodes. This applies to both data packets and routing > control messages. Again, I'm not sure I understand. Why does the volume of application data sent or received by some nodes affect the routing *protocol*?
I have some significant concerns about this document. These cover
both process and techncial content.
---
These requirements have arrived very late in the cycle. The ROLL
working group has written four requirements documents (3 RFCs and
one on the RFC Editor Queue), and the RPL specification is nearing
completion. In fact, some of the rquirements in this document
actually reference the requirements published by the ROLL WG.
It is unclear how these requirements should be applied and whether
they are a subset of the rquirements already captured by the ROLL
working group or different in some way.
If the requirements have all been captured already, I suggest that
this document should become Historic. If the reuirements are "new"
to the work done by ROLL, then please see the next point.
---
The proto write-up says...
On a [One?] single person, JP Vasseur, has indicated discontent
with the document. He seems to feel the document is unnecessary
because, in his opinion, it overlaps with the ROLL WG work. This
document, though, is specific to 6lowpan and references the
documents of ROLL. ROLLs work is not specific to 6lowpan
networks.
I note that the person expressing the concern is one of the co-chairs
of the ROLL working group.
The Abstract says...
The purpose of this
document is not to recommend specific solutions, but to provide
general, layer-agnostic guidelines about the design of 6LoWPAN
routing, which can lead to further analysis and protocol design.
This document is intended as input to groups working on routing
protocols relevant to 6LoWPAN, such as the IETF ROLL WG.
It is clear, therefore that, in the opinion of the 6lowpan working
gorup, this document does overlap with the work of the ROLL working
group.
The proto write-up does not show any signs of the document having
been
discussed with the ROLL working group or within the Routing
Area more widely. I
don't see any mention of the document on the
ROLL
working group mailing list.
I find this expression that the ROLL working group is an intended
consumer of this document very strange when combined with the
disregard of the that working group's view of the document.
Furthermore, the 6lowpan charter says...
6lowpan will work closely with the Routing Over Low power and
Lossy networks (roll) working group which is developing IPv6
routing solutions for low power and lossy networks (LLNs).
I do not see any demonstration of close working.
What actions have been taken to ensure that the content of this
document are understood by the ROLL working group and that the
details are relevant to the people developing routing protocol
solutions?
---
Section 1 (and again, Section 4) refers to a requirement for
"data-aware routing" without giving any description of this term.
The term is sometimes used to refer to the concept of routing packets
according to the data content of those packets. This is not consistent
with IP routing paradigms and would need to be brought out for full
discussion.
Potentially you mean something else by this term in which case you
really do need to define the term.
---
Section 3.2
It is not appropriate for an Informational requirements document to
take a position on which solutions my be adequate or to give PDU
specifications.
---
The document would have benefitted significantly from review in the
Routing Area. The Routing ADs asked Dimitri Papadimitriou to review
the document on behalf of the Routing Area Directorate. His comments
will be sent to the document authors under separate cover. Many of
his comments are very significant, and all would seriously improve
the document.
Please address the comments and update the document accordingly.
---
Requirement 8 says
[R08] 6LoWPAN routing protocols SHOULD be reliable despite
unresponsive
nodes due to periodic hibernation.
This needs to be clarified. What is "protocol reliability". Do you mean
that the protocol should exchange packets reliably, that the protocol
should be able to reliably find a path, or that the path found should
be reliabel?
---
Requirement 11 says
[R11] The procedure of route repair and related control messages
should not harm overall energy consumption from the routing
protocols.
Why don't you use "SHOULD NOT"?
---
The Mesh Under description appears to suggest that there is a
requirement to build a routing system for MAC addresses (i.e. not for
IP addresses). If this is a requirement it has been far too deeply
hidden in this document. It needs to be brought out and examined more
because with one notable exception, the IETF does not normally work
with routing for non-IP addresses.
---
Requirement 17
[R17] In case there are one or more nodes allocated for the specific
role of local management, such a management node MAY take the role of
keeping track of nodes within the area of the LoWPAN it takes
responsibility for.
Is this a requirement on the routing protocol? It doesn't appear to be.
---
Requirement 18
[R18] If the routing protocol functionality includes enabling IP
multicast, then it may want to employ structure in the network for
efficient distribution [I-D.ietf-manet-smf], such as Connected
Dominating Sets (CDS), Multi-Point Relays (MPR), or relay points
sending point-to-multipoint messages in unicast messages instead of
using link-layer multicast (broadcast).
Do you mean "MAY".
"may want to" seems like a very flimsy "requirement." Actually, the
paragraph looks like a solution in search of a requirement. Can you
turn this into a potential requirement, and leave the solution for
the solution documents?
---
Section 6 needs to make more clarity by separating the requirements
for security of the routing protocol, and the requirements of security
for end-to-end data that can be assisted by the routing protocol.
(1) This document seems to assume that a LoWPAN will be either Route Over or
Mesh Under in its
entirety. This is not an obvious result. I would expect that
a Mesh Under could live transparently
within a Route Over LoWPAN. (Essentially,
the ER in the Mesh Under LoWPAN from Figure 3
would be LoWPAN router in the
Figure 2 Route Over network.) If this scenario is realistic, the document
should address any routing requirements that would be introduced (or note that
no new requirements are established by the hybrid scenario. [Note: it is not as
clear to me whether a Route Over in a Mesh Under makes sense.]
(2) The term "node" seems to be used inconsistently within this document, and
with respect to IEEE
802.15.4 and 6lowpan-nd. For example, in figure 2 all
components of a Route Over network are
labeled as edge routers, LoWPAN routers,
or LoWPAN hosts. Figure 3 labels several components
in a mesh under network as
"mesh nodes", and the remaining components are Edge routers or
LoWPAN hosts.
The text that follows (last paragraph in 3.1) opens with a discussion of
communication between nodes in different LoWPANs -shouldn't this include
communication
between LoWPAN hosts? The next sentence talks about nodes
performing IP routing in the
Route Over case, but Figure 2 doesn't have "nodes".
Note: I considered making this a comment, since it is editorial, but being
consistent with these
terms is essential to understanding the document!
(3) The text in Figure 1 and section 3.2 is inconsistent. (Figure 1 "shows the
place of 6LoWPAN
routing in the entire network stack.")
From 3.2:
In the simplest case for a Mesh Under where layer two forwarding can
be performed without piggy-backing routing protocol information, the
mesh-header defined in RFC 4944 [RFC4944] is sufficient, see
Figure 5.
This implies that the 6LoWPAN routing could occur in the IEEE 802.15.4 MAC
layer. I realize
that ascii art has its limitations, but if that is correct a
note in the accompanying text in section 3
would be helpful.
Is there an example of a power affluent node that is *not* mains-powered? And does this have any impact on the routing requirements?
1. I support the part of Adrian's DISCUSS concerning the need to coordinate and
have this document reviewed by the ROLL WG. I note that the WG charter
explicitly mentions working closely with ROLL.
2. I cannot see in the document any requirement related to the management of the
nodes implementing 6lowpan routing. The charter talks about 'define the
necessary security and management protocols and constructs for building 6LoWPAN
networks- - is this covered in another document, or should it be covered here?
#1) This is a DISCUSS-DISCUSS. To be clear there's nothing for the authors to
do at this time.
The charter indicates that the WG will develop:
6. Produce "6LoWPAN Security Analysis" to define the threat model
of 6LoWPANs, to document suitability of existing key management
schemes and to discuss
bootstrapping/installation/commissioning/setup issues. This
document will be referenced from the "security considerations"
of the other 6LoWPAN documents. This document will be
informational.
Shouldn't this document point to that document? Is that document no longer
going to be published?
#2) The Security Considerations point to RFC 4944 and that includes the [KW03]
reference for attacks and counter measures for sensor networks. Do these line
up with the threats defined in RFC 4593? Did the WG consider RFC 4593? I don't
have a copy of the [KW03] reference so it's hard for me to tell.
#3) Sec 5.4: What do you mean by secure delivery/transmission? Does secure
delivery/transmission encompass origin authentication, integrity, and
confidentiality or some subset? RFC 4919 only refers to confidentiality and
integrity. I think you should be explicit about what "secure delivery" means.
#4) Sec 5.4: Why isn't a MUST support secure delivery? To me, SHOULD means the
protocol might not support the option of secure delivery/transport. That is a
bad thing in my book. If you make it MUST support then it's built-in when you
need it.
#5) Sec 5.4: With regards to the 802.15.4 AES MAC based on AES. The intro has:
Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.
but later it says:
Routing protocols need to define how this mechanism can be used to
obtain the intended security, either for the routing protocol
alone or in conjunction with the security used for the data.
The "may" and "need to" don't seem to line up.
Further, according to RFC 4919:
IEEE 802.15.4 mandates link-layer security based on AES
so why isn't this need to define /taking in to account a MUST?
In a nutshell it's not clear to me how the routing data is going to be secured.
MUST it be the IEEE mechanism, can it be something else that is WG defined, or
can it be something already defined elsewhere in the IETF?
In [R14], I think you should delete the 2nd sentence from the requirements
statement.
#6) Sec 5.4: In the security threats paragraph, it says:
Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
threats as listed in RFC3756 [RFC3756].
Are they or aren't they? If they are, then which ones apply?
#7) Sec 5.4: In the security threats paragraph, it says:
Bootstrapping may also impose additional threats.
What are these threats? How are they mitigated?
#8) The following is in Section 5.4:
While there are applications which require very high security,
such as in traffic control, other applications are less easily
harmed by wrong node behavior, such as a home entertainment system.
I'd disagree with this statement. Say an emergency broadcast system is in
effect and it's supposed to telling me via my TV to duck and cover and it's not.
My point is I'm not sure you need this sentence.
#9) Sec 6: I think the first sentence is a little off. Neither 4919 or 4944
have a section 4.4 that talks about security considerations. Did you mean:
OLD:
Security issues are described in Section 4.4 of the security considerations of
RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.
NEW:
Security issues are described in Section 5.4. The security considerations in
RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.
draft-sharikov-idn-reg
This is DISCUSS DISCUSS and I intend to clear during the call. To the best of my
knowledge, Kildin Sami (formerly know as Lappish) is spoken by only 600 people
on the Kola Peninsula of Northern Russia.
Who standardizes the alphabet for this language? How do we know that we go the
section on Kildin Sami right?
Nit in the Introduction: Those difficulties are especially pronounced with "all of Cyrillic" is used rather than only the characters associated with a particular language. s/with/when/ ?
Please note the following nit: The document seems to lack a Security Considerations section.
Please double-check the tables in Appendix A. For example: - U+03B0 is GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS (not GREEK SMALL LETTER ALPHA = U+03B1) -- there are two instances of this error - U+039B is GREEK CAPITAL LETTER LAMDA (not GREEK SMALL LETTER LAMDA = U+03BB)
draft-meadors-ediint-features-header
A very small point that can be fixed with an RC Editor note, I hope.
Section 2 provides some small and rather trivial BNF syntax descriptions.
Nevertheless, we need a reference to the BNF spec that is applicable.
draft-resman-idna2008-mappings
draft-mohali-diversion-history-info
draft-irtf-p2prg-alto-survey