IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-11-29. 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:
6rd CE BNG AAA Server
| | |
|-------DHCPDISCOVER------>| |
| |--Access-Request(6rd Attr)-->|
| | |
| |<--Access-Accept(6rd Attr)---|
|<-------DHCPOFFER---------| |
| | |
|--------DHCPREQUEST------>| |
| (6rd Option) | |
|<--------DHCPACK----------| |
| (6rd option) | |
| | |
DHCP RADIUS
Figure 1: the cooperation between DHCP and RADIUS
This diagram neither indicates that the RADIUS Access-Request/Accept sequence is authenticated, nor does it show any previous previous authenticated RADIUS interaction. It therefore appears to violate the RFC 5080 requirement.
Telechat:
Telechat:
MN MAG(NAT) LMA |------>| | 1. Mobile Node Attach | |------->| 2. Proxy Binding Update (IPv4TS) | |<-------| 3. Proxy Binding Acknowledgement (IPv4TS) | |========| 4. Tunnel/Route Setup | + | 5. Installing the traffic offload rules |------>| | 6. IPv4 packet from mobile node | + | 7. Forwarding rule - Tunnel home/offload | | |When reading this figure 2, it's not clear yet that the IPv4 Traffic Offload Selector option are in the Proxy Binding Acknowledgement message. So this is even confusing...
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1205 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
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1228 EST Adjourned
(at 2012-11-29 07:30:03 PST)
draft-ietf-nfsv4-federated-fs-admin
I think that it would be useful to encourage implementers to install the trust anchors so that they are scoped to a specific NSDB. This would be much better than using global trust anchors.
I hope this is an easy one. You say that the root cert in a FEDFS_SEC_TLS MUST be used to validate the NSDB's server certificate, and that's fine. The problem is that some implementation might well have an OS-wide root cert store and install this value in that, with potential bad effects. Would it be ok to add a statement that the cert from a FEDFS_SEC_TLS MUST NOT be used for other purposes if its not already known? That is, we do not want implementations to take this cert and put it into that kind of OS-wide store where it could be used for other things, in particular if its actually just an SSC. Discussion with the authors ended up with this text: " To ensure that this security configuration information does not cause vulnerabilities for other services, trust anchors provided through secData MUST only be used for the NSDB service (as opposed to being installed as system-wide trust anchors for other services). Most popular TLS libraries provide ways in which this can be done, for example, see [1]. " Though [2] might be a better reference for the RFC editor. [1] http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html [2] http://www.rtfm.com/openssl-examples/part1.pdf If some equivalent wording is added that'll clear this discuss.
I'm sorry to sound like the "RFC 2119 language police" with these
comments. In my opinion, my comments refer to text whose meaning
(and, therefore interoperability of implementations) depends on the
interpretation of the RFC 2219 language.
In section 4:
FedFsUuid: A universally unique identifier (UUID) as described in
[RFC4122] as a version 4 UUID. The UUID should be formatted in
network byte order.
s/should/MUST/ ?
FedFsNsdbName: A (hostname, port) pair.
[...]
A value of 0 indicates that the standard LDAP port number, 389,
SHOULD be assumed.
s/SHOULD/MUST/, or explain when 389 is not assumed and what is used
instead of 389. Why would one set the port to 0 instead of just using
the more direct 389, anyway? The answer to this question should be
applied in section 4.1.
[...]Therefore, a FedFsNsdbName SHOULD NOT contain a network address,
such as an IPv4 or IPv6 address, as this would indefinitely assign
the network address.
s/SHOULD NOT/MUST NOT/, or explain the syntax for encoding a network
address in a FedFsNsdbName.
FedFsPathComponent: A case sensitive UTF-8 string containing a
filesystem path component. It SHOULD be prepared using the
component4 rules defined in Chapter 12 "Internationalization" of
[3530bis].
When would it not "be prepared using the component4 rules[...]" and
how would that case be identified?
In section 5, some error conditions are specified as "MUST be
returned", some as "SHOULD be returned", some as "MUST fail with
status [...]" and some are not specified with any RFC 2119 language.
At the risk of suggesting foolish consistency, I suggest a editing
pass for consistency, with explanations of what to do if a SHOULD is
not followed, would likely ease the mind of an implementor. (OK, I
admit this comment is mostly stylistic, except for the clarification
of SHOULDs.)
1.1
Client: Any client that accesses fileserver data using a supported
file-access protocol.
I love circular definitions as much as the next guy, but how about at least
indicating whether the client is the software, the machine, the user, or some
other theoretical entity? The above is not useful.
Fileserver: A server exporting one or more filesystems via a file-
access protocol.
Hmmmm....That's not a terribly helpful definition.
4. Data Types
The basic data types defined above MUST be formatted as follows:
The MUST is strange. I always say that you should use MUST if an implementation
might accidentally choose to do otherwise and cause an interoperability
problem. In this case, choosing to do otherwise is not an accident; it's just
insanity. It's probably just as good to say "The basic data types defined above
are formatted as follows:". That said:
FedFsUuid: A universally unique identifier (UUID) as described in
[RFC4122] as a version 4 UUID. The UUID should be formatted in
network byte order.
There's something weird about the first sentence. The contradiction of the
"MUST" above and the "should" here is glaring. Don't you want to say here that
the UUID MUST be in network byte order? *That* would cause an interoperability
issue, wouldn't it?
A system (i.e.,
fileserver or administrative host) SHOULD resolve the fully
qualified domain name to a network address using the system's
standard resolution mechanisms.
SHOULD do something that is implementation dependent? That doesn't look right.
The secType field indicates the security mechanism that MUST be
used to protect all connections to the NSDB with the connection
parameters.
A value of FEDFS_SEC_NONE indicates that no security mechanism is
necessary. In this case, the secData array will have 0 length.
There appears to be a conflict in the above. I read the first sentence as
saying that whatever is in secType MUST be used; you can not use an
alternative. However, the second sentence indicates that no security mechanism
is "necessary", implying that you *could* use a security mechanism if you
wanted to. Which is it? Do I have to respect what's in secType, or are there
instances where I can choose what I like?
I have a few non-blocking comments, most of which have to do with combinations of 2119 key words. In all of those cases, I'm not *sure* what you want to say. If you really do want to say what's there, then my comments are wrong. But if, as I suspect, this is *not* really what you're trying to say, then we should sort out the right text. Please chat with me about them if that will help. -- Section 5.2.2 -- If the path contains an invalid UTF-8 character, then status FEDFS_ERR_BADCHAR MUST be returned. What characters are valid? When I look at the definition of FEDFS_ERR_BADCHAR, I think you mean "unsupported", rather than "invalid"... yes? [I'm picking on this because the IDNA specs actually *do* define valid and invalid characters, and you probably don't want to try to mess with that. :-) ] This also appears in Sections 5.3.2, 5.4.2, 5.5.2, 5.6.2, and 5.7.2. -- Section 5.5.2 -- The server SHOULD permit this operation even on read-only filesets, but MAY return FEDFS_ERR_ROFS if this is not possible. You might mean exactly this, in which case it's fine, but this is a SHOULD/MAY construct that's often wrong, so I'm checking. "SHOULD do X but MAY do Y" is correct if Y is *always* optional. But more often, this is what's really intended: The server SHOULD permit this operation even on read-only filesets, but MUST return FEDFS_ERR_ROFS if this is not possible. Is that the case here? This also appears in Section 5.6.2. This one is related: The server MAY enforce the local permissions on the path, including the final component. If the path cannot be traversed because of insufficient permissions, or the final component is an unexecutable or unwritable directory, then the operation MAY fail with status FEDFS_ERR_ACCESS. If you mean this, then the phrasing above is correct: 1. The server MAY enforce local permissions. 2. If it does, then it MAY use FEDFS_ERR_ACCESS to convey failures (but that's entirely optional, and it could use some other code instead). But if you mean this, then you should re-phrase: 1. The server MAY enforce local permissions. 2. If it does, then it MUST use FEDFS_ERR_ACCESS to convey failures. This also appears in Sections 5.2.2, 5.3.2, 5.4.2, 5.6.2, and 5.7.2. -- Section 5.9.2 -- On failure, an error value indicating the type of error is returned. This operation MAY return FEDFS_ERR_NSDB_PARAMS to indicate that there are no connection parameters on record for the given NSDB. The operation MAY return FEDFS_ERR_ACCESS if the operation's associated user does not have sufficient permissions to view NSDB connection parameters. This is similar to some of the others. If you mean to say that using those error codes is entirely optional, even under the conditions specified, then this is fine. But if you mean to say that certain error codes are definitely the ones to use in these situations, then the MAYs are wrong, and you should re-word this. There are similar situations at the ends of Sections 5.8.2 and 5.10.2.
Just trying to follow the bread crumbs … The following is in RFC 5531: Standards Track RPC services MUST mandate support for RPCSEC_GSS, and MUST mandate support for an authentication pseudo-flavor with appropriate levels of security, depending on the need for simple authentication, integrity (a.k.a. non-repudiation), or data privacy. In this draft: Use of RPCSEC_GSS is a MUST - so check mark in that box. Where's the MUST for the authentication psuedo-flavor? Under what circumstance would you be okay with no integrity protection?
Also any thought to MUST NOTing AUTH_SYS and AUTH_DH?
draft-ietf-nfsv4-federated-fs-protocol
Other than the comments on 4.2.1.3 and section 6, these are pretty much nits. - 2.8: I'm not quite clear on the term "subtype" - does that mean that the NFS-specific information is contained in an FSL "annotation"? I guess it does, but this is the first time the term "subtype" is used. - 2.8.1.2: what is "component4" ? I guess its an NFSv4 thing but maybe good to say. (Same for other foo4 things, but just saying once would be fine.) - 2.12: Do you mean that FSN UUIDs only need to be unique per NSDB node. (You might also want to use upper case MUST/SHOULD for some of the uniqueness statements.) - 4.2.1.3: LDAP integers can be of unlimited size. Do you need some kind of max for the fedfsFsnTTL to avoid any potential DoS? What about negative integers? I assume you do not want those? You could say that LDAP clients here MUST implement some kind of max and MUST NOT accept negative integer values. Or, as with other integers you could just say it MUST be between [0,MAX]. - 5.3: I wondered if it would make sense to say that LDAP referrals MUST have the same or better security properties than the original LDAP request that caused the referral? That is, if I start with LDAP/TLS, then I'd barf on a cleartext LDAP referral. - section 6: *use* of TLS is RECOMMENDED which is fine, but you don't say that implementation of TLS is a MUST. I think it'd be good to be explicit about that. (LDAP is a bit oddly structured, maybe in a way to leave wiggle room to say you conform here even though you don't support LDAP/TLS.)
2.8:
A fileset MAY be accessible by protocols other than NFS. For each
such protocol, a corresponding FSL subtype SHOULD be defined. The
contents and format of such FSL subtypes are not defined in this
document.
That doesn't look like protocol to me. I think you can strike the whole
paragraph, but at least get rid of the 2119 terms.
2.8.1.2:
...any non-ASCII UTF-8 code points and any URI-
reserved characters, such as the slash ("/") character, contained in
a component4 element MUST be represented by URI percent encoding.
The phrase "non-ASCII UTF-8 code points" isn't correct. Change it to "non-ASCII
characters". It's closer to right.
2.8.1.3:
In its "server" field, the NFSv4 fs_location4 data type contains a
list of universal addresses or UTF-8 hostnames.
This is in all likelihood a problem with 5661 as well. What exactly do you mean
by "UTF-8 hostname"? Do you mean a U-Label as described in IDNA (RFC 5890, et.
al.), or do you simply mean a US-ASCII hostname in a UTF-8 string data type? If
the former, you're going to have to say more. If the later, you should say
"US-ASCII hostnames" instead.
4.2.1.6:
I've never been clear on why 4512 did as much in the way of customized ABNF as
it did. You could replace all of the ABNF you have in this section with:
ANNOTATION = KEY "=" VALUE
KEY = ITEM
VALUE = ITEM
ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP
DQUOTE and WSP are defined in 5234, and UTF8-octets is defined in 3629. But
it's up to you.
8:
Client: Any client that accesses fileserver data using a supported
file-access protocol.
Fileserver: A server exporting one or more filesystems via a file-
access protocol.
See the admin document. Not very good definitions.
This is a DISCUSS-DISCUSS.
Hopefully a little bit of LDAP education will quickly resolve this one.
I'm looking at section 7.2
http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-14#section-7.2, which speaks about OID. So my OPS AD level of attention suddenly increased.
... one of the authors was
assigned the Internet Private Enterprise Numbers range
1.3.6.1.4.1.31103.x. Within this range, the subrange
1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
federated file system protocols.
From http://www.iana.org/assignments/enterprise-numbers, I see
31103
Daniel Ellard
Daniel Ellard
ellard&gmail.com
Then I thought: Ok, maybe, even if I read "permanently", this enterprise
specific number requested by a specific person was a temporary solution.
However, reading further, yes, there is a new "FedFS Object Identifiers"
registry, but it will still use the 1.3.6.1.4.1.31103.1.x range.
Then I looked at existing practice: http://tools.ietf.org/html/rfc4517
And I see, for example:
The LDAP definition for the Other Mailbox syntax is:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
From http://www.iana.org/assignments/enterprise-numbers:
1466
Mark Wahl
Mark Wahl
M.Wahl&isode.com
Is it normal that Standards Track documents register OIDs under enterprise
specific numbers (on top of that, representing individuals)? Is it normal that
OIDs are registered this way in LDAP?
Note: I know of one PEN used within a standards track document, but this one
was distinctly labeled. 29305
IPFIX Reverse Information Element Private Enterprise
RFC5103 Authors
ipfix-biflow&cert.org
Disclaimer 1: My lack of LDAP is probably the cause of this DISCUSS-DISCUSS. So
please shed some light. Disclaimer 2: I spoke with Martin Stiemerling before
posting this. So I'm really after a reply (from the APPS ADs, I guess) such as:
"don't worry, there are no problems with this."
I'm terribly sorry for the late DISCUSS. I missed this earlier, and only got to it through Benoit's comments. -- Section 7.2 -- Future allocations from the 1.3.6.1.4.1.31103.1.x range are to be assigned by IANA using the "RFC Required" policy defined in [RFC5226]. First, I'd like to know what the justification is for RFC Required. There's no shortage of code points. What harm would there be in allowing more registrations? But second (or maybe this should be first), why is this registry even created at all, when the OIDs are registered *again* in Section 7.3, in the Object Identifier Descriptors registry under LDAP Parameters? Why do we need two different registries for the same things?
The -14 version resolves all my earlier comments, and clears my earlier DISCUSS. Thanks for addressing all this.
draft-ietf-softwire-6rd-radius-attrib
In the Gen-ART Review by Pete McCann on 27-Nov-2012, this comment was provided: > IPv4MaskLen doesn't need to be any more than 8bits long. The authors agreed, but the document has not been updated yet.
This should be an easy thing to resolve: - a quick email to me to tell me there is nothing to worry about - an RFC Editor note to fix the text RFC 3588 has been obsoleted by 6733. I would like to know that the change is just a simple fix of the citation. I am concerned about what may have changed when 3588 was obsoleted.
The repeated use of fields with the same name in the figure in 4.1 is slightly confusing.
4.1: MUST the BNG use different 6rd parameters if the AAA server has ignored the suggested configuration attribute and supplied others in the Access-Accept? Don't you need to say that? 4.2: What would it mean to put a 6rd configuration attribute into an accounting request? Doesn't someone need to say more about that? section 6: Why not consider recommending RADSEC or RADIUS over DTLS? Maybe it'd be worth asking radext WG folks if its now timely to start doing that?
The issue raised by Bernard Adoba (aaa-doctors) has not been addressed in
version 7. See
http://www.ietf.org/mail-archive/web/aaa-doctors/current/msg00738.html
RFC 5080 Section 2.1.1 lays out the requirements for use of a State attribute:
The only permissible values for a State attribute are values provided
in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request packet. A RADIUS client MUST use only those values for the
State attribute that it has previously received from a server. An
Access-Request sent as a result of a new or restarted authentication
run MUST NOT include the State attribute, even if a State attribute
has previously been received in an Access-Challenge for the same user
and port.
This requirement exists to ensure that a State attribute ties back to an
authenticated RADIUS session.
Within the document, the flow diagram describes "cooperation between DHCP and
RADIUS":
6rd CE BNG AAA Server
| | |
|-------DHCPDISCOVER------>| |
| |--Access-Request(6rd Attr)-->|
| | |
| |<--Access-Accept(6rd Attr)---|
|<-------DHCPOFFER---------| |
| | |
|--------DHCPREQUEST------>| |
| (6rd Option) | |
|<--------DHCPACK----------| |
| (6rd option) | |
| | |
DHCP RADIUS
Figure 1: the cooperation between DHCP and RADIUS
This diagram neither indicates that the RADIUS Access-Request/Accept sequence
is authenticated, nor does it show any previous previous authenticated RADIUS
interaction. It therefore appears to violate the RFC 5080 requirement.
- While reading, I flagged the same DISCUSS as Barry regarding T1 in the
following sentence:
If the DHCP server to which the DHCP Request message was sent at time
T1 has not responded, the DHCP client enters the REBINDING state and
attempts to contact any server. In this scenario the BNG receiving
the DHCP message MUST initiate a new Access-Request towards the AAA
server.
- You started to use the terminology from RFC 5969, but for two terms only.
It's a pity that you didn't reuse so other.
4.1. IPv6-6rd-Configuration Attribute
6rdPrefix
The Service Provider's 6rd IPv6 prefix represented as a 16
octet IPv6 address. The bits after the 6rdPrefixlen number of
bits in the prefix SHOULD be set to zero.
...
6rdBRIPv4Address
One or more IPv4 addresses of the 6rd Border Relay(s) for a
given 6rd domain. The maximum RADIUS Attribute length of 255
octets results in a limit of 58 IPv4 addresses.
From RFC 5969:
6rd prefix An IPv6 prefix selected by the service provider
for use by a 6rd domain. There is exactly one
6rd prefix for a given 6rd domain. An SP may
deploy 6rd with a single 6rd domain or multiple
6rd domains.
...
BR IPv4 address The IPv4 address of the 6rd Border Relay for a
given 6rd domain. This IPv4 address is used by
the CE to send packets to a BR in order to
reach IPv6 destinations outside of the 6rd
domain.
-
The IPv6-6rd-Configuration Attribute MAY be used in Access-Request
packets as a hint to the RADIUS server
You should also mention in this section the normal case (the Access-Accept)
before treating the exceptions.
-- Section 3 -- If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. In this scenario the BNG receiving the DHCP message MUST initiate a new Access-Request towards the AAA server. "Time T1" isn't shown in any figure, defined anywhere, or used anywhere else. Further, it's not at all clear to me how this is meant to work. Is there some DHCP Request message that we're not seeing in Figure 2? If not, then the BNG is the DHCP server, and the 6rd CE is the DHCP client, as I see in the diagram, yes? You say if it "has not responded"... has not responded by when? Then you say that if it has not responded, the client "attempts to contact any server." But then you want the BNG to do something relative to this request... what happens when the client succeeds in contacting a *different* server, while this BNG thinks it's still serving this request?
-- Section 1 -- 6rd adopts Dynamic Host Configuration Protocol (DHCP) [RFC2131] as auto-configuring protocol. Do you really mean "adopts" here, or should it be "adapts"? I'm not certain from reading the document, but they imply different things and the RFC Editor won't know whether to change it or not. -- Section 2 -- The terms 6rd CE and 6rd Border Relay are defined in [RFC5969]. It would be helpful to at least expand the terms here, so I don't have to go to 5969 for that: NEW The terms 6rd Customer Edge (6rd CE) and 6rd Border Relay (BR) are defined in [RFC5969]. -- Section 3 -- The caption in Figure 2 is the same as the one in Figure 1, though it represents a different scenario. Please change the caption to make it clear what the difference is. -- Section 4 -- This section defines IPv6-6rd-Configuration Attribute which is used in the 6rd scenario. The attribute design follows [RFC6158]. In Section 3, you describe two different "scenarios". Here, you talk about "the 6rd scenario." Are you talking about both of them here, or just one? Please clarify. I think you're using "scenario" in two slightly different ways. -- Section 4.1 -- Since the subtypes have values, they can appear in any order. If multiple 6rdBRIPv4Address (subtype 3) appear, they are recommended to be placed together. Why are they recommended to be placed together? What happens if they're not? Is this just a neatness thing, or is there an actual reason for it? -- Section 4.2 -- I'm confused by the table: - What is the "#" heading? - The second row appears to be quantity specifiers, except for the last two columns. Why are they different? Ah... Now I think I've figured out what you're doing, but I had to do it by searching all your references for "challenge", and then finding a table like the one you have here. Please don't make people do that. OLD The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. NEW The following table adds to the one in [RFC2865], Section 5.44, providing a guide to the quantity of IPv6-6rd-Configuration attributes that may be found in each kind of packet. -- Section 7 -- IANA should allocate the number from the standard RADIUS Attributes space using the "IETF Review" policy [RFC5226]. The registry actually uses the old term, "IETF Consensus". I don't think IANA will be confused, but I think it would be clearer if you specified this differently. Also, you have to tell the RFC Editor to replace "TBD" in the document with the assigned value. So: NEW IANA should allocate the number from the standard RADIUS Attributes range (values 1-191). The RFC Editor should use the assigned value to replace "TBD" in Sections 4.1 and 4.2, and should remove this paragraph.
Some of these are from the secdir review (and subsequent exchanges between some AAA/RADIUS folks): 1. 6rd is all done on the SP's network so I'm just checking that it's implied that the CE and BNG have a pre-established trust relationship. I went looking for this kind of statement in RFC 5969 and couldn't find the description for a BNG. It would be good to state this (or whatever it is) explicitly in the security considerations. 2. There are two protocols (DHCP and RADIUS) being used in f1/2, but the security considerations only discusses how to secure the RADIUS part. A pointer to the 6rd RFC/draft that discusses how to secure the CE<->BNG bit (i.e., DHCP), I believe, is warranted. A follow on, is what security concerns are there for a rogue CE gather information about other CE's on the ISPs networked? 3. A RADIUS message used for call-check does not contain any information that would authenticate the request and is therefore susceptible to forgery. Therefore, RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet. The "Call Check" Service-Type was designed for situations where authorization can be determined via the Called-Station-Id or Calling-Station-Id attributes, which originally contained telephone numbers. In RFC 3580, Called/Calling-Station-Id could also contain a MAC address, but the principle was similar -- an unique (non-authenticated) identifier which could be used to determine whether a call was authorized. However, this draft does not say anything about use of the Calling-Station-Id or Called-Station-Id attributes, or the value of the User-Name attribute. Given that, the use of Service-Type = "Call Check" would not seem to apply. 4. Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user? If this is the case then the BNG may have received a state attribute in the access-accept message. Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction. If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service. Also, if it is the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange. When DHCP information is retrieved along with user authentication why is either Authorize-Only or Call Check needed? 5. It was not clear in the specification what is sent in the access-request message. Is the BNG looking to get a IPv6-6rd-configuration attribute in the access accept? It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un-ambiguously be able to service the request; there are other uses for the call-check service. I think you should specify that the 6rd attribute must be in the request if you want to see it in the response. 6. s4.1: Need to specify how the reserved bits are handled. Normally it's: The bits MUST be set to zero by the sender and MUST be ignored by the receiver.
1) abstract: This sounds a little like marketing to me: IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. Maybe: IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. 2) s1: r/Recently providers start to/Recently providers have started to 3) s1: r/transit/transition 4) s1: r/is one of the most popular methods to provide/provides 5) s1: r/may be/is 6) s4.1: r/recommended/RECOMMENDED ?
draft-ietf-6man-uri-zoneid
- 2nd para of section 3 says that browsers "should" accept a bare % as input. I don't know if you mean that "should" as a 2119 SHOULD or not. - Same place: Do you need to say that the browser MUST properly escape that if it sends the URI anywhere, that is, that the URI emitted MUST conform to this spec and include e.g., "%25eth0" and not just "%eth0"? - Idle curiosity: anyone know if its possible to use a % character in an interface name on any common OS? If it were, then maybe worth mentioning that that'd also need to be escaped? On ubuntu "ifconfig 25% up" at least gives the same error as "ifconfig foo up" so seems like if I were in a playful mood, I could muck with udev and call an interface "25%". So for the nittiest-nitty folks you could, if you wanted, say that an interface called "25%" might result in a URI containing "[fe80::a%2525%25]" :-) - The secdir review [1] has a number of suggestions that the authors seem happy to take on board. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03638.html
A very small nit in section 2: Note that the behaviour of an IPv6 stack if passed a non-zero zone index for an address other than link- local is undefined. s/non-zero/non-null/ ?
This is a user interface hack for a completely local matter. It is not related
to interoperability over the Internet. It uses error-prone mechanism ("%",
which must be escaped, and will end up being double-escaped by accident), and
is bound to leak onto the Internet in not great ways. It's not worthy of a
standards track document. But it's also not going to improve significantly by
using some other mechanism, it's better documented than not, and I don't have
the energy to argue about whether it should be other than standards track.
"Blech" I say, but I'm not going to stand in its way if that's what the
community wants to do.
I've been really confused by the the appendix, which mentions: Appendix A.
Alternatives Considered However, the solution 3 is the selected solution AFAIT
3. Escaping the escape character as allowed by RFC 3986:
http://[fe80::a%25en1]
Advantage: allows use of browser, consistent with general URI
syntax.
Disadvantage: somewhat ugly and confusing, doesn't allow simple
cut and paste.
However, the word "alternative" forced me to re-read the draft to see if I
missed something...
Editorial:
OLD
The MIB textual convention [RFC4001] and the socket
interface [RFC3493] define this as a 32 bit unsigned integer.
NEW
The MIB textual convention InetZoneIndex [RFC4001] and the socket
interface [RFC3493] define this as a 32 bit unsigned integer.
-- Section 3, first paragraph --
The use of "older versions" and "recent versions" will be meaningless after
this RFC has been published for a while. I suggest "some versions" instead,
for both.
-- Section 3, second paragraph --
As discussed in the AppsDir review thread, maybe it would help to add something
like this at the end of the paragraph?:
Such bare "%" signs are for user interface convenience, and must be
turned into properly escaped characters ("%25" encodes "%" in URIs)
before the URI is used in any protocol.
I think it would be useful to also say something about what happens if, say,
instead of "en1", there's a ZoneID called "ee1". A URI parser encountering
"fe80::a%ee1" would have to decide whether to interpret the "%" as "%25", or
whether to interpret "%ee" as a percent-escaped 0xEE character. Advice would
be useful; lacking useful advice, a warning that this could happen would at
least help a little.
-- Section 4, last paragraph --
Brian's having a conversation with Yves about this on the AppsDir review
thread, with a suggestion that the document recommend stripping the ZoneID
before sending the URI out on the wire. Recording that here for the record.
draft-ietf-netext-pmipv6-sipto-option
The draft was much harder to read than it needed to be. Maybe rework would be a good idea.
Slightly puzzled...
In the IPv4 Traffic Offload Selector Option you have
The traffic selector sub-option includes the parameters used to
match packets for a specific flow binding. This is an optional
field when this option is used only a capability hint.
There is only one other field in the IPv4 Traffic Offload Selector
Option and that is the M bit which describes how to interpret the
traffic selector sub-option. So, it the traffic selector sub-option is
optional, then what is the purpose of the whole IPv4 Traffic Offload
Selector Option?
It seems that the NAT function coexistent with the MAG would cause flows to break during mobility events between MAGs, which would sort of defeat the purpose entirely of using MIP technology to allow the same HoA to be used regardless of the current connection point. The document does not seem to talk about mobility across MAGs and how that handover would be supported since there is now additional state being built-up in the MAGs. The step-by-step process of how this works and what happens to the packet flows while it's happening seems to be completely missing.
I share Benoit's readability concerns, and Stephen's concern with underspecification. In Figure 1, I think it would be more clear for the LMA and NAT to connect to the same Internet cloud and show a CN at the other side of that cloud.
Maybe I'm confused, (fairly likely with me:-) but the protocol seems to be underspecified in at least these respects: (1) Are MAGs (and LMAs) supposed to fully implement all the IPv4 parts of 6088/6089 for this? E.g. 6088 allows one to specify protocol numbers - what if PIM were to be offloaded? What about all of UDP or just DHCP? What about dest=255.255.255.255? Do you need text about that kind of thing and specifically about what kinds of offloading need to be supported at the MAG? (2) How do you handle a case where an LMA asks for stuff to be offloaded that a MAG doesn't support?
- 3.1 and elsewhere, it seems wrong to talk about configuration variables like EnableIPTrafficOffloadSupport since that's implementation specific. That would be better changed to say e.g. "If the LMA is configured to turn on offloading..." or similar. - 3.1, last para: why is this only a SHOULD NOT and when would it be ok to send back the selection option if it wasn't requested by the MAG? Given that the MAG SHOULD ignore this anyway (last para of 3.2) this seems to add complexity for no real benefit. - sections 3 & 4, "M" flag - why are these SHOULDs? Wouldn't all MUSTs be cleaner? - section 4: repeating text from rfc 6089 is fine, but shouldn't you say whether that or the text here takes precedence in the event that e.g. 6089 is updated or obsoleted? (And which is the repeated text anyway, that's not clear to me at least.) - Some examples would be good, esp. for something a bit complex but likely to be wanted, e.g. offload all HTTP except these servers on port 443, if that's supported. (Its not clear to me to be honest.)
In section 3.1, it says:
o If the configuration variable, EnableIPTrafficOffloadSupport
(Section 6) on the local mobility anchor is set to a value of (0),
then the local mobility anchor MUST NOT...
...if the
configuration variable, EnableIPTrafficOffloadSupport (Section 6)
on the local mobility anchor is set to a value of (1), then the
local mobility anchor SHOULD NOT...
and in section 3.2:
o If the configuration variable, EnableIPTrafficOffloadSupport on
the mobile access gateway is set to a value of (0), then the
mobile access gateway MUST NOT...
o If the configuration variable, EnableIPTrafficOffloadSupport on
the mobile access gateway is set to a value of (1), then the
mobile access gateway MUST...
What interoperability failure or network harm occurs if an implementation
ignores the settings of these "configuration variables"? As far as I can tell,
these are local configuration and implementation issues and not suitable for
protocol requirements.
I have a sneaking suspicion that most of the 2119 language in this document is
being "used to try to impose a particular method on implementors where the
method is not required for interoperability" [2119, section 6], which is
inappropriate, but I'd like to start with an explanation of why the above
constitute a protocol requirement.
I found that draft extremely difficult to read: the reading flow is not
logical. Multiple times while reading the draft, I found myself guessing. Let
me show you a few examples:
1. Starting from the abstract
This specification defines a traffic offload mechanism and a related
mobility option for carrying IPv4 Offload traffic selectors between a
mobile access gateway and a local mobility anchor in a Proxy Mobile
IPv6 domain.
The direction is: from the LMA to MAG, to be synchronized on all MAGs where the
user connects. I was already confused when reading the abstract. And the
following figure didn't make it clear, as the point 5 doesn't have a direction
(I now understand that this is logical step, not a protocol step).
MN MAG(NAT) LMA
|------>| | 1. Mobile Node Attach
| |------->| 2. Proxy Binding Update (IPv4TS)
| |<-------| 3. Proxy Binding Acknowledgement (IPv4TS)
| |========| 4. Tunnel/Route Setup
| + | 5. Installing the traffic offload rules
|------>| | 6. IPv4 packet from mobile node
| + | 7. Forwarding rule - Tunnel home/offload
| | |
When reading this figure 2, it's not clear yet that the IPv4 Traffic Offload
Selector option are in the Proxy Binding Acknowledgement message. So this is
even confusing...
2. Another proof that the flow is not right
Section 3.2
* If the (M) flag of the IPv4 Traffic Offload Selector option in
the received Proxy Binding Acknowledgement is set to a value
(0), then the mobile access gateway SHOULD offload all the
mobile node's IPv4 flows identified using the flow selectors
present in the Traffic Selector Sub-option. The mobile access
gateway SHOULD tunnel all other mobile node's IPv4 flows to the
local mobility anchor.
And I will only know about the flag in a later section.
3. And a final proof
4. IPv4 Traffic Offload Selector Option
A new mobility option, IPv4 Traffic Offload Selector option, is
defined for using it in Proxy Binding Update (PBU) and Proxy Binding
Acknowledgement (PBA) messages exchanged between a mobile access
gateway and a local mobility anchor.
In section 4, I finally learned that "is defined for using it in Proxy Binding
Update (PBU) and Proxy Binding Acknowledgement (PBA)"
A logical flow would be:
which problem do we try to solve? use cases
protocol limitations
goal: we will define a Traffic Selector sub-option in the IPv4 Traffic
Offload Selector option. how it work: protocol spec. LMA considerations MAG
considerations limitations: IPv4, encryption
Half through the draft, I had to call a friend to give some background
information.
Coming back to the use cases:
- "Currently, there is no mechanism for allowing some of the subscriber's
IP flows to be offloaded in the access network." "Example of such
non-essential traffic is entirely a policy decision".
However, it would be more interesting with a least one specific use case.
You mentioned:
For example, all the HTTP flows may be
offloaded at the mobile access gateway and all the other flows for
that mobility session are tunneled back to the local mobility anchor.
But what is the use case? Improved QoE?
Another way to express my concern. The figure mentions "Services requiring
mobility, or service treatment", but what are those services that require
mobility?
- As mentioned by Scott Bradner in his OPS-Diretorate review:
Performing an IPv4 traffic offload, by definition, means that at least some
IPv4 to and from a mobile node will not be exchanged with the Internet through
the home network and any firewall and other protections that are operated by
the home network. This exposes the mobile node to some security risks. I
suggest that some mention of this be made in the Security Considerations
section.
- As mentioned by Scott Bradner in his OPS-Diretorate review:
Doing traffic offload may complicate debugging of connectivity issues.
Filtering at the remote site (access network) could mean that IPv4 connectivity
is different than IPv4 connectivity through the home network (this is a variant
of the first issue but focused on debugging problems not the security
implications. It might be helpful to include a short section discussing this
issue.
I do a traceroute: which route shall it take? Some applications will take the
offload path, and some other won't. Now I use active probing (OWAMP, TWAMP, or
IP SLA): if I don't match exactly the selector fields, the active probing will
not take the same path as the application. If I go one step further, i.e. using
this offload mechanism per DPI application (because I guess this is the end
goal), this implies that the active probing will not work any longer to emulate
a specific application. Hence, one of my question about the use case: QoE My
active probing tests will test me: your QoE is fine, while in practice, it's
not...
I really would like to view an "operational aspects" section discussing those
aspects.
- Instead of having a new IP Flow definition, does the RFC5101 one satisfies
your need?
- Are you sure that you will never need this for IPv6
EnableIPTrafficOffloadSupport
This flag indicates whether or not IPv4 Traffic Offload support
needs to be enabled
Don't you want to call that EnableIPv4TrafficOffloadSupport
- Section 6
If the flag is set to a
value of (0), the mobile access gateway MUST NOT enable IPv4
Traffic Offload support for any mobility session. It MUST NOT
include the IPv4 Traffic Offload Selector option in the Proxy
Binding Update.
General comment on section 6: Why do you repeat what you have already specified
in section 3.1 (and section 3.2).
This was a difficult read. I have to strongly agree with the document shepherd, who says in the writeup, "The readbility of the document could be improved. As part of the chair review this has been suggested to the authors." That said, I think the RFC Editor can deal with the situation, and I have no objection to approving this document. Just some non-blocking comments that I'd like the authors to consider: -- Section 1 -- A given operator may choose to offload all traffic except that which requires QoS services (Ex: Voice over IP traffic), or may choose to offload all HTTP traffic. It's not clear whether VoIP is an example of what the operator *would* offload, or of what they wouldn't. I gather it's the latter. It's also possible to read this as having to choose one of these options or the other (everything except QoS traffic, or HTTP traffic). In fact, you're just giving examples. Why not try this?: NEW One operator might choose to offload everything except traffic (such as Voice over IP) that requires QoS services. Another might choose to offload only HTTP traffic. -- Section 1 -- This approach has one limitation with respect to identifying encrypted traffic. IPsec encrypted traffic with no visibility into the application payload cannot be selected for offload. The first sentence introduces the second, and the second specifies what's said in the first (they're not two independent things). In this case, it's better to write them as one sentence with a colon, rather than as two sentences: NEW This approach has one limitation with respect to identifying encrypted traffic: IPsec encrypted traffic with no visibility into the application payload cannot be selected for offload. -- Section 1, Last paragraph -- Is there a reference you can cite for prefix coloring work? -- Section 3 -- You should refer to Figure 1 somewhere in the text. -- Section 5 -- I recommend adding a second paragraph, to make sure this isn't forgotten: RFC Editor: please replace "<IANA-1>" in Section 4 with the assigned value, and remove this paragraph.
Updated I'd echo this draft was a bit of a challenge to follow. if you look at the protocol flow in f2, I'd have expected to read about the MAG first since it starts the protocol instead you went with the LMA. Then in the LMA section instead of going with what it has to deal with when it receives something from the MAG you go with what the LMA must not send. Just a bit backward for me - but this is just a comment so do with it what you will. If the definition for IP Flow from 5101 can't be used maybe the one from 3917? I also didn't follow how you handle a case where an LMA overrides what the MAG tries to set up and the MAG doesn't support it. drafts says: "This option is carried like any other mobility header option as specified in [RFC5213] and does not require any special security considerations." It's misleading IMHO. This option does require security considerations since an attacker, by sending fake signaling messages, may prevent a mobile network from offloading traffic which may lead to a DoS. You'd better say something like: "This option is carried like any other mobility header option as specified in [RFC5213]. Therefore it inherits from [RFC5213] its security guidelines and does not require any additional security considerations." Typos: Section 1: s/its only about IPv4/it is only about IPv4/
draft-ietf-imapmove-command
I don't object to the publication of this document. I think that the motivation may be slightly over-cooked... While I can see good value in facilitating the move operation through a single command, I don't think that the motivation given in the Introduction is particularly helpful. The implication of the text is that the new command will provide protection against partial completion during a failure. But in fact exactly the same operations are needed in the mailboxes using the MOVE command as were previously needed. So while the reduction in commands helps to reduce the failure windows, the use of a single command does not close the windows completely. (Obviously, it makes the life of the Client massively simpler.)
- 3.1, I briefly wondered if MOVE has two or four arguments, maybe s/sequence set/sequence-set/ and s/mailbox name/mailbox-name/ would be a tiny bit clearer. - 3.3, 3rd last para: I didn't get the meaning here, nor am I sure if the "is allowed when..." means that this is not allowed in other situations. I assume this is clear to IMAP folks though. - 3.3, last para: does this mean that a server has to implement a check that pipelined MOVEs don't have overlapping sets of messages, or that servers depend on clients to do the right thing? Do you need to clarify that?
Section 1: Purely editorial nonsense: clients have instead had to use a combination of the UID STORE, UID COPY and EXPUNGE commands to perform this very common operation. Seems to me that you should list the commands without the UID (since they're not required) and in the right order. So instead: clients have instead had to use a combination of the COPY, STORE, and EXPUNGE commands to perform this very common operation. And if you have any reason for keeping the original, do so. Just one AD's OCD. Section 3.3: I suggest inserting a paragraph after the example and before "Because a MOVE applies to a set of messages": Although the effect of the MOVE is the same as the preceding steps, the semantics are not identical: The intermediate states produced by those steps do not occur, and the response codes are different. In particular, though the COPY and EXPUNGE response codes will return, no response code for a STORE will be generated nor will the \DELETED flag be set for any message.
No objection to the publication of the document, but one observation: I believe
that the intro is a little bit light, while I found some good text from the
charter could be cut/pasted:
It's often the case that an IMAP client needs to move (not copy)
messages from one mailbox to another. The mechanism that IMAP
provides to do that is a multi-step process:
1. Copy the messages from the source mailbox to the target mailbox.
2. Flag the original messages in the source mailbox as deleted.
3. Expunge the deleted messages from the source mailbox.
Implementors have long pointed out some shortcomings with this
approach. Because the moving of a message is not an atomic process,
interruptions can leave messages in intermediate states. Because
multiple clients can be accessing the mailboxes at the same time,
clients can see messages in intermediate states even without
interruptions. If the source mailbox contains other messages that are
flagged for deletion, the third step can have the side effect of
expunging more than just the set of moved messages. And servers with
certain types of back-end message stores might have efficient ways of
moving messages, which don't involve actual copying of data. Such
efficiencies are often not available to the copy/flag/expunge process.
We sometimes make too hard to read RFCs by only focusing on the protocol
specifications, and neglecting the problem statement and use case.
The -04 version resolves the issue I was holding that derived from one of Stephen's comments.
draft-ietf-nea-pt-tls
I would really like to see the title of this document updated. PT-TLS indicates that TLS must be used, but the title indicates that TCP must be used. I think the title should reflect that both TCP and TLS must be used.
Comment updated after discussion of implementation status with the document shepherd. --- I think that the protocol is intended to transport Security Postures not any old postures. I would have benefited from a clear and early definition of "Security Posture" - probably lifted from RFC 5209 although a citation might be enough. I should have liked to see these issues clarified in the Abstract and at the top of the Introduction.
a single comment: It is worth noting in Section 3.1.1 that there can be also firewalls in the network which prevent the server from reaching the client. The text describes only the case where the end device has a firewall.
2119 language in IANA Considerations always gives me the creeps. I don't think the ones in section 6.1 are necessary: Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF namespace values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability. I think both "MUST"s here could simply be lowercased, or change to "are required to". There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels. Here, better would be "will need to".
In the OPS-DIR Review by Nevil Brownlee on 20-Nov-2012, this comment was provided: I have performed an Operations Directorate review of draft-ietf-nea-pt-tls-08.txt This is a Standards Track document, describing PT-TLS, "a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel." The document is quite long, and assumes that the reader is familiar with Trusted Computing, Endoint Assessment, and with many acronyms that I hadn't encountered before. That meant that I also had to read (or at least skim) quite a few of the of the Normative-Reference RFCs before completing this review. I suggest that an appendix listing these acronyms and giving a few lines of explanation would be helpful. The document is clearly intended to describe version 1 of PT-TLS, but this is implied in section 3.7.1 rather than being explicitly stated. Perhaps it would help to state this early on in section 3.5? How will implementors find out that newer versions of PT-TLS exist? The IANA Considerations section seems odd to me. It says "This delegation of namespace is analogous to the technique used for OIDs;" which existing IANA Registry are you referring to? Have you asked IANA whether they can support the two-dimensional tables you're asking for?
Version -08 handles all of my comments, and clears the IANA DISCUSS. Thanks!
I needed to get to the third para of the intro before I could find a reference to the definition of "Posture", it would be useful to quote the definition in this RFC and to move the reference to the first para.
I cleared.
draft-ietf-mpls-ipv6-pw-lsp-ping
- I dunno what FEC 128 and FEC 129 mean, but I assume the real audience for this would.
When I see the long list of RFC EDITOR notes for an 8 pages document... I won't spend my time trying reinsert the notes in order to read a clean document. Bottom line: I will trust the other ADs on this one.
Thank you for addressing the issues raised by the RTGdir review.