Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC

[Francis Dupont]

 In your previous mail you wrote:

   I think a published update to MD5 security considerations should
   clearly say what it's still fine to do with MD5, in addition to
   what it's not safe to do.  This would mean adding a couple
   sentences, and that's about all it would really take to be clear on
   the issue:
   
   "Since RFC 1321 was published, MD5 found popular use in checksuming
   large file transfers.  This use of MD5 is still reasonable, as the
   level of collision resistance is of less importance in this
   application and MD5 may be significantly more efficient than
   cryptographically stronger algorithms.  Communications, networking,
   and storage systems prone to errors (e.g. due to faulty hardware,
   drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not
   implement the known MD5 collision-finding algorithms, and MD5
   remains highly effective at detecting such errors."
   
=> you are trying to amplify the practical issue so I can't see
how it solves it (:-)...

Regards

francis.dup...@fdupont.fr

PS: BTW IMHO a dedicated function should be better than MD5 for this use,
of course to reuse MD5 is easier (and I did it too :-).
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

TSVDIR Review for draft-ietf-mpls-ip-options-05

[James M. Polk]

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.


Summary:
This is a well written, concise and needed modification to MPLS.

That said, I don't understand why the 1st minor issue below is 
present. Recommend (fairly strongly) adding the


"Document Updates: RFC 3031, RFC 3032"

as mentioned below on this first page of this RFC to be.


Transport Issues:
There are no issues


minor issues:
- S2 "Motivation", last sentence is

  "We believe that this document adds
  details that have not been fully addressed in [RFC3031] and [RFC3032]
  as well as complements [RFC3270], [RFC3443] and [RFC4950]. "

I find it surprising that this document does not formally update 3031 
and 3032, given that it is mandatory to implement, optional to 
invoke. ISTM, as an outsider to MPLS, this would in fact be the case 
given the impact of/to IP stacks not adhering to this proposed standard.


- Section 5.2 is about Router Alert Options, and states "At the time 
of this writing ...". I wonder if this subsection is valid, or needs 
another review against this IntArea ID

http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02
to still be valid in a month or two once the IntArea ID (currently in 
WGLC) is processed by the IESG and RFC-Editor?


IMO - these two docs are progressing near enough to each other to 
each consider what the other says - with or without a normative or 
informative reference in either or both docs to the other.



nits:
- I'm surprised to see the Abstract on page 2. I thought we 
collectively fixed the case in which the Abstract can be on any page 
other than page 1.


- at the page Footer, in the middle of the line, there isn't a "short 
document name" - which has been there on all previous well formed IDs 
and RFCs that I have seen (which of course is not all of them). It is 
recommended the authors pick a short form name for the subject of 
this doc for this location, such as


 LER Header Option Behaviors

- S3, 4th para, second to last sentence is:

  "First a downstream LSR may
  have not have sufficient IP routing information to forward the packet
  resulting in packet loss. "

recommend removing the first instance of "have". The sentence reads 
better without it.


- S3, 4th para, last two sentences
list a "First" and a "Second" reason correctly, but are missing 
required commas after each word (i.e., "First, ...", and "Second, ..." )


- S3, 5th para, 1st sentence is lacking commas here:

  "...FEC, yet are forwarded
  into an IP/MPLS network without being MPLS-encapsulated,
   present..."

- S5.1, last bullet has this:

  "...MPLS encapsulation at a ingress LER ..."
  ^
s/a/an

James  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 33 messages in the last 7 days.
 
script run at: Fri Dec 10 00:53:02 EST 2010
 
Messages   |  Bytes| Who
+--++--+
  9.09% |3 | 10.17% |23071 | l.w...@surrey.ac.uk
  9.09% |3 |  8.17% |18544 | m...@sap.com
  9.09% |3 |  5.86% |13294 | francis.dup...@fdupont.fr
  6.06% |2 |  5.86% |13306 | wesley.m.e...@nasa.gov
  6.06% |2 |  5.85% |13267 | turn...@ieca.com
  3.03% |1 |  8.82% |20024 | stpe...@stpeter.im
  6.06% |2 |  5.26% |11941 | martin.thom...@andrew.com
  3.03% |1 |  5.28% |11973 | b...@nostrum.com
  3.03% |1 |  5.16% |11706 | ron.even@gmail.com
  3.03% |1 |  4.92% |11163 | jeff.hod...@kingsmountain.com
  3.03% |1 |  3.89% | 8824 | s...@resistor.net
  3.03% |1 |  3.06% | 6952 | huit...@microsoft.com
  3.03% |1 |  3.03% | 6876 | jmp...@cisco.com
  3.03% |1 |  2.71% | 6156 | hartmans-i...@mit.edu
  3.03% |1 |  2.67% | 6070 | nar...@us.ibm.com
  3.03% |1 |  2.60% | 5904 | i...@adambarth.com
  3.03% |1 |  2.41% | 5462 | mcqui...@pobox.com
  3.03% |1 |  2.30% | 5215 | samirs.li...@gmail.com
  3.03% |1 |  2.19% | 4966 | m...@mnot.net
  3.03% |1 |  2.14% | 4848 | ves...@tana.it
  3.03% |1 |  2.04% | 4632 | sha...@juniper.net
  3.03% |1 |  1.90% | 4310 | g...@net-zen.net
  3.03% |1 |  1.86% | 4218 | t...@americafree.tv
  3.03% |1 |  1.85% | 4208 | jari.ar...@piuha.net
+--++--+
100.00% |   33 |100.00% |   226930 | Total
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf