IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2009-11-19. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Russ
1 Administrivia
2 Protocol Actions
2.1 WG Submissions
2.1.1 New Item
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Item
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Item
2.2.2 Returning Item
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
Telechat:
Telechat:
Telechat:
3.1.2 Returning Item
3.2 Individual Submissions Via AD
3.2.1 New Item
Telechat:
Telechat:
Telechat:
Telechat:
3.2.2 Returning Item
3.3 Independent Submissions Via RFC Editor
3.3.1 New Item
Telechat:
3.3.2 Returning Item
Telechat:
3.3.3 For Action
Telechat:
1318 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1401 EST Adjourned
draft-ietf-syslog-sign
I tried to search the document for an explanation of what the reassembly algorithm is for fragmentation, but found very little material. On IP we always forgot to specify some safety checks such as prohibiting overlapping fragments, and had to patch specifications and implementations later. Perhaps these should be specified here on the first go around? Or is the situation with syslog different from IP? I admit that there's probably no firewalls in syslog that were one reason why fragmentation rules had to be constructed so carefully.
Section 3., paragraph 2:
> For this
> reason, syslog signer and collector implementations implementing this
> specification MUST support messages of up to and including 2048
> octets in length, in order to minimize the chance of truncation.
DISCUSS: Relays also need to support 2048-octet messages. But more
importantly, Section A.2 of RFC5424 has a lot of arguments why for a
UDP transport, a payload size of 480 octets is really recommended. If
this mechanism is to be used with SYSLOG over UDP, it would be
consistent to make the same recommendation here. If the intent is to
have this be used only with TLS, this needs to be explicitly said
somewhere.
Section 6.1., paragraph 1:
> Although the transport sender is not constrained in how it decides to
> send redundant Signature and Certificate Blocks, or even in whether
> it decides to send along multiple copies of normal syslog messages,
> we define some redundancy parameters below which may be useful in
> controlling redundant transmission from the transport sender to the
> transport receiver, and which may be useful for administrators to
> configure.
DISCUSS: Blind retransmissions will not guarantee reliability but will
be guaranteed to waste bandwidth. This is a really ugly mechanism.
Plus, while the section does define "redundancy parameters", it
doesn't discuss at all what they should be set to under what network
conditions. It's really easy to misconfigure things such that a
significant amount of bandwidth is wasted - even when there aren't
even any actual syslog messages being sent.
Section 1., paragraph 6: > The mechanism described in this specification is intended to be used > in conjunction with the syslog protocol as defined in [RFC5424] as > its message delivery mechanism and uses the concept of STRUCTURED- > DATA elements defined in that document. In fact, this specification > mandates implementation of syslog protocol. Nevertheless, it is > conceivable that the concepts underlying this mechanism could also be > used in conjunction with other message delivery mechanisms. > Designers of other efforts to define event notification mechanisms > are therefore encouraged to consider this specification in their > designs. I don't think it's appropriate for the IETF to make a blanket recommendation for this mechanism for other event notifiation systems. (I note that the IETF already has other message signing mechanism that SYSLOG also did not pick, and probably for good reason.) Section 3., paragraph 3: > While syslog signer and collector implementations MAY support > messages with a length larger than 2048 octets, implementers need to > be aware that any message truncations that occur render the mechanism > useless. Wouldn't it make more sense to say that this mechanism MUST NOT be applied to messages > 2048 octets, in order to avoid invalid signature warnings on the receiver? Section 5.3.1., paragraph 2: > Because certificates can legitimately be much longer than 2048 > octets, the Payload Block can be split up into several pieces, with > each Certificate Block carrying a piece of the Payload Block. Note > that the signer MAY make the Certificate Blocks of any legal length > (that is, any length that keeps the entire Certificate Block message > within 2048 octets) that holds all the required fields. Software > that processes Certificate Blocks MUST deal correctly with blocks of > any legal length. The length of the fragment of the Payload Block > that a Certificate Block carries MUST be at least 1 octet. The > length SHOULD be chosen such that the length of the Certificate Block > message does not exceed 2048 octets. See above - for reliability reasons, I think 480 octets are a better size limit. Section 5.3.2., paragraph 0: > 5.3.2. Certificate Block Format and Fields Is there sufficient information in the payload and certificate fields to reassemble a fragmented payload block after retransmission under loss? Section 8.2., paragraph 1: > As a signer, it is advisable to avoid message lengths exceeding 2048 > octets. Various problems might result if a signer were to send > messages with a length greater than 2048 octets, because relays MAY > truncate messages with lengths greater than 2048 octets which would > make it impossible for collectors to validate a hash of the packet. See above, this limit should be 480.
I agree with Lars on Blind retransmissions. The document seems to be ecouraging this and, while there is a configuration parameter noted, it is unclear whether this is mandatory to implement, and to what value certInitialRepeat should default. It seems to me that this mechanism is a bit of a hack.
I can't find a reference to how one computes the non PGP signatures.
I don't believe that two implementations compliant with this spec would
necessarily be able to interoperable. It has a huge number of options and very
weak what must be support by sender and receiver. For example, it not even clear
what the mandatory crypto suites are.
I am a bit skeptical that everyone is going to want to implement both the PGP
and the X.509 approach. I think it would be better to split to two RFC one for
PGP and one for X.509 so vendors could just chose the one they were
implementing. Obviously a vendor could implement both but it would help deal
with the issue of you when both a sender and receiver implement RFC XXXX, you
would know it would work. Did the WG consider this?
On the text requiring a operator acknowledge certain reboots. I can't imagine
how to do this on many embedded devices. Is this necessary?
Can you get a Cert with an IP address in it signed by a well know CA? This draft
seems to require that.
Reading section 5.2.2, it looks like support for X.509 is SHOULD and support for
Open PGP is MAY and X.509 fingerprints is MUST. Is this for both senders and
receivers? If so it seems that X.509 in fingerprint mode is only thing that can
be counted on. Is that what the WG really wanted?
This draft is very hard to understand. I think it needs some high level box and arrows level description of how it works would help implementers get it right.
There is one point which is not entirely clear to me. So I would like to discuss
it before recommending approval of this document:
5.2.2. Signer Authentication and Authorization
b. X.509 end-entity certificate matching: The collector is
configured with information necessary to identify the valid end-
entity certificates of its valid peers, and for each peer, the
HOSTNAME(s) it is authorized to use.
To ensure interoperability, implementations MUST support
fingerprints of X.509 certificates as described below. Other
methods MAY be supported.
I am confused here. Is this requirement on management tools, or on the protocol
itself? I didn't find (or missed) where fingerprints are transferred in the
protocol.
Collectors MUST support key blob type 'C', and specifying the
list of valid peers using certificate fingerprints. The
fingerprint is calculated and formatted as specified in
[RFC5425], Section 4.2.2.
For each peer, the collector MUST support specifying a list of
HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
addresses.
How can this MUST be achieved? Is this again a requirement on management tools?
Other forms of HOSTNAMEs are beyond the scope of this
specification.
4.2.8. Signature
This is a digital signature, encoded in base 64 per [RFC4648]. The
signature is calculated over the completely formatted Signature Block
message (starting from the first octet of PRI and continuing to the
last octet of MSG, or STRUCTURED-DATA if MSG is not present), before
the SIGN parameter (SD Parameter Name and the space before it ["
SIGN"], "=", and the corresponding value) is added.
Did you mean that the digital signature is calculated over the whole
Signature Block message, when ' SIGN="..."' is removed from it?
A clarifying example would be helpful here, or in section 4.2.9.
5.2.1. Block Format and Fields
b. Key Blob Type, a one-octet field containing one of five values:
1. 'C' -- a PKIX certificate.
A reference is missing here.
5.3.2.9. Example
<110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]
It would have been good to see an example of Payload block split into
2 separate Certificate blocks.
8.2. Packet Parameters
Signers need to rigidly enforce the correctness of message bodies.
Problems may arise if the collector does not fully accept the syslog
What does it mean to "not fully accept"?
packets sent from an signer, or if it has problems with the format of
the Certificate Block or Signature Block messages.
9.2. Version Field
The third registry that IANA is requested to create is entitled
"syslog-sign signature scheme values". It is for the values of the
Signature Scheme subfield. The Signature Scheme subfield constitutes
the fourth octet in the Version field of Signature Blocks and
Certificate Blocks. New values shall be assigned by the IANA using
the "IETF Consensus" policy defined in [RFC5226]. Assigned values
are to be increased by 1, up to a maximum value of "9".
This means
that the same Signature Scheme value can be reserved for different
Protocol Versions, possibly in each case referring to a different
Signature Scheme each time.
This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:
"The values are registered relative to the Protocol Version."
This makes it possible to deal with
future scenarios in which the single octet representation becomes a
limitation, as more Signature Schemes can be supported by defining
additional Protocol Versions that implementations might support
concurrently.
Section 5.2.1 list item b includes the key blob type 'K' -- a bare public key.
Section 5.2.2 specifies two methods for X.509 certificate validation and one
method for
validating OpenPGP certificates, but does not specify any method for
validating a bare key.
I would assume that a fingerprint mechanism (similar to
that specified for OpenPGP) is
the straightforward solution. I do not see how
this mechanism can be interoperable without
specifying a base validation
method.
I believe this specification should also clearly state that implementations MUST
support
a corresponding validation method for every Key Blob Type it supports.
Other methods can
be supported as well, but for interoperability I think we
need a baseline.
Section 8.5 states: "... a reviewer can pinpoint any messages sent by the originator but not received by reviewing the signature block information." I don't think this is quite correct. Since the signature block indicates only the first message number, a reviewer can determine (a) that one or more messages are missing, and (b) the range in the sequence that particular message falls in. The specific missing message can only be determined if it is the first message in the signature group or the set of messages was sequential (e.g., if the signature group included messages 3,4,5,6,... and 5 is missing that could be determined). Anyway, I think the word "pinpoint" is misleading.
Section 4.2.2 offers the following option for implementing Reboot Session ID:
> In yet another way, implementers MAY consider
using the snmpEngineBoots value as a source for this counter as
defined in [RFC3414].
RFC 3414 defines snmpEngineBoots as 'a count of the number of times the SNMP
engine has re-booted/re-initialized since snmpEngineID was last configured'.
It looks like it's necessary to make clear that this manner of implementing
Reboot Session ID would work only if there is an SNMP engine at all and if the
SNMP engine and the signer always re-boot at the same time.
In the text above '... implementes MAY consider ...' the MAY should not be capitalized to be consistent with the other 'may' statements in the same paragraph.
The document claims to provide a mechanism to allow the detection of missing
messages, but doesn't discuss that aspect of the mechanism beyond the short note
at the end of the example of one way post-processing could be done. I found it
difficult to convince myself that an online-review system could retrain when a
message was lost without resorting to behavior like what was described for
offline review, and I'm still very unclear on how online-review will retrain
after reboot events. Can the document provide clearer guidance to the
implementer on how this might be realized?
draft-ietf-mboned-rfc3171bis
I agree that yearly review of assigned ranges by IANA is excessive. There's already a requirement for IANA to freeing up unrenewed registrations within 30 days. A single review of the registry triggered by this document, followed by that renewal/freeing process, ought to suffice for the next few years.
Would be nice to include a "Changes from RFC 3171" section.
The cover page shows that this document, once approved, obsoletes
RFC 3171 and RFC 3138. Section 1 says that this document also
updates RFC 2780. The cover page needs to reflect this too. An
RFC Editor Note seems like a fine solution.
The Gen-ART Review by Miguel Garcia on 19-Oct-2009 included some
suggestions:
- Due to the nature of the draft, I think it makes sense to promote
RFC 5226 to a normative reference.
- Expand terms at the first occurrence. This includes:
Section 1: SDP, SAP, GLOP, SSM
Section 8: VMTP
Section 9: ASN
Section 9.2: RIR, AS, eGLOP
- Section 9.2 contains two similar abbreviations: eGLOP and EGLOP.
Those are probably the same and should be unified.
- The document uses quite a few references to URLs. The RFC Editor
does not like this approach because URLs often change with time. So,
I would suggest to refer to the title of the web page instead. It
might be possible that the RFC Editor accepts the addition of a
reference to a URL (which should be valid for some time), but the
main link should be done to the content, not to the URL. This
includes:
Section 1: http://www.iana.org/numbers.html
This page is already obsolete, and the URL redirects to
http://www.iana.org/protocols/; I suggest to refer to the "IANA
Protocol Registries [IANA-protocols]", and the link is in the
reference [IANA-protocols].
Section 11: http://www.iana.org/protocols/apply
I suggest to refer to the "IANA Protocol Registration Forms
[IANA-registration]", moving the link to the [IANA-registration]
reference.
- There is no reference to [SDR], used in Section 7.
- Reference to RFC 1190 is obsolete. RFC 1819 should be used instead.
- Reference to RFC 2030 is obsolete. RFC 4330 should be used instead.
Section 12: Annual Review. I have no idea what IANA is supposed to review or do.
Could this be more specific. I'm also a bit dubious that anything at IETF needs
to be done as often as every year.
Section 4.1. I'm confused about Expert Review,
IESG Approval or Standards
Action process. Is this Expert Review followed by IESG approval or is it "Expert
Review or IESG Approval". The text in 2780 is even more confusing where the
sentence
New values in this range are
assigned following an IESG Approval or Standards Action process.
seems to contradict the following sentence
Assignments of individual multicast address follow an Expert Review,
IESG Approval or Standards Action process.
Can someone help me get unconfused by what this all means.
10.1 Just because a packet is scoped to stay within the domain, I don't
understand why that means we don't need a registration procedure with well known
addressees. Imagine I want to build some multicast service to find other IM
client within the domain, or say printers. Building a protocol that requires the
admin to pick and configure an address for every device they deploy that uses
the protocol is just not practical. Can we have a registry for at least some
subset of the admin scoped space.
8.1 SSM. I agree that in many uses cases SSM assignments are not needed. But it
seems like in some cases it might be useful to have some for certain cases.
Seem my comment on point 10.1 above.
draft-ietf-6man-overlap-fragment
Section 8., paragraph 1:
> [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
> Considerations for IP Fragment Filtering", RFC 1858,
> October 1995.
DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC
1858
Section 8., paragraph 4:
> [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
> Co-existence Security Considerations", RFC 4942,
> September 2007.
DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC
4942
INTRODUCTION, paragraph 2: > Handling of overlapping IPv6 fragments Imprecise title. This ID isn't about handling such fragments, it's about forbidding them. Section 4.5, paragraph 0: > This document explores the issues > that can be caused by overlapping fragments. Last sentence should add the "and updates 2460..." bit from the abstract. Section 3., paragraph 11: > The TCP header has the following values of the flags S(YN)=1 and > A(CK)=1. This may make an inspecting stateful firewall think that it > is a response packet for a connection request initiated from the > trusted side of the firewall. Hence it will allow the fragment to > pass. Stateful firewalls are called stateful because they track the transport protocol connection state. So a stateful firewall would *only* pass this packet *if* it was actually in response to a prior SYN in the opposiute direction. So I don't quite see how this attack is feasible. Section 4., paragraph 1: > IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT > create overlapping fragments. When reassembling an IPv6 datagram, if > one or more its constituent fragments is determined to be an > overlapping fragment, the entire datagram (and any constituent > fragments, including those not yet received), MUST be silently > discarded. I agree that it must be discarded, but whether this is done silently is clearly a management decision of the local stack. Section 5., paragraph 1: > This document discusses an attack that can be used to bypass IPv6 > firewalls using overlapping fragments. It recommends disallowing > overlapping fragments in order to prevent this attack. Imprecise language: It doesn't just "recommend" it, it makes it a requirement.
I think this is a fine piece of work, but I have some difficulty
with the way it is positioned. It seems to be a little too timid about
updating the base IPv6 spec.
According to the Abstract, this document has two purposes:
- document the issues
- update 2460 to ban overlaps.
The Introduction, however, only talks about documenting the issues.
As far as I can see, the update to 2460 is actually more important than
the justification of the issues, so it would be good if the Introduction
was a little more fullsome.
But Section 4 is unclear. It is titled "Recommendation". If this work
truly updates 2460, this is not a recommendation; it is a protocol
modification.
The Gen-ART Review by Francis Dupont on 29-Oct-2009 included a few
editorial suggestions:
- page 1: allows -> does not disallow??
- page 2: Acknowledgements -> Acknowledgments
- page 3: the term 'check' is not enough because it is for protection,
something like 'security check' should be better (but a bit too
strong).
- page 5: it is possible to get bad overlapping fragments from an error
too (i.e., it is not always an attack, of course the action should be
to drop the whole packet anyway).
- page 6: received), MUST -> received) MUST?
- page 6: Acknowledgements -> Acknowledgments
I agree with the basic recommendation of this draft that overlapping fragments
should not be allowed (in v4 and v6) but I'm not at all convinced by much of the
rest of text. Was this reviewed by firewall people - my understanding tis the
best practice in statefull inspection firewalls is to reconstruct the full
packet. If this is true, the advice in the draft probably needs to be adjusted
slightly.
I find this draft very confusing. Why would a firewall allow a packet in because
the SYN= ACK=1. Are you aware of any firewalls that would actually do this when
there had not be an outbound SYN first? Are there really commonly used firewalls
that use 1858 ? The statefull inspection firewalls I have used reassembled the
packet.
In section 4, what happens if you get a duplicate of a fragment? Is that an
overlap causing discard?
The recommendation in section 4 includes:
> When reassembling an IPv6 datagram, if
one or more its constituent fragments is determined to be an
overlapping fragment, the entire datagram (and any constituent
fragments, including those not yet received), MUST be silently
discarded.
It is not clear what 'silently' means here. It looks like the discards due to
such overlapping datagrams should be counted and reflected through some
management interface, which may chose to send notifications about the attack for
every or whenever a number of such events is recorded. In this case the discard
is not completely 'silent'.
draft-ietf-pkix-authorityclearanceconstraints
Section 5.1: there are potentially two certification paths of interest when using ACs (one for the AA, another for the end-entity); it would be helpful if the text said "certification path for the AA" whenever it talks about paths here. Section 9: "If there is no Clearance associated with a TA, it means that the TA has not been assigned any clearance." Should this be "..., it means the TA is not constrained"?
Section 2
The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]:
I don't think it is a good idea to repeat this definition here. It
appears to create to normative definitions of the same thing, and
could cause an issue if some difference creeps in.
Section 7 says: The algorithm described in here has the idempotency, associative, and commutative properties, like the rest of the processing rules in this document. I am not sure that all of the processing rules in the document are idempotent, associative, and commutative. Maybe best to drop the final clause? --- Appendix I don't object, but... This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in X.680. If the material is normative, perhaps it should be moved into the main body of the document. --- Appendix -- The following is a '02 version for clearance. Do we really need this in the RFC? I assume this is from the -02 revision of the I-D. --- Nit Section 1 Since [RFC3281bis] does not permit chain of ACs, s/chain/ chain/
The 2002 edition of the X.680 ITU-T receommendation defining ASN.1 basic
notation was superseeded by the 2008 edition. Is there any reason not to include
the newer version as Normative Reference?
draft-ietf-dna-simple
Discuss-discuss: I'm inclined to agree with Tim that this document
updates RFC 4861. In addition to the change Tim noted, this document
also specifies fast transmission of an RS without the initial delay
specified in section 6.3.7 of RFC 4861. Similarly, this document
calls for the transmission of an initial DHCPv6 message without the
initial delay specified in section 17.1.2 of RFC 3315. The document
also modifies the retransmission rules for several messages. And,
although I hate to raise this issue, this document suggests that
a DHCPv6 transaction is initiated before the hsot has seen the M/O
bits in an RA.
In section 4.1, I think each table entry should include:
o Link-local IPv6 address of the router that advertised the prefix.
o Link-layer (MAC) address of the router that advertised the prefix.
o One or more IPv6 addresses; for each address include:
* flag to indicate whether the address was obtained through
SLAAC or DHCPv6
* preferred lifetime
* valid lifetime
* other configuration information if address was obtained
through DHCPv6:
- DUID
- IA_ID
- flag indicating IA_NA/IA_TA
- other configuration information (DNS recursive servers, NTP
servers, etc.)
o One or more prefixes assigned to the link
* preferred lifetime
* valid lifetime
* on-link flag
In section 4.2:
o Sending of neighbor discovery or DHCPv6 probes
is incorrect ("or"). The host always sends NS probes and RS requests;
it *may* send a DHCPv6 confirmation early as an optimization.
In section 4.4:
For the purpose of sending neighbor solicitations to previous
routers, the host first identifies the set of operable IPv6 addresses
(candidate set) that it wishes to use. If the addresses obtained
from a previous router are no longer valid, the host does not include
these addresses in the candidate set for NS based probing.
s/operable/valid/ At this point, the host does not know what link it
is attached to, so it cannot determine which addresses are operable.
Also, the second sentence in this paragraph is redundant assuming the
change to "valid" is made.
More abstractly, I would rewrite this paragraph and the following
paragraph to allow for multiple addresses on an interface:
For the purpose of sending Neighbor Solicitation messages to
previous routers, the host first identifies the set of candidate
routers to probe. Any router in the SDAT for which there is at
least one valid address is in the set of candidate routers.
For each router in the candidate set, the host obtains the
link-local and MAC addresses of the router from the SDAT. The host
then sends a unicast Neighbor Solicitation to the router's
link-local address.
In the next paragraph, make "Router Solicitations" singular. The
first paragraph in this section has a MUST requirement that the host
only send one Router Solicitation.
In section 4.5.1, I am baffled by the last paragraph. No DHCPv6
address is used anywhere else in the probe NS message and I can think
of no reason why "The probing node SHOULD include a Source link-layer
address option in the probe messages if the address was obtained using
DHCPv6".
Section 4.6 is somewhat problematic, in that a host is expected to use
a Confirm message if it already has assigned addresses and a Solicit
message if not. Thinking about the problem a little, I would suggest
turning the solution around as follows:
* Send a Solicit message
* Compare the addresses in the Advertise message to the addresses in
the SDAT
* If a match is found, assume connection to the corresponding link;
otherwise
* Complete the DHCPv6 message exchange with a Request and wait for the
Reply
Otherwise, the host will need to send a Confirm message for each of
candidate links and a Solicit message in case it is attached to a new
link.
In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use
the current info in the RA; why would it try to reuse any cached info
from a previous attachment?
Also in the same para, what does it mean to receive a "DHCPv6 message [...]
which contains prefixes that intersect with those previously
advertised by a known router"? A DHCPv6 message contains assigned
addresses and other configuration information, but no prefixes. I'm
guessing the idea is to use the DHCPv6 response as an optimization, in
case it is received before any NA or RA messages. If I have that
right, then the check would have to be that the set of addresses in
the DHCPv6 message matches the set of previously assigned addresses
associated with the probed router.
In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP network" I think all of the text in the first paragraph of the introduction is more or less at odds with the rest of the document. Moving to a different IP network is not what this document is about. The machinery in this document identifies if a host reattaches to a link to which it has been previously attached. It accomplishes that result by determining if it has reachability to a router it has previously used as a default router. If the host determines it has been previously attached to its current link, it reuses the previously used addresses and other configuration information. Similarly, section 2.1 has several goals that mention "link change" when, in fact, Simple DNA is all about determining link reattachment. Section 2.2: When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. But, section 4.6 suggests initiating DHCPv6 before receiving an RA, which reduces latency in completing DHCPv6 transaction for address assignment on a new link. Section 2.4: Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Not true. Simple DNA hanges the timing of DHCPv6 transmission and uses Solicit when Confirm would be appropriate. In section 2.5, if assumption 1 does not hold, a host may make an incorrect determination of which link it has attached to. In section 4, the second paragraph describes reattaching to the same link, while Simple DNA determines whether the host has reattached to *any* link to which it has previously been attached. In section 4.5.2, is there any difference between this RS message contents and the RS message contents specified in RFC 4861? If there is no difference, just reference the appropriate section of RFC 4861. There should be some text somewhere about when info is cached in the SDAT and when info is flushed from the SDAT.
DISCUSS: I believe the majority of the SHOULDs in this ID should
become MUSTs. Some examples below. Please check them all.
Section 2.4., paragraph 1:
> Detecting Network Attachment is performed by hosts after detecting a
> link-layer "up" indication. The host simultaneously sends multicast
> Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs)
> in order to determine whether previously encountered routers are
> present on the link.
DISCUSS: Section 4.9 has appropriate text on handling retransmissions
of a single probe. What I'm missing is some text that recommends an
upper bound for how many previous networks should be probed for.
Clearly, probing for hundreds of previously known networks will
results in thousands of packets that will all be sent without any sort
of congestion control, which would be a problem. Similarly, probing
for a small number of previously known networks will be fine. Can we
add a recommendation that says that you should limit yourself to
probing for at most X (10?) previous network locations?
Section 2.2., paragraph 1: > The Simple DNA protocol provides substantial benefits in some > scenarios and does not provide any benefit at all in certain other > scenarios. Compared to what? Section 4.1., paragraph 1: > In order to correctly perform the procedure described in this > document the host needs to maintain a data structure called the > Simple DNA address table (SDAT). This data structure is maintained > by the host on a per interface basis. Why per-interface? Can't this be shared among all interfaces? Section 4.3., paragraph 2: > After the indication is received, the host considers all currently > configured (non-tentative) IP addresses to be deprecated until the > change detection process completes. It SHOULD also set all Neighbor > Cache entries for the routers on its Default Router List to STALE. Why SHOULD and not MUST? Section 4.4., paragraph 1: > When a host receives a link-layer "up" indication, it SHOULD > immediately send both a Router Solicitation and if it retains at > least one valid IPv6 address, one or more unicast Neighbor > Solicitations. Why not MUST? Section 4.4., paragraph 4: > The host SHOULD NOT send > unicast Neighbor Solicitations to a test node corresponding to an > IPv6 address that is no longer valid. Why not MUST NOT? Section 4.6., paragraph 3: > Where an > existing valid address is being tested for operability, this address > should be placed in the Identity Association's IAADDR element, and > the DUID associated with that address should be copied to the DHCP > SOLICIT from the SDAT. should -> MUST? (2x) Section 4.7., paragraph 2: > On reception of a Router Advertisement or advertising DHCPv6 message > (a REPLY or ADVERTISE) which contains prefixes that intersect with > those previously advertised by a known router, the host utilizes the > configuration associated with the detected network. What exactly does "intersect" mean? Do you mean "all prefixes returned must match the prefixes in the SDAT associated with a router" or "at least one returned prefix must match one of the prefixes associated with a router in the SDAT?" Section 4.7., paragraph 3: > When the host receives an advertisement containing only prefixes > which are disjoint from known advertised prefixes, the host MUST > determine whether the solicited advertisement corresponds to any of > the routers probed via NS. Do you mean "disjoint" as in "doesn't match *any* of the prefixes associated with *any* router in the SDAT? Section 4.7., paragraph 4: > If it does, then the host SHOULD conclude > that the IPv6 addresses corresponding to that router are no longer > valid. Since any NS probes to that router will no longer provide > useful information, further probing of that router SHOULD be aborted. I think these need to be MUSTs, or else explain when it wouldn't be. Section 4.7., paragraph 6: > When the host receives a Router Advertisement in reply to the Router > Solicitation it sent, the host SHOULD look for a Neighbor Cache entry > for the sending router and SHOULD mark that router's Neighbor Cache > Entry as REACHABLE if one was found. The host SHOULD add a new > Neighbor Cache Entry in the REACHABLE state for the sending router if > one does not currently exist. I think all of the SHOULDs need to be MUSTs.
As already reported in the Gen-ART Review by Brian Carpenter, the
"Updates: 4861" should be removed from the cover page. This
specification makes normative references to RFC 4861, it does not
update it. An RFC Editor Note seems like a fine solution.
There are three issues that I would like to see addressed before moving to No
Objection.
(1) [Note: this is in direct conflict with Russ's discuss!]
Brian Carpenter suggested that the "Updates 4861" be removed in his Gen-ART
review.
I believe this document does update 4861. Specifically Section 6.2.6
of RFC 4861 states:
In all cases, Router Advertisements sent in response to a Router
Solicitation MUST be delayed by a random time between 0 and
MAX_RA_DELAY_TIME seconds.
Section 2.4 of draft-ietf-dna-simple states:
As a result, in addition to implementing simple DNA, it is desirable
that routers adopt procedures which allow for fast unicast Router
Advertisement (RA) messages.
My interpretation of this statement is that a shorter delay is recommended,
which would
be an update to 4861. (Am I misinterpreting this text?)
(2) Assuming my interpretation regarding the update to 4861 is correct, I
believe that the
shorter delay has implications for congestion control and for
security (specifcally DoS
attacks). These implications need to be addressed in
the document - the latter should be
addressed in the security considerations.
(3) Yaron Sheffer suggested the following addition to the security
considerations
The DNA procedure does not in itself provide positive, secure authentication
of the
router(s) on the network, or authentication of the network itself, as
e.g. would be
provided by mutual authentication at the link layer. Therefore
when such assurance
is not available, the host MUST NOT make any security-
sensitive decisions based on
the DNA procedure. In particular, it MUST NOT
decide it has rejoined a network known
to be physically secure, and proceed
to abandon cryptographic protection.
I believe that something along that line would be a sensible addition.
From Yaron's secdir review: 4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both have such a value. 4.3: "all currently configured IP addresses" - but only for this physical interface, right? 4.8: why is no DAD performed? Someone else might have joined the network while I was disconnected, and has a duplicate of my address.
draft-ietf-mmusic-connectivity-precon
Section 3.2., paragraph 2: > Packets may be both sent and received on the media streams in > question. However, such packets SHOULD be limited to packets that > are necessary to verify connectivity between the two endpoints > involved on the media stream. That is, the underlying media stream > SHOULD NOT be cut through. For example, ICE connectivity checks > [I-D.ietf-mmusic-ice] and TCP SYN and ACK packets can be exchanged on > media streams that support them as a way of verifying connectivity. I'm a bit confused about the TCP case. In Section 1, you say "(...) where the media is carried over (...) TCP [RFC0793], the connection-establishment procedures may fail." TCP establishes a connection with SYN/ACKs. If they are the reason for failure, how can you use them to verify connectivity?
In section 4, there are four numbered points...
1. if an explicit connectivity verification mechanism (e.g., ICE) is
negotiated, the precondition is met when the mechanism verifies
connectivity successfully, otherwise
2. if a connection-oriented transport (e.g., TCP) is negotiated, the
precondition is met when the connection is established.
3. in other cases, an implicit verification mechanism MAY be
provided by the transport itself or the media stream data using
the transport
4. if none of the above apply, connectivity cannot be verified
reliably and the connectivity precondition will never be
satisfied if requested.
This reads
if (1)
else if (2)
else (3)
else (4)
Or am I missing something?
Time to remove section 9?
The Gen-ART Review by Francis Dupont provided editorial suggestions, and the author said they would be included in a future revision. A revision has not been posted yet.
I only have some minor comments and likely to clear upon receiving a clarifying
response.
4.2. Explicit Connectivity Verification Mechanisms
For example, with an
RTP-based media stream where RTCP is not suppressed, connectivity
MUST be ascertained for both RTP and RTCP; this is a tightening of
the general operational semantics provided in Section 3.2, which is
imposed by ICE.
Does this mean that ICE is a normative dependency? (And currently it isn't.)
3.1. Syntax
The connectivity precondition type is defined by the string "conn"
and hence we modify the grammar found in [RFC3312] as follows:
precondition-type = "conn" / "qos" / token
ABNF document reference is missing here.
Where "token" is defined?
4.1. Media Stream to Dialog Correlation
In the absence of a dialog-to-media-
stream correlation mechanism (e.g., ICE), a UAS (User Agent Server)
MUST NOT require the offerer to confirm a connectivity precondition.
It is not clear to me what is required here. Can you elaborate?
4.3. Verifying Connectivity for Connection-Oriented Transports
In the case of
TCP for example, once the TCP three-way handshake has completed (SYN,
SYN-ACK, ACK), the TCP connection is established and data can be sent
and received by either party (i.e., both a send and a receive
connectivity precondition has been satisfied). SCTP [RFC4960]
connections have similar semantics as TCP and SHOULD be treated the
same.
Why SHOULD and not MUST?
In Section 6:
Since B asked for confirmation about the "send" connectivity (from
A's point of view), A now sends an UPDATE (5) to B to confirm the
connectivity from A to B:
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:conn e2e send
a=des:conn mandatory e2e sendrecv
a=des:conn mandatory e2e sendrecv
Is it Ok that the last line is repeated here?
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
7. Security Considerations
Connectivity preconditions rely on mechanisms beyond SDP such as
TCP[RFC0793] connection establishment, or ICE connectivity checks
[I-D.ietf-mmusic-ice] to establish and verify connectivity between an
offerer and an answerer. An attacker that prevents those mechanism
from succeeding can prevent media sessions from being established and
hence it is RECOMMENDED that such mechanisms are adequately secured
by message authentication and integrity protection. Also, the
mechanisms SHOULD consider how to prevent denial of service attacks.
The last sentence - how?
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
This looks Informative.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004.
With the S/MIME-->SIP identity RFC Editor this can be removed or be made
Informative.
This is a minor DISCUSS on a suggested RFC Editor Note; that is, the following
text has been
suggested by the author as a resolution to LC comments but does
not appear in the tracker
or in the document:
OLD:
S/MIME [RFC3853] provides such end- to-end integrity
protection, as described in [RFC3261].
NEW:
The SIP identity mechanism specified in RFC 4474 [RFC4474] provides
such end-to-end integrity protection.
The replacment text isn't always correct, since the SIP identity specification
also permits
a proxy server to provide identity services and to verify
identities. I would also prefer to
see the S/MIME reference preserved, even
though we expect SIP identity to be the dominant
mechanism in deployments. As a
result, I suggest the following RFC Editor Note instead:
OLD:
S/MIME [RFC3853] provides such end- to-end integrity
protection, as described in [RFC3261].
NEW:
S/MIME [RFC3853] provides such end- to-end integrity
protection, as described in [RFC3261]. When the user
agent provides identity services (rather than the proxy server),
the SIP identity mechanism specified in RFC 4474 [RFC4474] provides
an alternative end-to-end integrity protection.
The OPS-DIR review performed by Menachem Dodge provided a couple of editorial
suggetions that seemed to be accepted by the editors but not incorporated in the
note to the RFC Editor or in a revised I-D:
1. It would be useful if a note was placed in section 3.1 stating that this is
only a partial grammar, that this document and RFC 5027 define distinct elements
for the ABNF rule named precondition-type and referring the reader to the IANA
registry; and referring to section 5 for a discussion of the other precondition
types.
2 Section 6. Examples
In the case of the second example which refers to Figure 2:
In SDP3 there is a repeated "a=des:conn" line:
a=curr:conn e2e send
a=des:conn mandatory e2e sendrecv
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
I was also wondering whether SDP4 could be shown for completeness
of the example.
Section 3.2:
In the case of RTP-based media streams,
RTCP connectivity MAY be verified, but it is not a requirement.
I find this exception for RTCP very strange for a number of reasons. First, RTCP
is an important part of most RTP/RTCP applications. Thus not requiring RTCP to
be verified, when still an application is signaling to be using RTCP seems
strange. I would note that if an application in SDP signals that RTCP is not to
be used, then you obviously don't need to verify connectivity you are not using.
But if the application is indicating RTCP usage I strongly think it needs to be
verified. Secondly, as you write later in the document it can't be utilized with
ICE.
My suggestion is to remove that RTCP exception.
draft-ietf-forces-sctptml
Section 4.2.1.5., paragraph 0:
> 4.2.1.5. Scheduling of The 3 Channels
DISCUSS: You're not getting strict prioritization by using three
sockets, even if a sender gives transmission priority to HP over MP
and LP and a receiver first serves all requests queued up in the HP
buffer before going on to the MP and LP channels. That's because there
is no *transmission* prioritization between the three streams. In
other words, a sender can enqueue enough MP and LP messages to delay
transmission/reception (and hence processing) of HP messages - SCTP
will not preempt transmission of queued MP and LP data when new HP
data shows up; all transmissions will occur in parallel. I want to
make sure that this is clear and will not cause issues for FORCES
before I clear the discuss.
Section 4.2.2.6., paragraph 1: > The architecture of this TML defines three separate channels, one per > socket, to be used within any FE-CE setup. The scheduling design for > processing the TML channels (Section 4.2.1.5) is strict priority. A > fundamental desire of the strict prioritization is to ensure that > more important work always gets node resources such as CPU and > bandwidth over lesser important work. See above; the current scheme doesn't really result in this.
The reference for IKEv1 should be to RFC 2409, not 4109 (which is just a list of algorithms, not the protocol itself).
I found this an interesting and readable document, but I have a number
of concerns. These are largely editorial rather than technical, so it
should be possible to resolve them relatively easily.
---
I don't understand how [FE-PROTO] is not a normative reference.
---
Section 3.2.1
There are two interfaces to the PL and TML, both of which are out of
scope for ForCES.
I don't undesrtand this. This is a ForCES working group document. If
these interfaces are out of scope, why are they described here, and why
is Appendix B present?
The "TML API" is also mentioned in Section 4.2
---
Section 4.2.1
There are some 'MUST' statements about the priority levels on each of
the channels, and which channels each message must use. What happens if
an implementation violates this?
---
Section 4.2.1.5
Is this scheduling description actually essential for correct
interoperability, or is this just advice for how to make a nice
implementation? It is true that an implementation that follows a
different scheduling algorithm might become congested and not be able
to deliver the right ForCES messages, but isn't that a broken
implementation rather than a non-conformant implementation?
I would prefer this scheduling description to move to the Appendix with
the other information about scheduling.
---
Section 9.2
Seem to be missing some publication information for [SCTP-API]. Is this
an I-D or an RFC? If so, what is its name/number?
Always a shame that I-D nits doesn't pass cleanly. --- Section 1 I may be being over-sensitive, but it seems odd to me that TCP is not listed in the set of examples in the definition of ForCES Protocol Transport Mapping Layer. --- Section 4 We all love SCTP, but is this document the right place to describe it? --- Section 4.2.1.2 it is strongly recommended Is that 'RECOMMENDED'? --- Section 6 The IANA section could really use a little extra meat. I see that IANA has worked out what to do, but it would not hurt to name the registries and show the specific allocations. (Text not unlike that in IANA's last call evaluation.) === Nits Shouldn't include citations in the Abstract. --- Section 1 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol architecture that defines the ForCES protocol architecture and the state transfer mechanisms as defined in [FE-PROTO]. The layer defines the architecture? Or the layer is part of the architecture. --- Section 3 The ForCES protocol layering constitutes two pieces: the PL and TML layer. This is depicted in Figure 1. I think the 'L' in PL and TML stands for 'layer'. --- Section 3 There is some content overlap between the ForCES protocol draft [FE-PROTO] s/draft/specification/ --- Section 3.1 by the IETF [FE-PROTO]. The PL level is responsible for associating Now it is the "layer level"? :-) Ditto 3.2 The TML level Etc. throughout the document. --- Section 8 discussions that have made this draft better. s/draft/document/ --- Section 3.2.1 Figure 2 also shows an interface referred to as CEM/FEM[RFC3746] This use of "also" confused me. The previous paragraph talks about two interfaces. This is not a third intercace.
The Gen-ART Review by Avshalom Houri provided editorial suggestions, and the author said they would be included in a future revision. A revision has not been posted yet.
I think SCTP is a fine protocol for Forces to use and have no fundamental objection to this specification. Few small comments Note I am not in agreement with the statement SCTP is also very mature and widely used making it a good choice for ubiquitous deployment. One of the normally quoted advantages of SCTP is no HOL blocking. I was fascinated to read 4.2.1.1. I've actually pointed this out to some of the authors / proponents of SCTP before and they violently disagree with me. Do they agree with section 4.2.1.1? Just to be clear, I do agree with it.
9.2. Informative References
[FE-MODEL]
Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
Model", October 2008.
[FE-PROTO]
Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J.,
Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R.
Gopal, "ForCES Protocol Specification", November 2008.
Are these suppose to point to drafts?
If not, RFC numbers are missing.
The DISCUSS and COMMENT is largely based on the OPS-DIR review performed by
Juergen Quittek which was not answered by the authors:
1. I am missing a statement on how ForCES messages are encoded in SCTP messages.
Even if this is done straightforward, i.e.
each message is transferred as
payload of a single SCTP packet, this should be explicitly mentioned. May there
be a need for distributing a single message over several SCTP packets?
May
several messages be sent in a single SCTP packet?
In the appendix you address
this step of processing in figure 8 calling it "Format msg." and "decapsulate".
But also here it does not become clear what "formatting" and "decapsulating"
mean.
This should be explicitly discussed by the document. Maybe I missed it
when reading the draft, but if not, please clarify.
2. In Figure 7 there is a message from the CE TML to the FE TML.
According to
the figure, this message is not related to any corresponding ForCES message. How
would this message be encoded in an interoperable way? Which document defines
the encoding?
Please provide a normative reference to it.
3. Section 4.2.2.3 states that "By using 3 sockets in conjunction with the
partial-reliability feature, both timeliness and prioritization can be
achieved.".
I have two comments on this sentence:
- You say "can be achieved".
This is not sufficient.
I would read it as "Can be achieved, but typically
are not"
- Why does the choice of three sockets provide prioritization?
- The SCTP stack may block packets on the high priority
socket because
it processes packets on the low priority
socket. You need to argue here
that you use SCTP
prioritization and that the SCTP stack specification
(please refer to normative reference) requires all
compliant
implementations to handle priorities as
required by [FE-PROTO].
-
Prioritization of different SCTP sockets is not dealt
with at routers
between FE and CE. Why do you think
that at these routers low priority
packets would not
block high priority packets? Or if they did, why would
you still meet the requirements of [FE-PROTO]?
4. In section 7.1.1, second paragraph you state: "It should be straightforward
to extend such a policy to alternatively use the
3 SCTP TML port numbers as SPD
selectors. But as noted above this choice will require increased number of SPD
entries."
" It should be straightforward ..." is a speculation that does not
seem to be appropriate in a standards track RFC. What if it is not
straightforward? Maybe you rather want to say:
"Implementors MAY extend such a
poliy to ...".
5. In section 4.2.1.5 the second sentence is "The LP channel is processed only
if a channel that is higher priority than itself has no more messages left to
process." This is not correct. If one channel with higher priority has no more
message, there still may be another one that has a message. Suggestion:
"The LP
channel is processed only if there is no channel with higher priority that has
one or more messages left to process."
6. In appendix B.1, the last lines on page 25 include "On success ... a success
indication is presented to the TML".
I think it is not the TML but the PL to
which the indication is presented.
7. The first section of appendix B.3 says: "The TML is agnostic to the nature of
the PL message it delivers to the remote TML".
This in in contradiction to the
first line of the next paragraph
saying: "When the FE PL sends a message to the
TML, the TML is expected to pick one of HP/MP/LP channels and send out the
ForCES message". Choosing the appropriate channel and priority for a message is
not what I would call "being agnostic to the nature of the message".
1. An Abstract section should not include references
2.. In section 3.1, last but one line you use the acronym LFB.
Please explain what it refers to.
3. Section 4.2.2.5 is titled "Satisfying HA Requirement". Please explain acronym
"HA".
4.In section 7, the last but one line before section 7.1 you write "([FE-
PROTO])". I would remove "(" and ")".
5. In appendix A the last word on page 21 is "discuss". I think it should be
"discusses".
6. in appendix A.2, last two lines I would replace "The implementor is left to
..." with "It is left to the implementor to ...".
7. Appendix B, first two lines: Please replace "provides" by "discusses",
"outlines", "describes", "defines", "specifies", or another word that is more
appropriate.
8. Appendix B, lines 4-5: "The implementer is expected to worry about details
...". A standards track document should not request an implementer to "worry"
:-) Please replace "worry about" with another phrase, for example, "take care
about".
9. Some times you use "implementer", some times you use "implementor". Both
words are fine. But it would be nice if you decide for one form of this term and
use only this one.
10. Appendix B, enumerated item 2, first line:
"Sending and reception" -> "Sending and receiving"
11. Appendix B, figure 7: Please label the message from CE TML to FE TML. All
other messages are labeled, but this one is not.
12. The complete IANA considerations section consists of one
sentence: "This
document makes request of IANA to reserve SCTP ports 6700, 6701, and 6702. This
document also requests for SCTP PPID 21, 22, and 23." I think that usually IANA
needs more information for creating these entries in their registries. In 4.2.1
there is text which explains what each value means which should be reflected
here, so that IANA knows exactly what each port value and PPOD means.
13. [FE-MODEL] and [FE-PROTO] are still Internet-Drafts. If they are approved as
RFCs then the RFC number needs to be mentioned, if not the last I-D and marked
as work-in-progress
14. I support Adrian Farrel's portion of the DISCUSS about [FE-PROTO] needing to
be a normative reference.
Section 6. IANA considerations
The proposed and individual registered ports seems to be in conflict with
registration policy. Although RFC 4960 doesn't say so explicitly from below
quotes it can be inferred that SCTP ports should not be registered on port
numbers that for other protocols already are in use, due to existing TCP, DCCP
or UDP applications interest in using SCTP in the future.
RFC 4960 says:
o A port name registered for TCP MAY be registered for SCTP as well.
Any such registration SHOULD use the same port number as the
existing TCP registration.
o Concrete intent to use a port SHOULD precede port registration.
For example, existing TCP ports SHOULD NOT be registered in
advance of any intent to use those ports for SCTP.
I think we should avoid creating these potential conflicts on ports 6701 and
6702. I would suggest that IANA revoke the current SCTP registrations on port
6700, 6701 and 6702 and assign new ports to SCTP ML.
draft-ietf-mipshop-pfmipv6
Updated for draft-ietf-mipshop-pfmipv6-09.txt; as far as I can tell, few, if
any, of my DISCUSS points have been addressed in the -09 rev.
-----
I'm not at all sure I could implement an interoperable protocol from this
document. The only description of message transmission and processing is in
Section 4. There appear to be only general descriptions of message flows and
operations in section 4. Is this document defining extensions to RFC 5568? If
so, there should be an explicit description of what is the same and what is
updated.
This document introduces a formal definition for "access network", spec., P-AN
and N-AN, that doesn't seem to appear in RFC 5213. There are references to an
"access network" in RFC 5213, but those references seem to imply a passive link;
in this document, the P-AN and N-AN include L2 devices that apparently can send
and receive messages as shown, e.g., in figure 2.
Is there some other document in which the access nodes are given this more
active definition? Access nodes don't appear in RFC 5568, either.
Related: this sentence seems like a handwave:
(b) The previous access network (P-AN), to which the MN is currently
attached, indicates the handover of the MN to the PAR (PMAG).
Detailed definition and specification of this message are
outside the scope of this document.
Why is the AN involved at all? RFC 5213 assigns all of this detection
responsibility directly to the MAG.
=====
How does the PAR know the NAR in predictive handover? (4.1)
(c) The PAR sends the HI to the NAR. The HI message MUST have the P
flag set and include the MN ID, the HNP, the MN IID and the
address of
the LMA that is currently serving the MN.
=====
In reactive handover, if the MN
does nor provide the old AP-ID to the NAR, how does the NAR determine the PAR?
(a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID
on the old link may be provided by the MN to help identify the
PMAG on the new link.
BTW, even though PAR/PMAG and NAR/NMAG are interchangeable throughout the doc,
it would be good to choose one and stick with.
There seems to be an unstated assumption that AP-IDs can be mapped to access
routers.
The requirements for functions in the MN and the access network to support "predictive handover" should be stated. How is predictive handover better than reactive handover? It seems both require traffic buffering, either at the NAR (predictive) or the PAR (reactive).
Section 4.1., paragraph 1:
> It is hence required that all MAGs have the capability
> and enough resources to buffer packets for the MNs accommodated by
> them.
DISCUSS: How large is this buffer and at what rate is it being drained
after the tunnel is up? Sending large amounts of data at line-rate
between the PMAG and NMAG may overload the NMAG.
Section 4.1., paragraph 42:
> The encapsulation type for these user packets SHOULD follow that used
> in the tunnel between the LMA and MAG (IPv6-in-IPv6 as specified in
> [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
> [IPv4PMIPv6], TLV-header UDP tunneling as specified in [GREKEY] or
> any new method defined in the future).
DISCUSS: [IPv4PMIPv6] and [GREKEY] need to be normative references. I
also don't think that we can simply allow any possible future
tunneling mechanism here. IMO this should become a "MUST follow either
X, Y or Z". Finally, since there are multiple options here, how does
one MAG know which scheme the other one is expecting/using?
Configuration?
I have reviewed draft-ietf-mipshop-pfmipv6-10, and have one concerns
that I'd like to discuss before recommending approval of the document:
Although version -10 is a big improvement over -09, I think the text
about "MN IID" option still needs some clarification. This option has
a very misleading name, and it's very specific to PPP (and would not
be useful on most link layers that don't use PPP).
A very rough first cut of the thing I think still need clarification:
- The option's name should probably be something like "MN Link-Local
Address IID", since for other addresses (global unicast) the MN might
use other IIDs.
- Section 6.2.3 needs an explanation about this option and its
use. Perhaps something like "In PPP, the interface identifier for the
MN's IPv6 link-local address can be assigned by the AN. In
deployments that use this configuration, this option is used to
transfer this identifier from P-AN to N-AN." (And change the
description to "The Interface Identifier used for MN's IPv6 link-local
address in the P-AN".)
- In Section 4.1, step (c) should say something like "With some link
layers, thte MN Link-Local Address IID can also be included (see
Section 6.2.3)".
- In Section 4.1, step (h), suggest rephrasing: "..., the NMAG SHOULD
confirm that the same interface identifier is used for the MN's
link-local address (this is transferred from PMAG using the MN-LLA-IID
option at step (c), and sent to the MN during the
Configure-Request/Ack exchange)"
- In Section 4.1, rephrase the text that talks about neighbor cache
entries (below the itemized list) -- at this point, the MAG can create
a neighbor cache entry for the Link-Local address, and just add
"routes" (or similar) for the whole HNP (since this is a
point-to-point link, and MN owns the whole HNP, it's not necessary to
create individual neighbor cache entries for every address (from HNP)
that the MN uses -- that could be hundreds of entries per MN.
In the Gen-ART Review by Francis Dupont on 2009-09-22, Francis said:
"incredible painful to read (obviously a candidate for "how an RFC
should not be" :-)."
A revised draft was produced in response to this comment; however, it
has not been posted yet. What is the plan?
4. Proxy-based FMIPv6 Protocol Overview This flag MUST be set in the entire document. Do you mean that this flag needs to be set in any message specified in this document? 6.2.7. IPv4 Address Option As described in Section 4.3, if the MN runs in IPv4-only mode or dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). This option is used to transfer the IPv4 home address if assigned on the previous link. The format of this option follows the IPv4 Home Address Request Option defined in [IPv4PMIPv6]. Does this need a new allocation from IANA?
In figure 2, I would suggest adding two additional lines in step l to indicate that UL and DL data now flow directly between the NMAG and LMA (i.e., that the PMAG is no longer included the the traffic flow). This is noted already in the text, but seems conspicuous by omission in the figure.
draft-ietf-l3vpn-2547bis-mcast-bgp
I understand that the many options available in this draft and the closely
related draft-ietf-l3vpn-2547bis-mcast are necessary for a variety of reasons
including technical issues and differences between various network environments.
However, these many options place interoperability at risk. This issue is being
addressed (in my opinion quite well) by "Mandatory Features in a Layer 3
Multicast BGP/MPLS VPN Solution", draft-ietf-l3vpn-mvpn-considerations. I am
placing this discuss because I believe that this latter document is necessary,
and that it would be a mistake to approve either this document or its companion
document until draft-ietf-l3vpn-mvpn-considerations is submitted for
publication.
I will move to a YES vote as soon as draft-ietf-l3vpn-mvpn-considerations is
submitted.
draft-ietf-ccamp-mpls-graceful-shutdown
I expected the document to include also information about management
considerations related to gracefull shutdown. For example sending SNMP
notifications i.e. linkDown notifications for shutdown of a TE Link, or of a
group of TE Links and some other TBD notification when a node shudown is
initiated.
draft-ietf-bmwg-ipsec-term
I have reviewed draft-ietf-bmwg-ipsec-term-12, and have couple of
concerns about the terminology. For any other document, these
would be just editorial nits, but this is a terminology document,
after all:
- The text in Section 3.1.1 and 7.4 seems to apply only to IPsec
(ESP/AH) SAs, but not IKE SAs?
- Section 3.1.2: "public key cryptography" should be "public key
encryption" (that's the term used in RFC 2409, and digital
signatures are also a form of public key cryptography).
- Section 3.1.2: I would strongly suggest avoiding the term
"nonrepudiation" -- it's so overloaded that it's hard to know what it
means (if anything). This part of the text doesn't seem very relevant
to benchmarking anyway, so it probably could be just deleted.
- Section 7.3.1: This text seems to confuse the inputs to IKE Phase 1
(information configured before Phase 1 is run), the actual Phase 1 of
the protocol, and the output of that phase (Phase 1 SA or ISAKMP/IKE
SA).
- Section 7.3.1: "SPI information" probably should be "IPsec SA
information" or something like that.
- Section 7.3.2: This text seems to confuse the Phase 2 of the IKE
protocol, and its output (IPsec SA(s)).
- Section 7.6.1/7.6.2/7.6.3/7.6.4: This text seems to conflate the
"Phase 1 initiator" and "phase 2 initiator". While it's common to have
an "IPsec client" that only acts as "Phase 1 Initiator", the client
will also act as "Phase 2 Responder", since either end can initiate
phase 2 exchanges.
- Section 7.6.1/7.7.1/7.7.3/7.13/10.4.4/10.5.1/10.5.3/and several
other sections: There's no such thing as "IKE Phase 2 SA"; these are
not IKE SAs, but IPsec SAs.
- Section 7.7.1: I found this term really confusing, especially
considering the rest of the document seems to use it also in cases
where more than one IPsec SA pair exists. For example, Section 7.13
talks about "IKE Phase 1 SA to IKE Phase 2 SA ratio" for the IPsec
tunnels -- but according to this definition, the ratio can't be
anything else than 1 (otherwise it's not an "IPsec tunnel")! And
Section 10.1.2 talks about establishing several Tunnels with a single
IKE SA, which isn't consistent with this definition.
- Section 7.8.2: The figure here is really confusing: you can't use
transport mode SAs this way...? (unless you do something like RFC
3884)
- Section 7.9.1: MD5-HMAC should be spelled "HMAC-MD5"; likewise,
"HMAC-SHA1" instead of "HMAC-SHA"; and there's no such thing as
AES-HMAC.
- Section 7.9: The text should also cover combined mode algorithms,
like CCM and GCM (or explicitly state they're not covered by
this document).
- Section 10.2.2 and 10.2.3: I'm not quite sure what "The end points
(i.e. hosts, subnets) should NOT see any fragments at ANY time. Only
on the IPsec link, fragments MAY occur." means. Is this text trying
to say that when you're doing benchmarking, the devices under test
should be configured to do post-encryption fragmentation? Or that the
endpoints generating the plaintext benchmarking fraffic should be
configured to use small enough packets that fragmentation see
fragments?
- Section 10.3.1: the terms "initiator" and "responder" don't seem
applicable here; perhaps sender/receiver?
- Section 10.4.1: the definition seems to cover only packet losses
before encryption or after decryption, but not between these two
points. Is this intentional? (it seems measuring this would be
challenging, since it the endpoints can only see how many frames were
dropped, but not where exactly)
- Section 10.8.2: it seems this should be "IPsec integrity check DoS
resiliency rate" or something -- it's not about IKE Phase 2.
- Section 10.8.3: likewise, this is not about Phase 2, so perhaps
"IPsec replay attack DoS resiliency rate"?
- Sections 3 and 7.1: It might be worth clarifying that other protocols than IKE can be used for key exchange (although benchmarking them is beyond the scope of this document) in IPsec; in IETF, we have specified at least Photuris, KINK, and HIP (and perhaps others I don't recall right now). - Sections 3, 3.1.2, 7.3: I think the text about historical origins of IKE (hybrid of ISAKMP, Oakley, SKEME) is very unlikely to be helpful to the readers (and probably mostly confusing).
I think this is a very useful document with a lot of material. The volume of
work is reflected in the number of (relatively small) discussion points that I
have.
Section 1
To appropriately define the parameters and scope of this document,
this section will give a brief overview of the IPsec standard.
Is there text missing? Should you be pointing forward to Section 3?
---
Section 2
The terminology
specified in this document is constrained to meet the requirements of
the Methodology for Benchmarking IPsec Devices documented test
methodologies.
This looks like the name of a document. Is a reference missing?
The text in the subsequent paragraphs appears to have been lifted from,
and to refer to, this other document.
---
Section 5
The use of RFC 2119 language seems eratic and maybe out of place.
You should decide whether you really want to use it, and if so, make its
use consistent.
At the very least you need to fix "WILL NOT" in section 7.7.1 as this
is not part of the RFC 2119 vocabulary.
---
Section 7.1
Since this section "defines" IPsec, it must include references to the
RFCs that define the protocol suite.
But I am not sure how this definition is intended to differ from that
in section 7.10.
---
Sections 8.1 and 8.2 include...
See Also: [...] Layer2 Clear Framesize, Layer2 Encrypted Framesize.
But these terms are not defined.
---
Sections 9.1 and 9.3
You should clarify the definition of "tunnel setup"?
One of the major issues in this type of work is comparing apples with
apples! This definition will be necessary to ensure that the metric
described in 10.5 has meaning.
Note also that in section 9.3 you have
Issues: If the TAPS increases, the TPS usually decreases, due to
burdening of the DUT with the DOS attack traffic.
This might be true of a node under some form of load, and so applies to
the maxima in section 10.5, but it does not apply to the raw definitions
in this section. Not least to note is that TAPS includes all of the
successful setup attempts so an increase in TAPS may be a direct match
for an increase in TPS.
---
Section 10.2 offers symmetry for encryption and decryption at the DUT,
but does not seem to match this for send and receive. Thus, section
10.2.1 is ambiguous about "throughput" (as is RFC 1242) with respect to
a bidirectional flow.
I think the RFC Editor will require you to remove citations from your Abstract. --- In the Abstract... This document seeks to extend these efforts specific to the IPsec paradigm. Is there any chance you could be a little more positive? --- Abstract The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. Very interesting, and completely true. But not material to include in this Abstract --- Section 2 A seperate document will be written specifically to address testing using the updated IKEv2 specification. Pedantic, but... The IKEv2 specification was not updated. Perhaps just strike "updated"? --- Section 4 The definition format utilized by this document is described in [RFC1242], Section 2. Well... Why do you then redefine the format in this section? That seems counter- productive. You should probably cut this section down to only the sentence I quoted.
The Gen-ART Review by Joel Halpern on 16-Oct-2009 raised two issues
that need to be resolved.
First, in section 3.1.1, where Security Association is introduced, the
text reads:
"An SA is a relationship between two or more entities ..."
But, section 7.4 formally defines Security Association as:
"It is a negotation agreement between two IPsec devices ..."
Is it always two? If so, please remove "or more" in section 3.1.1.
Also, is it always a negotiation agreement? Earlier text talked about
manual provisioning of Security Associations.
Second, in section 10.2, the throughput measurement is defined in terms
of packets per second. This is probably the dominant factor. However,
some implementations may well be limited by cryptographic processing,
and therefore have different packet processing performance for different
ranges of packet sizes. Section 10.2 should say something about the
assumptions or requirements relative to packet size. This seems to be
important enough that it should not be assumed that readers will
understand it from the reference to RFC 1242.
The Gen-ART Review by Joel Halpern on 16-Oct-2009 raised some editorial concerns. The document is missing the IANA considerations placeholder. There seem to be a number of references that are missing. RFC1962 is an example of the problem. The "Issue" in section 7.5 looks like a reasonable issue, but it appears to have nothing to do with selectors, the subject of 7.5. The definitions in section 7.7.3 and 7.7.4 define the terms "Established Tunnel" and "Active Tunnel" and defines them as "An IPsec device ...". The other tunnel definitions are in terms of the association. It is quite jarring to see a device referred to as a tunnel. Are these terms supposed to be Tunnel Endpoints? The definition of 7.10.1 describes the properties of AH, but does not actually say what it is. Instead of starting "Provides", it probably should start something like "A protocol header which provides". A similar comment applies to 7.10.2 on ESP.
see comments on draft-ietf-bmwg-ipsec-meth
draft-ietf-bmwg-ipsec-meth
Section 7.1.3., paragraph 1: > It is OPTIONAL to perform the tests with TCP as the L4 protocol but > in case this is considered, the TCP traffic is RECOMMENDED to be > stateful. What does "the TCP traffic is RECOMMENDED to be stateful" mean? Section 7.1.4., paragraph 1: > It is RECOMMENDED to test the scenario where IPsec protected traffic > must traverse network address translation (NAT) gateways. This is > commonly referred to as Nat-Traversal and requires UDP encapsulation. Is the idea here to have a pass/fail test or a performance - throughput/latency/etc. - test. (Because NATs vary widely in their behavior, the latter is going to be much more problematic than the former.)
I have reviewed draft-ietf-bmwg-ipsec-meth-05, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:
- Section 5/9.1/10.1/11.1: These sections suggest that the scope of
this document is limited to IPsec devices that also work as ordinary
routers, and these benchmarks can't be used with e.g. remote access
IPsec VPN gateways (that would not usually support "without IPsec"
mode at all). Is this the intent? (If it is, a short explanation in
Section 5 would be in order.)
- Section 7.6.1: This section requires testing transport mode; would
this mean IPsec devices that are specifically intended for gateway use
(and thus may not support transport mode at all) cannot be benchmarked
by this methodology?
- Section 8.2: This text doesn't seem to distinguish between
"maximum number of IPsec SAs on a device" and "maximum number of IPsec
SAs per IKE_SA/user". The methodology is clearly measuring the latter,
which could be very different from the former?
- Sections 9.3/9.4/11.2/11.3/11.4: these test methodologies talk about
counting the frames to detect packet loss -- but if fragmentation
occurs somewhere, the number of frames sent in and number of frames
coming out would be different even without packet loss?
- Section 10.3: Since the DUT will encrypt the frames, how would
the tester see the tags?
- Section 12.1: It seems this test is measuring the average duration
of one tunnel setup, but you can't calculate the tunnel setup rate
from this value? (it seems with this methodology, the DUT would be
mostly sitting idle, and nowhere near its maximum SAs-per-second
limit...) (Also applies to 12.2/12.3)
- Finally, any changes to address my comments about bmwg-ipsec-term
probably require changes in this document, too.
idnits seems to not like the way you have handled references. Although the RFC
Editor can sort this out, I think you should have a go first.
You'll also need a null IANA section. I don't see any IANA email about this I-D.
The Gen-ART Review by Sean Turner on 17-Oct-2009 suggests some editorial changes: Sec 4: s/in RFC 2119. RFC 2119/in [RFC2119]. [RFC2119] Secs 8.1-11.3: s:/Topology /Topology: Sec 8.1: s/If all packet are/If all packets are Sec 8.1: s/format should reflect/format SHOULD reflect Sec 10.1: s/Reporting Format/Reporting Format: Sec 13.1: s/(timestamp_B).The/(timestamp_B). The
I believe that publishing this document will cause more harm that good. By my count it recommends over 4000 configuration that should be tested for each test. And it misses many important configuration such as single DES. Consider a test like 11.1. This is just not practical. If someone sends me the test results for a some IPsec devices that meet all the suggestions of this draft, I might change my mind but currently I don't believe that anyone would reasonable do all these test or that this set of tests would provide the most reasonable characterization of an ipsec device. For example the idea of low rates being defined with 0 packet loss would give a very unrealistic view of performance of many devices. Publishing this will cause RFPs that ask vendors to produce this data.
I support Cullen's discuss - the number of recommended combinations seems a serious impediment to anyone actually performing the tests as specified. How many wg participants have actually completed these benchmarks? The wg and technical summaries on the ballot are silent on this point...
draft-turner-deviceowner-attribute
I would suggest that the authors re-consider this draft and try to see if it can be written to be about cert extensions, about organizations and about specific rules on what implementations need to do in order to support policy decisions regarding these attributes. Some specific comments: I agree with the issues that Pasi raised in his review. Also, the document says: The Device Owner attribute indicates the country or organization that owns the Device with which this attribute is associated. But I do not know what it means for a device to be owned by a country. I would argue that in most cases there is no such thing. Devices belong to organizations, e.g., ministry of such and such, city blaah administration, or acme corporation. And: This attribute may be used in authorization decisions. For example, a router deciding whether to connect to another router could check that the device owner present in the device's certificate is on an "approved" list. This is a pretty weak definition. First of all, it brings up interesting applications for routers that you probably did not mean? (E.g., if these certs were somehow used in BGP, we would not expect interdomain BGP to demand that it only talks to the same domain :-) Secondly, I don't know what to implement based on the above description. And: NOTE: This document does not provide LDAP equivalent schema specification as this attribute is targeted at public key certificates [RFC5280] and attribute certificates [RFC3281bis]. This is left to a future specification. I do not understand what "this" refers to in the last sentence. The application to certs? Or LDAP schema? Please be more specific.
I have reviewed draft-turner-deviceowner-attribute-02, and have a
couple of questions/concerns that I'd like to discuss before
recommending approval of the document:
- Abstract/Section 1: talking about "protocols that support ASN.1
attributes" is really vague, and unlikely to lead to any kind of
interoperability (e.g. Kerberos uses ASN.1 and has some concept of
attributes, but it doesn't look like this spec as-is would allow using
this attribute in Kerberos -- and probably that was not the intent,
either).
If the intent is PKCs and ACs, I'd suggest something like "This
attribute may be included in attribute certificates [RFC3281bis] and
in the Subject Directory Attributes extension in public key
certificates [RFC5280]" (or is it intended to be used in DNs, too?)
The document title should be slightly more specific, too.
- I was surprised to find "IMPORTS NOTHING" in the ASN.1 module -- it
seems most of the ASN.1 is generic attribute stuff which should be
imported (instead of copy-pasted) from somewhere?
- Why have three different ways (2-latter, 3-letter, numeric) of
representing exactly the same information? This seems unlikely to
promote interoperability (e.g. if the information is an integer, we
don't usually allow both little-endian, big-endian, and
"middle-endian" encodings, but just pick one of them...)
- Why three separate entries for 3166-2 codes, instead of SIZE(4..6)?
- The concept of "ownership" may vary from one legal system to
another, but IMHO it's more typical to say that a device is owned by
by a legal person (e.g. "Ministry of Justice, Finland" or "IETF Trust,
Virginia, USA") than by a country (which would usually have
thousands/millions of different organizations).
When you use the 3166 codes in the device owner attribute, is it
intended to specify just the nationality of the organization (e.g.
"US" for IETF Trust, "FI" for "Ministry of Justice, Finland"), or is
it intended to imply that the organization is somehow part of "the
government"? (which is obviously a very fuzzy definition if you have
federal, state, municipal levels, different branches, government-owned
companies, etc.)
I'm wondering why you did not just use a domain name for the owner? So the owner could be cisco.com or something like that.
This is the one of the issues on Pasi's list:
DeviceOwner ::= CHOICE {
alpha2Country [0] PrintableString ( SIZE (2) ),
-- ISO 3166-1 2 Letter Codes (aka diagram).
alpha3Country [1] PrintableString ( SIZE (3) ),
-- ISO 3166-1 3 Letter Codes (aka trigram).
alpha4Country [2] PrintableString ( SIZE (4) ),
-- ISO 3166-2 4 Letter Codes (ISO 3166-1 diagram and a hyphen
-- followed by one alpha or numeric code).
alpha5Country [3] PrintableString ( SIZE (5) ),
-- ISO 3166-2 5 Letter Codes (ISO 3166-1 diagram and a hyphen
-- followed by two alpha or numeric codes).
alpha6Country [4] PrintableString ( SIZE (6) ),
-- ISO 3166-2 6 Letter Codes (ISO 3166-1 diagram and a hyphen
-- followed by three alpha or numeric codes).
numericCountry INTEGER (0..999),
-- ISO 3166-1 3 Digit Codes.
group OBJECT IDENTIFIER
}
Having both 2 letter country codes, 3 letter country codes
(some of which
correspond to 2 letter country codes) and numeric country
codes doesn't help
interoperability. If you look at LTRU WG document,
you can see that there is a
single registry that avoids multiple representations of the same thing.
My recommendation is to either remove everything but 1 choice for country codes
(using 3 letter country codes seems to be the best), or add more text clarifying
which choice is going to be used in which case and how interoperability is to be
achieved.
1. I support two of the points raised by Pasi's DISCUSS: the concept of 'ownership' needs clarification and especially what meas for a device to be 'owned' by a country, and having multiple ways of identifying country codes may lead to interoperability problems 2. Normative reference [X.680] is to the 2002 edition of the ITU-T recommendation which is seperseded by the 2008 edition. We should discuss whether such reference (which is the equivalent to a downref to an obsolete RFC) is OK. I did not enter a DISCUSS as I have already entered one for a different document, but we probably need a common approach.
draft-turner-clearancesponsor-attribute
Some of the same comments apply here as in the other draft-turner. In addition, the document seems to lack a definition of a "sponsor". When I followed the references I understood what was meant by "clearance". But it is still unclear what a sponsor is. Is this an entity that performed the clearance evaluation, or the entity that paid for it? Also, I support Cullen's comments on DirectoryString and its length. My main issue with DirectoryString is that I have no idea what I should be putting to the sponsor attribute. If I put in "NSA", will it help me get through access controls at some place? :-)
I have reviewed draft-turner-clearancesponsor-attribute-02, and have a
couple of questions/concerns that I'd like to discuss before
recommending approval of the document:
- 32 characters seems an awfully short limit for the maximum length.
For example, "National Institute of Standards and Technology" is
46 characters, and presumably, that's not the only agency with
a long name...
- Is the intent that the clearance sponsor name is scoped by the
certificate issuer? Or in other words, could one certificate issuer
use e.g. "DSAC" to mean "Defence Scientific Advisory Council" (UK),
and another "Domestic Security Alliance Council" (in US)?
(If this is the intent, it probably needs some explanation
about how to process these...)
- Same as deviceowner-attribute: the ASN.1 module should probably
import everything on page 6.
I don't understand what goes in the directory string or how a machine is going
to do anything with it. Why is it so short? I'm not asking for a change to the
drat - I'm just confused. If you can clear this up with an email to me, I can
easily imagine clearing this discuss with no change to draft.
Abstract This document defines the clearance sponsor attribute. This attribute may be included in locations or protocols that support X.500 attributes. "Protocols"? 2. Clearance Sponsor The clearance sponsor attribute indicates the sponsor of the clearance of the subject with which this attribute is associated. This attribute is only meaningful if the clearance attribute [RFC3281bis] is also present. The clearance sponsor attribute is a DirectoryString [RFC5280], which MUST use the UTF8String CHOICE, string with a minimum size of 1 characters and a maximum of 32 characters. Did you mean Unicode characters or octets? 3. Security Considerations If this attribute is used as part of an authorization process, the procedures employed by the entity that assigns each value Did you mean clearance values? must ensure that the correct value is applied.
1. I support Pasi's part of the DISCUSS about 32 lenght strings being too short for proper identification of organizations, and Jari's COMMENT about lack of definition of the term 'sponsor'. 2. Same comment as with the other turner draft about the normative reference to superseded version of the X.680 Recommendation
draft-carpenter-renum-needs-work
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.
The document says:
It would also be possible to use ULAs for all
on-site network management purposes, by assigning ULAs to all
devices. This would make these on-site activities immune to
renumbering of the prefix(es) used for off-site communication.
My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.
The document says:
The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
This is specifically unicast-only; a DHCP client must discard a
multicast FORCERENEW. This could nevertheless be used to trigger the
renumbering process, with the DHCP server cycling through all its
clients issuing a FORCERENEW to each one. DHCPv6 has a similar
feature, i.e., a unicast RECONFIGURE message, that can be sent to
each host to inform it to check its DHCPv6 server for an update.
These two features do not appear to be widely used for bulk
renumbering purposes.
The FORCERENEW RFC says that DHCP authentication is a MUST, and as we
know, DHCP authentication has not been deployed in any wide scale
and perhaps not even in any single network. As a result, it is very
unrealistic to assume that FORCERENEW as currently defined would be
helpful here. Perhaps the somewhat positive assessment above should
somehow take this into account.
Section 2.6. talks about SLP. It is unclear to me what the real significance of this is, how widely has it been deployed? AFAICT, what has been deployed is DHCP based discovery of certain key services. The document says: Until this ambiguous behaviour is clearly resolved by the IETF, operational problems are to be expected, since different host operating systems have taken different approaches. This makes it difficult or impossible for a site network manager to configure routers and DHCPv6 servers in such a way that all hosts boot in a consistent way. If one operating system starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, and yet another uses SLAAC even if the M bit is set, systematic address management becomes impossible. You present this in a light where there's a problem and that it will eventually be solved. I think that is a little bit too optimistic. I think the reality is that since the different interpretations got into implementations from day one, it has been very hard to come to any conclusion about the desired changes in the IETF specifications. More fundamentally, the change in the IETF specifications no longer solves this problem, as the code is already out there. That is, when stateful address allocation is used, IPv6 does not guarantee full uniformity on host behavior. However, I do not see this as a fundamental problem -- you just have to deal with it. Also, what does all this have to do with the topic of the document? The document says: In contrast, SCTP already supports dynamic multi-homing of session end-points, so SCTP sessions ought not be adversely impacted by renumbering the SCTP session end-points [RFC4960], [RFC5061]. Yeah. And this has no relevance for the topic at hand. The point is that there are protocols that are bound to IP addresses, and as long as there exists protocols like this then a change of an IP address is going to disruption sessions. Not that this matters, IMHO, because in IPv6 a sudden change is not what is recommended. For IPv4 that is of course all we have.
Toward the end of section 5.1.1, this text:
and yet another uses SLAAC even if the M bit is set, systematic
address management becomes impossible.
is somewhat misleading. The use of SLAAC is entirely independent of the M bit;
SLAAC is controlled by the A bit associated with each prefix in its PIO.
Regarding the discussion of M/O bits, SLAAC and consistent address assignment, I
agree that the current state of the definition and semantics of the M and O bit
are problematic. In fact, some OSes (e.g., Linux-based OSes) don't have an API
to make the M/O bits accessible to a user-level DHCPv6 client. As a practical
matter, it is relatively easy to have all the hosts on a link use either SLAAC
or DHCPv6:
* for SLAAC, configure the A-bit 'on' in the PIO for any prefixes and don't
configure any DHCPv6 service for address assignment; any hosts that try to use
DHCPv6 for address assignment will fail while still obtaining any other
configuration information through DHCPv6
* for DHCPv6, don't enable the A-bit in
any PIOs and enable the M/O bits; hosts won't use SLAAC and will start DHCPv6
whether or not they respsect the M/O bits
The authors might consider adding text to section 3, referencing draft-ietf- v6ops-ipv6-cpe-router-02, explaining the use of DHCPv6 to assign an IPv6 address to the SP-facing interface of an IGD. Also under discussion for inclusion in draft-ietf-v6ops-ipv6-cpe-router-02 is the use of the default router information from a RA received from a SP edge router to establish a default route in the IGD forwarding table. --- Toward the end of section 5.1.1: Neither the SLAAC approach, nor DHCP without pre-registered MAC addresses, will work reliably in all cases of systems that are assigned fixed IP addresses for practical reasons. For example, servers that that need a fixed IP address and for which the network admin doesn't want a dependency on the DHCP service? --- In section 5.3.4, the 6net project deliverables D3.6.1 and D3.6.2 might be cited as providing relevant experience in managing a renumbering event. If I recall correctly, it was reported in one of those deliverables that coordinating the renumbering processes across admin domains, and the blocking that happens when another admin domain doesn't follow through, caused the greatest delay int he renumbering process. --- In section 6.3: A DHCPv6 extension has been proposed which could convey alternative routes, in addition to the default router address, to IPv6 hosts [I-D.dec-dhcpv6-route-option]. This might be extended as a way of informing hosts dynamically of prefix changes. Other DHCP options are also on the table that may offer information about address prefixes and routing to DHCP or DHCPv6 clients, such as [I-D.ietf-dhc-subnet-alloc] and [I-D.sun-mif-route-config-dhcp6]. it's not at all clear to me from this text how the cited DHCP options have anything to do with renumbering. --- Section 7.3 - what does DNSsec have to do with renumbering? --- Also in section 7.3: traffic monitoring, either with a traffic analyzer or a specialty tool like NDPmon, can be a very useful tool to confirm that renumbering has completed successfully or that some traffic is still using the old prefixes
Minor semi-editorial nits: - Section 2.5: I think "MS Exchange" is the email server product; DNS and DHCP come with "Windows Server". - Section 2.5: the last paragraph seems largely unrelated to renumbering. - Section 6.3: s/DNSOPS WG/DNSOP WG/ - Section 6.3: It looks like NSCP is an individual draft, not something DNSOP WG is working on yet.
I'm happy to see this draft published as is, but I would be happier if: 1) when discussing how UDP and TCP sessions fail, point out that many applications today deal with this already at the application layer. If you are running an application and you switch from a wired interface to wireless interface, this looks exactly like a renumbering to the application. Any decent IM client, softphone, or web application (such as facebook, gmail) will just deal with it and from the users point of view nothing broke and the application just kept working as the renumber happened. 2) Although there are multiple ways to update a DNS record in a secure way, the most prevalent by far is dyn-dns. This is widely supported in most home gateways today.
draft-melnikov-sasl-scram-ldap
I know this was discussed in e-mail. My DISCUSS is a placeholder until
"[[anchor2: Add an example.]]" is fixed.
Why the two step process?
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
sasl@ietf.org mailing list.
+1 for Ralph and Russ's discuss issues
draft-nsri-aria
Sorry to be dense, but does the expression in
2.2. Key Scheduling Part
Let K denote a master key of 128, 192 or 256 bits. Given the master
key K, we first define 128-bit values KL and KR as follows.
KL || KR = K || 0 ... 0,
mean that KL is set to the leftmost 128 bits of K and KR is set to the remaining
bits of K (if any), right-padded with zeroes to for a 128 long bitstring?
draft-levy-sip-diversion
Could we get the RFC editor and authors to agree to put the IESG note
to the body of the document, in which case no note would be needed?
The file header says: Inended status: Historic and you meant "Intended status", of course.
Current IESG note says: This RFC contains an early alternate proposal that was not chosen by the SIP working group when creating the solution specified in RFC 4244 "An Extension to the Session Initiation Protocol (SIP) for Request History Information". I suggest some edits: This document contains an early proposal to the IETF SIP Working Group that was not chosen; the solution that was chosen can be found in RFC 4244 "An Extension to the Session Initiation Protocol (SIP) for Request History Information".
I think we need to talk about this one a bunch. The IESG note about 4244 does
not seem right quite right - 3325 was the primary work that came out of this
thought I agree that later 4244 also covers this.
Let me provide a bit of background. Cisco was doing work with cable labs and
came up with something close to this draft. Cisco then submitted it to the IETF
and in the mean time Cisco implemented it their gateways. The draft was very
controversial at IETF for a variety of reasons largely technical. In the
meantime, if you wanted call-id to work (which everyone did want) and you were
using cisco gateways (which had the bulk of the market share at that time) you
pretty much needed to do this to work. So lots of vendors implemented. As the
discussion continued at IETF, effectively 3325 was formed by taking the parts of
this draft that people could agree on and adding a security section that we
could sneak past the IESG on some sort of bogus private used in walled gardens
pretext. As you can imagine that pretext turned out to be a disaster in the long
run. After 3325 was published, many people felt folks that had done the pre
standard implementation of this draft should migrate to 33245 and we would have
interoperability - many did migrate and some did not. Later 4244 added in more
functionality that 3325 did not have and had been in this draft. The IETF also
defined 4474 for call-id which is the only solutions of these that is usable on
the internet. (as a side note I am author of some of the text in this draft,
3325, 4244, and 4474). At this point in time, the sheer number of different
solutions to the caller-id problem is a significant interoperability problem.
The IETF is working on a 4244bis draft as a WG item and discussing work on
calling and called part id in WG meetings. My understanding of Cisco position on
this topic is that thought Cisco is still the primary user of this approach,
Cisco does not believe it would be helpful to the internet, or even Cisco, to
publish this even as an historic RFC. It has generated much discussion for many
years inside Cisco. People from multiple other vendors, such as Microsoft, have
strongly suggested that this draft should be updated with a version of this
draft roughly says whatever you do don't use this - go do what the IETF
standards track recommends. I'd like to note that the reason the author sent
this is to the RFC Ed is that Joel Halpern asked him to submit it and somehow
between Steve and Joel, Steve was under the impression that Joel was the Chair
of the IETF so did it.
I also note this draft has changed the syntax from earlier version that were
widely implemented so I'm not sure how much it does reflect the historic code
base. The draft is in pretty sad state and I wonder at things like two of the
original authors being removed and the spelling mistakes that are hard to
imagine anyone other than me making - my favorite being "Inended status".
In summary, I believe publishing an RFC that is an alternative to the standards
track RFCs for the caller-id problem is harmful to interoperability and this
should not be published.
draft-mavrogiannopoulos-rfc5081bis