Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
Hi, On 2011-1-18, at 20:41, Pascal Thubert (pthubert) wrote: I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. right. This is very much related to the ongoing discussion in BEHAVE about how IPv4/IPv6 translator boxes should treat IPv4 packets that come in with UDP checksum zero. If they calculate a UDP checksum for the outgoing UDP packet, they might upgrade that packet to a level of assurance that the original didn't have. I'm not sure what the current thinking in BEHAVE is, but it would make sense for this ID to follow their thinking. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. Against transmission corruption, but not necessarily against corruption during on-node processing during forwarding; think faulty RAM (yes, rare.) But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. You mean let an IPv6 UDP packet go with a zero checksum? That's at the moment not allowed by RFC2460. The 6MAN WG is discussing just this topic. Lars smime.p7s Description: S/MIME cryptographic signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
Hi Lars, On 2011-1-18, at 20:41, Pascal Thubert (pthubert) wrote: I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. right. This is very much related to the ongoing discussion in BEHAVE about how IPv4/IPv6 translator boxes should treat IPv4 packets that come in with UDP checksum zero. If they calculate a UDP checksum for the outgoing UDP packet, they might upgrade that packet to a level of assurance that the original didn't have. [Pascal] I'll copy Dan, and forward the previous mail unicast. I'm not sure what the current thinking in BEHAVE is, but it would make sense for this ID to follow their thinking. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. Against transmission corruption, but not necessarily against corruption during on-node processing during forwarding; think faulty RAM (yes, rare.) [Pascal] Well: 1) 2 bytes checksum is not exactly a great protection anyway. When I was younger, I've had a sad experience on a SNA MLTG that would hang because of the 2 bytes CRC of SDLC. 65535 out of 65536 errors would be caught. Even on T1 lines, that proved insufficient. 2) The memory error can also happen in the transmitter before checksum or on the receiver application. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. You mean let an IPv6 UDP packet go with a zero checksum? That's at the moment not allowed by RFC2460. The 6MAN WG is discussing just this topic. [Pascal] Exactly. Without that 6MAN work, we had to reform a normal UDP packet, thus the current text. But now, with the 6MAN work (on tunnels mostly as it goes), there might be an opening. How would you suggest we move forward? Lars ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art review of draft-lear-iana-timezone-database-01
Elwyn, SM, Thank you for your reviews. Here is my current thinking: 1. There was probably some confusion in that we probably meant section 5.2 and not 5.3 in RFC 5226. Nevertheless, I find RFC 5226 difficult to apply here because of the way it is worded. Specifically, it is designed for assignment purposes and not for change purposes. Hence, I've removed most references to 5226. To be clear, the TZ coordinator should be given great deference, but that in limited circumstances appeals to the IESG must be allowed (one could imagine a designated expert who went crazy and took sides in a political fight, for instance). 2. Clearly there is a need for criteria for updating the database. We're going to take a swing at that. 3. The licensing terms listed in the current draft seem to satisfy almost nobody. Therefore they have to be redone. I have asked for opinions on this very subject from one or two knowledgeable people, and hope to have a new proposal before the draft cut-off date. 4. I've accepted your minor point and your nits. Eliot On 1/13/11 2:13 AM, SM wrote: Hi Elwyn, At 09:10 12-01-11, Elwyn Davies wrote: This document is not quite ready for the IESG. The appeals process (if there is to be one) needs to clarified as it currently points indirectly to a hole in RFC 5226. As explained below, I have a feeling that it would be wise to avoid tying the processes in this document to the Designated Expert processes in RFC 5226 despite the similarities. Making it clear what does apply and what doesn't is probably more work than doing it from scratch in this document, especially given the hole in RFC 5226. [snip] I think the draft should make it explicit that it is referring to the 'Designated Expert' sections in RFC 5226 here if it continues to reference RFC 5226 - although there is a clear relationship with Designated Experts, the differences between the selection process and the operations of the TZ Coordinator and generic Deisgnated Experts may Yes, there are significant differences. According to RFC 5226: The designated expert is responsible for initiating and coordinating the appropriate review of an assignment request. It might be helpful to get some feedback from IANA and the IETF Trust on this draft before it is evaluated by the IESG. mean that citing RFC 5226 might lead to legalistic disputes about which set of rules applies. Also, I am unable to find statements in RFC 5226 backing up the sentence above. Regrettably, RFC 5226 appears effectively to have a 'dsngling reference' in this area. Section 3.2, para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses 'disputes and appeals in more detail'. However s5.2 is titled 'Updating Registrations' and says nothing about appeals and disputes. Section 7 of RFC 5226 covers appeals of IANA decisions but says nothing specific about appealing designated expert rulings. I think this area may need a little more work. Overall, my inclination would be to make this a standalone document that does not try to partially modify the RFC 5226 Designated Expert process and operations. Appeals... *sigh*. Section 7 of RFC 5226 states that: Appeals of registration decisions made by IANA can be made using the normal IETF appeals process as described in Section 6.5 of [IETF-PROCESS]. Section 4 of mentions that: In keeping with [RFC5226], the IESG selects the TZ coordinator(s). The IESG will use rough consensus of the TZ mailing list as their primary guide to further action, when it exists, and whatever other means they have at their disposal, when rough consensus cannot be found. As RFC-5226 states, the IESG is not a normal avenue for appeals of specific decisions of the coordinator, but rather a last resort when a coordinator is thought not to be functioning in an appropriate way. That could be rewritten as: The IESG selects the TZ coordinator(s). The IESG will use the rough consensus of the TZ mailing list as their primary guide for any action, when it exists, and whatever other means they have at their disposal, when rough consensus cannot be found. The IESG is not an avenue for appeals of specific decisions of the coordinator, but rather a last resort when a coordinator is thought not to be functioning in an appropriate way. An appeal can be made in such a case by using the normal IETF appeals process as described in Section 6.5 of RFC 2606. The following sentence in Section 1.1 might have to be removed then: The TZ coordinatior is a Designated Expert, as defined in [RFC5226] Regards, -sm ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen Art LC + TC review of draft-ietf-mmusic-image-attributes-10
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-mmusic-image-attributes-10 Reviewer: Avshalom Houri Review Date: 2011-01-19 IETF LC End Date: 2011-01-20 IESG Telechat date: (if known) - 2011-01-20 Summary: The document is ready as a standard track RFC. Major issues: None Minor issues: Lines 1147-1148 - Not clear that the paragraph is trying to say. Nits/editorial comments: Line 163 notice - to notice/noticing Line 833 anser - answer Line 875 cause - causes Line 940 notice - noticing Line 1115 wish - wishes Line 1119 wish - wishes Line 1144 , in order to satisfy Bob's request, - (in order to satisfy Bob's request) Line 1153 the IANA - IANA Tnx Avshalom___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
-Original Message- From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] Sent: Wednesday, January 19, 2011 1:36 AM To: Lars Eggert; Dan Wing (dwing) Cc: The IESG; david.bl...@emc.com; gen-art@ietf.org; 6lowpan- cha...@tools.ietf.org; draft-ietf-6lowpan...@tools.ietf.org Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Hi Lars, On 2011-1-18, at 20:41, Pascal Thubert (pthubert) wrote: I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. right. This is very much related to the ongoing discussion in BEHAVE about how IPv4/IPv6 translator boxes should treat IPv4 packets that come in with UDP checksum zero. If they calculate a UDP checksum for the outgoing UDP packet, they might upgrade that packet to a level of assurance that the original didn't have. [Pascal] I'll copy Dan, and forward the previous mail unicast. I'm not sure what the current thinking in BEHAVE is, but it would make sense for this ID to follow their thinking. Because 6MAN had not finished deciding exactly what it wanted to do regarding zero checksums in UDP, we sidestepped the issue as much as we could. BEHAVE allows a configuration option to (a) drop an IPv4 UDP packet without a checksum, or (b) have the translator calculate the checksum: http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-23#section-4.5 That document has finished IESG review. -d It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. Against transmission corruption, but not necessarily against corruption during on-node processing during forwarding; think faulty RAM (yes, rare.) [Pascal] Well: 1) 2 bytes checksum is not exactly a great protection anyway. When I was younger, I've had a sad experience on a SNA MLTG that would hang because of the 2 bytes CRC of SDLC. 65535 out of 65536 errors would be caught. Even on T1 lines, that proved insufficient. 2) The memory error can also happen in the transmitter before checksum or on the receiver application. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. You mean let an IPv6 UDP packet go with a zero checksum? That's at the moment not allowed by RFC2460. The 6MAN WG is discussing just this topic. [Pascal] Exactly. Without that 6MAN work, we had to reform a normal UDP packet, thus the current text. But now, with the 6MAN work (on tunnels mostly as it goes), there might be an opening. How would you suggest we move forward? Lars ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] GEN-Art review of draft-ietf-isis-layer2-09
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-isis-layer2-09 Reviewer: Kathleen Moriarty Review Date: 19 January 2011 IETF LC End Date: IESG Telechat date: (if known) Summary: The document looks pretty good overall, but there are some edits that are recommended below. Major issues: Minor issues: Nits/editorial comments: Abstract: Include name for acronym TLV and IS-IS, both are used before being defined. Include commas in the following sentence: Change from: “in this document are generic layer 2 additions and specific ones as needed are” To: “in this document are generic layer 2 additions and specific ones, as needed, are” Section 1: Paragraph 1, Line 5: Change From: Layer To: layer Paragraph 2, Line 2: Include acronym for PDU Paragraph 2, Line 3: Change from: “generic layer 2 additions and specific ones as needed are defined in” To: “generic layer 2 additions and specific ones, as needed, are defined in” Section 2: Line 1: Change from: “In this section we specify the enhancements” To either: “This section specifies the enhancements” Or: “In this section, we specify the enhancements” Line 2: Change from: “Layer-2” To: “layer 2” OR make the use of this consistent in the document. Section 2.1: Bullet 4: Make use of “Layer-2-IS-IS” consistent in the document. Paragraph 2: Note use of Level 1 and Layer 2 in this paragraph to make consistent (dash/no dash, upper or lower case “L”) Define acronym LSP in first line Section 2.2: Line 1: Change from: “Multi Topology aware” To: “Multi-Topology Aware” Bullet 5 (acronym already defined, it can be completely spelled out or use the defined acronym): Change From: “sub-TLVs: The MT aware Port Capabilities TLV” To: “sub-TLVs: The MT-PORT_CAP TLV” Last sentence: Include acronym for IIH. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen Art LC review: draft-groves-mikey-sakke-00
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-groves-mikey-sakke-00 Reviewer: Avshalom Houri Review Date: 2011-01-19 IETF LC End Date: 2011-01-18 IESG Telechat date: (if known) - Summary: The document is ready as an informational RFC document Major issues: None Minor issues: None Nits/editorial comments: Various TBD values in the document. There is no indication how these values will be determined. Line 182: is used as the TGK. TGK is mentioned here the first time with no previous explanation. Line 514: an US-ASCII - a US-ASCII Line 516: an US-ASCII - a US-ASCII Line 838 - a SSV - an SSV Tnx Avshalom ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
I think the new text is much better. I think the open question on checksum recomputation is whether there are enough MUST and MUST NOT requirements in the new text to sufficiently ensure that any recomputed checksum is computed on data that was integrity-protected via other means across the links over which the checksum was elided. If so, the result is concatenated protection, where the other means spans integrity protection of the packet across the gap created by eliding the checksum. This approach requires assurance that the integrity domains overlap - an important example is that if the other integrity check is applied in the same node that elides the UDP checksum, that node MUST be implemented so that there's no gap in the node between checking the UDP checksum and application of the other integrity check where an internal corruption would be unprotected. Rechecking the received UDP checksum after applying the other integrity check is among the ways to achieve this). Thanks, --David -Original Message- From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] Sent: Tuesday, January 18, 2011 1:42 PM To: Lars Eggert; The IESG; Black, David; gen-art@ietf.org Cc: 6lowpan-cha...@tools.ietf.org; draft-ietf-6lowpan...@tools.ietf.org Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Hi Lars and David: After the first round, the text would now look like this: 4.3.2. Compressing UDP checksum The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason [RFC4944] disallows the compression of the UDP checksum. With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum if it is authorized by the Upper Layer. The compressor MUST NOT set the C bit unless it has received such authorization. The Upper Layer MAY only provide the authorization in the following cases: Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- fieldbus by tunneling existing field protocols over UDP. If the tunneled PDU possesses its own addressing, security and integrity check, the tunneling mechanism MAY authorize to elide the UDP checksum in order to save on the encapsulation overhead. Upper Layer Message Integrity Check: In this case, there is some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength. A forwarding node MAY infer authorization from an incoming packet if the C bit is set. A forwarding node that cannot unambiguously derive such authorization MUST NOT elide the UDP checksum when performing 6LoWPAN compression. The forwarding node that expands a 6LoWPAN packet with the C bit on MUST compute the UDP checksum on behalf of the source node and place that checksum in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. If a 6LoWPAN termination is also the transport endpoint and it receives a compressed packet with the C bit set, then it MUST drop the drop the packet unless it is explicitly authorized by the Upper Layer to accept packets with a zero checksum on that UDP port. If it has such authorization then it is entitled to ignore the UDP checksum process completely. If the C bit is not set, the packet might have been forwarded by an edge router, so this is not an indication that the MIC is not present. If the terminating node knows that the message integrity will be validated by the upper layer by some state associated to the Service Access Point, it is entitled to ignore the checksum operation as if the C bit was set. I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. What do you think? Pascal http://www.xtranormal.com/watch/7011357/ -Original Message- From: Lars Eggert [mailto:lars.egg...@nokia.com] Sent: Tuesday, January 18, 2011 8:57 AM To: The IESG Cc: 6lowpan-cha...@tools.ietf.org; draft-ietf-6lowpan...@tools.ietf.org g Subject: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Lars Eggert has entered the following ballot position for draft-ietf-6lowpan-hc-13: Discuss When responding, please keep the subject line intact and reply to all email
