Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla e...@rtfm.com wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have been reused
for other purposes already:
No, I'm not forgetting that. That doesn't change the fact that the
computation is
a MAC.
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?
For me the ciphersuites defined in TLS should have a uniform
security level. I.E. why use AES-256 with security level of 2^256
but use a MAC for a handshake of 2^96 bits?
regards,
Nikos
[0]. http://www.ecrypt.eu.org/documents/D.SPA.13.pdf
[1]. For an HMAC the square root of
the internal state of the hash algorithm is also affecting the
security level.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
test, please ignore
___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
A preliminary research question: The existence of a tool to monitor a Home Agent.
Dear participants of the Ietf mailing list, I am a student doing research for my dissertation. In part of that research I am looking for monitoring tools, specifically implemented for the Home Agent. (MIB RFC 2006) Or the Mobile IP suite. So far I have only found general tools, as the HP NNMi, Nagios, OpenNMS, Cacti, Munin, NetMRG. And a framework for massive SNMP polling named Torrus. HP NNMi has in theory support for logging MIB RFC 2006 since it is able to load in MIBs and monitor specified OIDs. And I know many of the open source tools as Nagios, Cacti, Munin, and NetMRG, are able to extend their functionality through plug-ins or through configuration. So they should be able to monitor the Home Agent through the support to of custom OIDs, but I have not seen anyone do this to use with the Home Agent. I have also done some research on Cisco ASA, Cisco stand alone HA, Juniper's Steel-Belted Radius Mobile IP Module, Radio-IP Roaming Gateway/Server/Client and Oracle(Sun) Solaris HA implementation. I have not yet gained access to any of the vendors' Web UI so I have been unsuccessful in determining how much their web UI display of the MIB structure in RFC 2006; the scope of what they do with the data. (Logging in graphs, etc..). My preliminary research question is: - Is there is any tools which combines the open source technologies, to specifically to monitor and display, in for example a web interface, the information from the data objects in RFC 2006? I would be grateful for any replies. Kind regards, T.S.Lura ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
Overflowing by another 32 bits is hardly the same as there was only room for -Ekr On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Eric Rescorla e...@rtfm.com writes: Can you please point to where in IP there is a limit that requires a MAC no greater than 96 bits. The AH had room for exactly 96 bits of MAC value, any more and it'd have to overflow to another 32 bits worth (the size of the non-MAC data is 96 bits and the MAC data adds the other 96 bits), see RFC 2402. The original AH used a 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it was also 192 bits long. With the expansion of the non-MAC data to 96 bits, it was necessary to truncate the MAC to keep the same overall size. Peter. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla e...@rtfm.com wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have been reused
for other purposes already:
No, I'm not forgetting that. That doesn't change the fact that the
computation is
a MAC.
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?
If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.
In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.
For me the ciphersuites defined in TLS should have a uniform
security level. I.E. why use AES-256 with security level of 2^256
but use a MAC for a handshake of 2^96 bits?
Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla e...@rtfm.com wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?
If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.
In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.
Such things should be explicit then. In any case I think there is a mistake
here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
PRF, and the AES-128 ciphersuites with SHA-256, thus there was
intention to match the security strength of the cipher with the size
of the hash.
If this wasn't the intention, then it is pretty much misleading, and should
be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
is being truncated in 96 bits. The choice for SHA-384 was because .
Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.
This depends on the threat model you have. There might be cases where
the case you describe is no problem for the adversary.
regards,
Nikos
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla e...@rtfm.com wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?
If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.
In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.
Such things should be explicit then. In any case I think there is a mistake
here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
PRF, and the AES-128 ciphersuites with SHA-256, thus there was
intention to match the security strength of the cipher with the size
of the hash.
If this wasn't the intention, then it is pretty much misleading, and should
be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
is being truncated in 96 bits. The choice for SHA-384 was because .
I'm not one of the authors of that draft, but I imagine for the usual
reason of tiling
the space of algorithms (not that I consider it a great reason.)
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Actually, this discussion has been going on for longer than so-far referenced docs show. One of my favourite RFCs on the subject: RFC 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is no, and what that answer means. On 03/06/11 21:52, Dean Willis wrote: Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
Hi Ben, More comments inline as [ON1]. :) -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 8. maaliskuuta 2011 23:14 To: Oscar Novo Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 Hi, thanks for the quick response. More comments inline. I've deleted any sections on which I think we are in agreement. On Mar 7, 2011, at 6:07 AM, Oscar Novo wrote: Hello Ben, Thanks for your comments. Answers to your comments inline. Oscar -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 5. maaliskuuta 2011 0:46 To: draft-ietf-xcon-common-data-model@tools.ietf.org Cc: General Area Review Team; The IETF Subject: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-xcon-common-data-model-23 Reviewer: Ben Campbell Review Date: 2011-03-04 IETF LC End Date: 2011-03-04 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as a proposed standard. I have a few minor comments that should be considered prior to publication. [...] Minor issues: -- section 3.3.1: XCON-URI can not be resolved to addresses and/or ports. Then why does it include a port in the ABNF? [ON] Note that URIs can not be resolved to addresses and then to ports. That's why we state it very clear in the document that this isn't the case. Besides that, an XCON-URI can be viewed as a key to access a specific conference object. So, having a direct mapping to a URL can be useful some times for some conferences. I understand that it doesn't map to a port. But I don't understand why you would include a port construction in a URI that can't map to a port. Actually, to generalize, I don't understand why one would use host either, since that construction is designed to carry addressing material, either in the form of a DNS name or an IPv4 or v6 address. What do you mean by direct mapping to a URL? Do you expect to contruct an XCON URI from, say, a SIP URI? [ON1] Ben, I think the XCON-URI identifier is unclear to you. I recommend you to read section 3.3 of my document. A XCON-URI identifier is created by the conference system and maintains a relationship between all the conference object identifiers in the conference. Figure 2 of my document shows an example and, in that case, the XCON-URI is a host identifier: xcon:ji0...@example.com. A XCON-URI can be anything. However, I can remove the port if it's unclear. Also, can host be an IP address? If so, does that change the comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression of zeros in an IPv6 address, etc?) [ON]I'm not an URI expert. Ted Hardie was the person in charge to review and verify the URIs of the document. For your question I would recommend you to read RFC3986 section 6.1. 3986 says string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. My point is that if you are really using the host and port constructions, they need some of those additional rules. Certainly, 2 host:port constructions that match character for character are equivilent--but there's a number of ways host:port can be equivalent when it _doesn't_ match character for character. And that's not even counting aliasing--I'm talking about strict syntactic equivalence. Wouldn't it better to just use some sort of string contruction (perhaps unreserved) that would allow you to put something in it that looks like host:port, but without the meaning usually associated with those? Was this concern discussed in Ted's review? If so, do you have a pointer to it? [ON1] From RFC3986 section 6.1: comparison methods are designed to minimize false negatives while strictly avoiding false positives. Ted's agreed on the text mention in the document. He's an URI expert. -- 4.6.2, 1st paragraph: Are two users with the same signaling protocol allowed to have different authn mechanisms? [ON] Answering that question is out of the scope of this document. The Conference Control Protocol and/or RFC5239 (for instance section 11.1) should answer this question. My question is whether the data model allows it. Why wouldn't that be in scope? [ON1] From section 4.6.2 of the document: Since a variety of signaling protocols are possible, a variety of authentication mechanism - determined by every individual conference servers - may need to be mapped from the different protocols. The specific types of authentication mechanism are beyond the scope of this document. I'm concerned that user-admission-policy is a child of users, not user,
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On 03/08/2011 09:59 AM, Martin Rex wrote: To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like unreasonable cutdown of the security margin for the Finished messages. I agree. Last I looked into it, I came to the conclusion that collisions of any efficient 96 bit hash function are likely within range of today's supercomputers and botnets. But the logistics of it probably make it impractical for an actual attack. You need the master secret to manipulate the verify_data in any valid way (and if the attacker had that there'd be no security left to attack anyway). Otherwise, a useful attack on the finished message probably has to involve 2^48 or so live network connections to collide among. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On 03/08/2011 11:33 AM, Eric Rescorla wrote: On Tue, Mar 8, 2011 at 9:20 AM, Martin Rexm...@sap.com wrote: Eric Rescorla wrote: I don't understand this reasoning. Why does the output size of the pre-truncated PRF influence the desirable length of the verify_data (provided that the output size is than the length of the verify_data of course). One of the purposes of a cryptographic hash function is to protect from collisions (both random and fabricated collisions). As I mentioned, that appears not to be the case here, but I have found no written rationale for this design subtlety. I could be missing something. It's also possible that some cipher suite or mode could be added in the future that makes a collision on the verify_data significant. Cutting down the SHA-384 output from 48 to 12 octets significantly impairs its ability to protect from collisions. It's comparable to truncating the SHA-1 output from 20 to 5 octets. I think it's more comparable truncating SHA-1 down to 12 octets. I don't understand this analysis. Consider two ideal PRFs: * R-160 with a 160-bit output * R-256 with a 256-bit output Now, consider the function R-256-Reduced, which takes the first 160 bits of R-256. Are you arguing that R-256-Reduced is weaker than R-160? If so, why? I think he's arguing that anything cut down to 96 bits represents a lousy hash function allowing practical collisions on today's hardware. The implication for TLS protocol evolution (and anything else interpreting bytes-on-the-wire) is to keep in mind that the Finished.verify_data is simply not designed to resist offline collision attacks. Remember to bring this up the next time somebody suggests permitting endpoints to use lousy RNGs, particularly in conjunction with certificates with fixed DH parameters. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
On 03/08/2011 12:45 PM, Martin Rex wrote: RFC-5746 TLS extension Renegotiation indication Yes, it would be bad if those could be collided. I'm sorry, but I think it is a bad idea to use a flawed design for the TLS finished message by subverting the collision resistence of stronger secure hash functions that are used for the PRF. Here's how my reasoning goes. I could be wrong. The Finished.verify_data represents a 96-bit MAC, not a general-purpose cryptographic hash function. The attacker is presumed to have the ability to modify data at some points in the protocol stream. The protocol relies on correct validiation of the verify_data to detect this condition and abort. Master_secret is not known to the attacker, if the connection is properly authenticated. The authentication only depends on the verify_data to prevent downgrade attacks. But if the authentication is broken, the attacker can simply issue the proper MAC and has no need to collide them. Master_secret is very long, changes every full handshake, and is required to compute the MAC. Any offline precomputation the attacker could do in support of collision finding requires the ability to compute the MAC function for the actual master_secret (as computed by the client or the server including locally-generated entropy not received from the attacker). Therefore, collisions on the Finshed.verify_data require active sessions to be useful and the attacker will need to amass a pool of about 2^48 of them to collide between. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-hoffman-rfc3536bis-00 (Terminology Used in Internationalization in the IETF)
I suggest that the draft include a definition of the term writing system. Peter Daniels' explanation of what a writing system is in The World's Writing Systems is probably too detailed (not to mention arcane); but given the importance of the term (which is used 7 times in the draft), its meaning should be formally established. - Lyman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-kanno-tls-camellia-00.txt (Additionx
Martin Rex m...@sap.com writes: Truncating the PRF output to 12 octets for TLSv1.2 seems like an error. It's not an error, it's IPsec cargo cult design. OK, using cargo cult design for a security protocol probably rates as an error, but the choice of exactly 96 bits was deliberate rather than the full size was deliberate. Peter. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
On Mar 9, 2011, at 6:01 AM, Oscar Novo wrote: Hi Ben, More comments inline as [ON1]. :) -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 8. maaliskuuta 2011 23:14 To: Oscar Novo Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 Hi, thanks for the quick response. More comments inline. I've deleted any sections on which I think we are in agreement. On Mar 7, 2011, at 6:07 AM, Oscar Novo wrote: Hello Ben, Thanks for your comments. Answers to your comments inline. Oscar -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 5. maaliskuuta 2011 0:46 To: draft-ietf-xcon-common-data-model@tools.ietf.org Cc: General Area Review Team; The IETF Subject: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-xcon-common-data-model-23 Reviewer: Ben Campbell Review Date: 2011-03-04 IETF LC End Date: 2011-03-04 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as a proposed standard. I have a few minor comments that should be considered prior to publication. [...] Minor issues: -- section 3.3.1: XCON-URI can not be resolved to addresses and/or ports. Then why does it include a port in the ABNF? [ON] Note that URIs can not be resolved to addresses and then to ports. That's why we state it very clear in the document that this isn't the case. Besides that, an XCON-URI can be viewed as a key to access a specific conference object. So, having a direct mapping to a URL can be useful some times for some conferences. I understand that it doesn't map to a port. But I don't understand why you would include a port construction in a URI that can't map to a port. Actually, to generalize, I don't understand why one would use host either, since that construction is designed to carry addressing material, either in the form of a DNS name or an IPv4 or v6 address. What do you mean by direct mapping to a URL? Do you expect to contruct an XCON URI from, say, a SIP URI? [ON1] Ben, I think the XCON-URI identifier is unclear to you. I recommend you to read section 3.3 of my document. A XCON-URI identifier is created by the conference system and maintains a relationship between all the conference object identifiers in the conference. Figure 2 of my document shows an example and, in that case, the XCON-URI is a host identifier: xcon:ji0...@example.com. A XCON-URI can be anything. However, I can remove the port if it's unclear. I think it would be best to remove port unless you have a concrete reason to include it. I assume there must have been one at one time, but it's not apparent to me from the text, or the discussion so far. Also, can host be an IP address? If so, does that change the comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression of zeros in an IPv6 address, etc?) [ON]I'm not an URI expert. Ted Hardie was the person in charge to review and verify the URIs of the document. For your question I would recommend you to read RFC3986 section 6.1. 3986 says string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. My point is that if you are really using the host and port constructions, they need some of those additional rules. Certainly, 2 host:port constructions that match character for character are equivilent--but there's a number of ways host:port can be equivalent when it _doesn't_ match character for character. And that's not even counting aliasing--I'm talking about strict syntactic equivalence. Wouldn't it better to just use some sort of string contruction (perhaps unreserved) that would allow you to put something in it that looks like host:port, but without the meaning usually associated with those? Was this concern discussed in Ted's review? If so, do you have a pointer to it? [ON1] From RFC3986 section 6.1: comparison methods are designed to minimize false negatives while strictly avoiding false positives. 3986 does not mandate that all URI schemes use a character by character comparison. It lists that as a minimum choice. It also suggests that each scheme will have it's own additional rules. My issue with host is that there's a lot of implied baggage there. Host can be an literal IP address (IPv6, IPv4, IPvFuture, a name, etc.) For some of these, a character comparison may not yield the results that an implementor would intuitively expect. Host can include internationalized domain names--and that _really_ throws
[Gen-art] review: draft-ietf-netext-pmip6-lr-ps-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netext-pmip6-lr-ps-05 PMIPv6 Localized Routing Problem Statement Reviewer: Joel M. Halpern Review Date: 7-March-2011 IETF LC End Date: 14-March-2011 IESG Telechat date: 17-March-2011 Summary: This document is close to ready for publication as an Informational RFC. Moderate issues: The abstract is misleading. It reads as if the problem is allowing communication between a PMIP mobile node and a correspondent, wherever the correspondent is. Even the introduction is somewhat hazy on its scope, sometimes referring to the generalized notion of correspondent node, and sometimes seeming to mean just the sub-case of two nodes, both attached to MAGs, in the same domain. It is only in the conventions and terminology that Localized Routing is actually defined in a way to make clear what problem is of interest. Minor issues: In the introduction, the word problem space is used to describe what is being covered in this document. However, the document includes sections such as section 4, Functional Requirements for Localized Routing which are not about the problem, but rather about what mechanisms are needed for a solution. Rather than argue about what belongs in this document, or the document name, I would suggest clarifying in the introduction what this document is actually doing. While the arguments at the end of section 3.1 sound plausible, they are, as far as I can tell, quite controversial in the mobile industry. I have heard speakers make exactly opposite assertions about several of these claims. As such, I think this paragraph ought to be toned down. I found myself confused by the text in section 5. I think that the problem is that I assume that a Local Mobility Agent will be in the same domain as the Mobile Access Gateway handling the client the LMA is supporting (otherwise it sems not to be local.) Given the discussion of Roaming, and the way it is constructed, this appears not to be the case. If there is no such domain coupling requirement, then could you please add a note to that effect somewhere early in the document (possibly in the introduction along with a better description of the problem.) Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-ancp-protocol-15
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-ancp-protocol-15
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-mrw-nat66-09.txt
Transport Directorate review of draft-mrw-nat66-09.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. I found no major issues with the document, and the document is nearly ready for publication. Below are two points you might want to consider addressing before publishing. Overall, personally, I am glad to see this draft go forward to publication. I think it is valuable, the more so because of the careful review and iteration of the algorithms that took place on the nat66 mailing list. 1) The Introduction contains a factual error: It is transport-agnostic with respect to transports that don't checksum the IP header, such as SCTP or DCCP, and to transports that use the TCP/UDP pseudo-header and checksum [RFC1071]. DCCP is not like SCTP in regard to checksum of the pseudo-header, per RFC 4340 Section 9.1: DCCP uses the TCP/IP checksum algorithm. The Checksum field in the DCCP generic header (see Section 5.1) equals the 16-bit one's complement of the one's complement sum of all 16-bit words in the DCCP header, DCCP options, a pseudoheader taken from the network- layer header, and, depending on the value of the Checksum Coverage field, some or all of the application data... The pseudoheader is calculated as for TCP. 2) There are a few impacts (or potential complications) end-to-end. As the Transport Directorate reviewer, I thought I should review carefully how NPTv6 impacts our many transport protocols. I found that that most of the transports fit into one of the two categories mentioned in the Introduction. Either (I) they don't checksum the IP header so don't care if it changes or (II) they use the RFC 1071 checksum and therefore the algorithm's adjustment works for them. OK: udp (II) dccp (II) udp-lite (II) partial checksum DCCP (II) dccp-udpencap (II) sctp (I) alc with tesla (I) norm with tesla (I) However, I'd like to mention two cases that are not addressed by I or II: 2a). RFC 5925- TCP Authentication Option - this is broken because IP addresses are used in computing a MAC. Work has begun in draft-touch-ao-nat to allow the zeroing out of the addresses but this discussion has not been completed. Suggestion: mention the RFC 5925 problem briefly in this draft. 2b). RFC 5996 -IKEv2bis - NAT traversal - I think there may be residual issues for NPTv6 with IPsec. Fred wrote (not unreasonably) on the mailing list that: ESP (Encryption or the ESP-NULL integrity check) works through this. AH doesn't. (2010-12-10) But as I read RFC 5996, NPTv6 should trigger NAT Detection even though it does not need to NAT traversal solutions defined. In the case of transport mode, NAT Detection results in checksum fixup. It seems like this implies only redundant action (as per RFC 3948 3.1.2) but it would be a good idea for someone with expertise to look at whether there is a conflict. Also, RFC 5996 calls out that: if a NAT is detected, both devices MUST use UDP encapsulation for ESP. and RFC 3948 2.1 says: the IPv4 UDP Checksum SHOULD be transmitted as a zero value which brings conflict with IPv6's prohibition of UDP checksum zero. On UDP, the authors might want to take note of this sentence from draft-ietf-6man-udpzero-02, section 1.3.4: If NAT is defined for IPv6, it should take UDP zero checksum into consideration. NPTv6 seems like it is also a novel test of the adress-agility of the SA management in IKEv2bis. Suggestion: mention that it would be valuable to test interactions of NPTv6 with various aspects of current-day IKEv2/IPsec NAT traversal. Thanks! Allison ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF 80 - Meeting Information
80th IETF Meeting Prague, Czech Republic March 27 - April 1, 2011 Host: CZ.NIC 1. Registration - Early Bird Cut-off March 18, 2011 2. NEW: Companion Program 3. Social Event 4. Visas Letters of Invitation 5. Accommodations and Transportation 6. Meeting Wiki 1. Registration - Early Bird Cut-off is March 18, 2011 Early-Bird: $650 USD, if paid in full prior to 1700 PDT March 18. Late: $800 USD if paid after Early-Bird cutoff date and time. Register online at: http://www.ietf.org/meetings/80/ 2. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 15.00 If don't want to sign up for the Companion Program and participate in the benefits, you can still join the companion email list to be in touch with other IETF companions. You can join the email list at: http://www.ietf.org/meeting/companion-program.html Benefits include: - A special welcome reception for companions from 16:30-1700 on Sunday, 27 March - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 27 March - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website at: http://www.ietf.org/meeting/companion-program.html or onsite at the meeting. 3. Social Event General information: http://www.ietf80.cz/page/851/ietf-80/ Social Event Registration: https://www.ietf.org/registration/ietf80/eventticket.py Date: Tuesday, 29 March 2011 Time: 19:00 The IETF 80 social event, hosted by CZ.NIC, will take place in the Municipal House. You will be able to survey very beautiful Art Nouveau building in the heart of Prague. As a contrast of a historical building you will be treated to a very modern performance of La Putyka. You will also have a possibility to taste variations of Czech cuisine. Additional details will be available March 16. 4. Visas Letters of Invitation: The Czech Republic has adopted the EU migration and visa policy principles and is about to complete the harmonization of its policies with the law of the European Communities. A list of countries, whose citizens need no visa to the Czech Republic, is available here: http://www.mzv.cz/jnp/en/information_for_aliens/list_of_states_whose_citizens_are_exempt/index.html For more detailed information please contact the diplomatic mission of the relevant country - their list sorted in the alphabetical order is available at: http://www.mzv.cz/jnp/en/information_for_aliens/local_competency_of_dm_in_processing/index.html 5. Accommodations and Transportation Reservations Cut off Date: 9 March 2011 (Hilton), 11 March 2011 (Sheraton and InterContinental). For additional information on rates and policies, please visit: http://www.ietf.org/meeting/80/hotel.html 6. Meeting Wiki The IETF 80 meeting wiki (Your Wiki) has been created for the attendees of IETF 80 meeting to exchange information. The wiki uses DokuWiki software and a users guide can be found at: http://www.dokuwiki.org/dokuwiki Your IETF 80 (Prague) wiki can be found here: https://www.ietf.org/registration/MeetingWiki/wiki/ietf80 and is also accessible from the Prague meeting page on the IETF website. Only 18 days until the Prague IETF! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dccp-tfrc-rtt-option-04.txt (Sender RTT Estimate Option for DCCP) to Proposed Standard
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Sender RTT Estimate Option for DCCP' draft-ietf-dccp-tfrc-rtt-option-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-03-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dccp-tfrc-rtt-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dccp-tfrc-rtt-option/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sidr-signed-object-03.txt (Signed Object Template for the Resource Public Key Infrastructure) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Signed Object Template for the Resource Public Key Infrastructure' draft-ietf-sidr-signed-object-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-03-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-signed-object/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-signed-object/ Abstract This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6172 on Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode
A new Request for Comments is now available in online RFC libraries. RFC 6172 Title: Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode Author: D. Black, D. Peterson Status: Standards Track Stream: IETF Date: March 2011 Mailbox:david.bl...@emc.com, david.peter...@brocade.com Pages: 6 Characters: 11625 Updates:RFC4172 I-D Tag:draft-ietf-storm-ifcp-ipn133-updates-03.txt URL:http://www.rfc-editor.org/rfc/rfc6172.txt Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document. This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK] This document is a product of the STORage Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
