Re: year for highest number of IETF participants
Indeed, the number Joe was counting was the number who filled out a
registration form. Counting those who actually paid their registration
yields closer numbers.
rbarnes$ for n in $(jot 15 73); do
att=$(curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; |
grep -o Yes | wc -l);
echo $n $att;
done
73 969
74 1170
75 1102
76 1129
77 1242
78 1159
79 1144
80 1231
81 1127
82 948
83 1395
84 1199
85 1157
86 1115
87 1435
On Tue, Oct 8, 2013 at 8:51 AM, Adrian Farrel adr...@olddog.co.uk wrote:
Curiously these numbers do not match those at
https://www.ietf.org/meeting/past.html
Registration, we may conclude, does not equate to attendance.
Adrian
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Joe
Abley
Sent: 08 October 2013 02:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/, );
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
Re: pgp signing in van
It also makes it obvious to everyone that Peter is using PGP. Which serves a pedagogical function, I guess. :) On Mon, Sep 9, 2013 at 1:12 PM, Peter Saint-Andre stpe...@stpeter.imwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/13 11:02 AM, Cyrus Daboo wrote: Hi Peter, --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre stpe...@stpeter.im wrote: But until the MUAs across the board support it out of the box, I believe most people don't know about it or know what it means. So that's an opportunity to educate people. For instance, perhaps the Internet Society might be interested in taking on that task. Is there a reason you choose to use inline signing with PGP rather than multipart/signed? Is that a technical reason (e.g., poor interoperability)? Ignorance or misconfiguration in my use of Thunderbird, it seems. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLgF/AAoJEOoGpJErxa2pnG8P/RpJj1SDr1plL3myoumgi4iS 0RLDNqq+2J+aiuDOccVJZYRITWFo3HmP3XD+nuDXiVxVUl+vuDhWHhWzQxtV04DS AUTN5mgY7Z5z2wfECFzC2MmqEG9tVD7i/gTij8cHTHyFuMvF27X32nTe/gxpo0eu 5cOhbzt2YWyF0nZff8cbQ+7o6d8RtaqE6G+jJVS4qUWeqEhYoFjjIGWieHZaNmw2 U/CQfYnAbpph/D38QDP/Tw8UJkNLXlukrbKPKtd+8Z/KAxGYkldabD01Frdkt5ZF k2PosNHHpy9Ob61SH8N/vrAO/NF4c6VYEoAk8yqCgYLLNH3BSc3fSUoGjF47VU8f PMKW/Hz9cG/1P5VhVTHNPx50b5Auuglo36pLIvlJjYzT8cZCpaCElhn4dScKLMLt //E+/EdTs6gnayBgbok31NXPWr4ORMlaff8jSinVK08COIGyCyul+9vo2/vs4WdI XZ8ToqmXUg/0d0KfRozqCQwKDHHqdkYIfTt8/rLDheXUDTTuvKWxmmLLxXs6CXMU kMQ99IaRraoAVWaEiUhIdLH3Ewj7ibFsqx9UruvUX5irqDO9SbjlJC7b41iHgUIG HBJiH3w947+mHLIXFJ2G9dBcv+CuOYVATqScu0jSDbsWE6xsqS1miNofyr1+al49 wcogO/B8kXm7cSHJjce5 =cGPH -END PGP SIGNATURE-
Re: adaptive http
Hi Faiz, Thanks for bringing your idea to the IETF. The best way to propose your idea is to write down the details in an Internet-draft. That helps make sure that everyone understands how your system works. There are some tools for writing drafts here: http://tools.ietf.org/ Once you've written your draft, submit it here: http://datatracker.ietf.org/submit/ --Richard On Thursday, June 27, 2013, Fail ul haque Zeya wrote: Hi all, I have an idea and want to share.It is about adaptive http. The protocol requests the interests and other parameters from the client and send the web page dynamically different to different users based on the interests. The intersts can be shared via XML. This is in contrast to configured html pages a different mechanism, regards faiz
Re: Renaming RFC
Cf. http://tools.ietf.org/html/rfc5513 On Thu, Jun 13, 2013 at 5:30 AM, t.p. daedu...@btconnect.com wrote: - Original Message - From: l.w...@surrey.ac.uk To: ietf@ietf.org Sent: Wednesday, June 12, 2013 10:55 PM Subject: Renaming RFC RFC should be renamed to Resulted From Comments. It's now the endpoint of the process; Request For Comments dated from when it was the start. tp Fundamentally disagree. Some SDOs produce standards as tablets of stone, and the world at large is not even allowed to read them. The IETF says this is the best we can do, can you help us make it better, by making a request for comments. For me, this is the reason why the IETF succeeds, because it looks to engage the whole world, to do yet better. Tom Petch /tp (Though RFCs through workgroups are arguably Resulted from Collaboration/Consensus/Chairing). If you're going to alter the process in any way, start here. Lloyd Wood http://sat-net.com/L.Wood/
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
I would suggest we not try to sort out on this list which sorts of Internet services are subject to American regulations. On Tue, May 28, 2013 at 2:20 PM, James Polk jmp...@cisco.com wrote: At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto: jari.ar...@piuha.net**jari.ar...@piuha.net jari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
Even for location delivery, there's not that much to say at the standards layer. For *delivery*, the story is the same as with signaling. Either the RTCWeb VoIP service can translate the location information to comply with RFC 6442, or the PSAP can just build a web app that collects it however it likes. For *determination*, it's about the browser. You can do browser-based geolocation today, to OK quality. Or the browser could implement the GEOPRIV protocols to benefit from network-provided location. All that's about implementation/deployment though. I don't really see any new standards there. --Richard On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne h...@cs.columbia.eduwrote: The most difficult part for any emergency calling system is location delivery. WebRTC probably doesn't have much impact on emergency calls if all the calls traverse a server of some kind and if the caller location can be looked up based on caller IP addresses, but once you have the end system involved in location determination (e.g., for mobile devices or for DHCP-delivered location), it has to know when a call is an emergency call as you otherwise end up providing location for every call, which is non-ideal from a privacy and battery perspective. At least in the US, many of the WebRTC services would be considered interconnected VoIP, so they are indeed subject to 911 obligations. Henning On May 26, 2013, at 3:57 PM, Richard Barnes r...@ipv.sx wrote: Indeed, there has already been some coordination between the groups, going back about a year: http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt So my read of the situation is much less dire than James's. As I understand it, the upshot of the initial coordination discussions is that there's not a single, clear RTCWEB+ECRIT story. Instead, there are a few ways you can put them together. In the short run, without upgrading PSAPs, RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP, either at the server, or at the client using something like SIP-over-WebSockets. In the long run, PSAPs can just advertise an RTCWEB service like they would advertise a SIP service today (in LoST). Neither of these is incompatible with RTCWEB or ECRIT as they're being specified today. I expect there are probably some ECRIT considerations that aren't naturally supported in RTCWEB. Things like real-time text come to mind. However, it doesn't seem to me that there's gross incompatibility. --Richard On Sat, May 25, 2013 at 10:18 AM, John C Klensin john-i...@jck.comwrote: --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko jari.ar...@piuha.net wrote: ... I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari, James will probably have a different answer and perspective, but I suggest that retrofits of security-sensitive features are so often problematic to make always not much of an exaggeration. I don't think there is any general solution to the early vs. complete tradeoff [1], nor, as long as we keep trying to deal with things as collections of disconnected pieces rather than systems, to the issues created by WGs with significant overlaps in either scope or technology. What I think we can do is to be particularly vigilant to be sure that the two WGs are tracking and frequently reviewing each other's work. At least RTCWEB and ECRIT are in the same area, which should make that coordination easier than it might be otherwise. john [1] Watch for a note about this that I've been trying to organize for about two weeks and hope to finish and post this weekend.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
Keep in mind, though, that the binary decision is usually per site. So if the PSAP is web-enabled, the user can provide location to 911.gov, and not anyone else. That seems like a solution that's more likely to deploy than something that requires the browser to distinguish emergency from non-emergency web apps. --Richard On Monday, May 27, 2013, Henning Schulzrinne wrote: Agreed - this is not so much about standards, but developer awareness. If we write any how to or similar informational documents, they should probably contain that type of discussion. There is a browser aspect, however: Right now, users only have a binary choice about location disclosure, even though I suspect many users would be fine with location disclosure for 911 only, not disclose my fine-grained location for any purpose you like. On May 27, 2013, at 1:51 PM, Richard Barnes r...@ipv.sx wrote: Even for location delivery, there's not that much to say at the standards layer. For *delivery*, the story is the same as with signaling. Either the RTCWeb VoIP service can translate the location information to comply with RFC 6442, or the PSAP can just build a web app that collects it however it likes. For *determination*, it's about the browser. You can do browser-based geolocation today, to OK quality. Or the browser could implement the GEOPRIV protocols to benefit from network-provided location. All that's about implementation/deployment though. I don't really see any new standards there. --Richard On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne h...@cs.columbia.edu wrote: The most difficult part for any emergency calling system is location delivery. WebRTC probably doesn't have much impact on emergency calls if all the calls traverse a server of some kind and if the caller location can be looked up based on caller IP addresses, but once you have the end system involved in location determination (e.g., for mobile devices or for DHCP-delivered location), it has to know when a call is an emergency call as you otherwise end up providing location for every call, which is non-ideal from a privacy and battery perspective. At least in the US, many of the WebRTC services would be considered interconnected VoIP, so they are indeed subject to 911 obligations. Henning On May 26, 2013, at 3:57 PM, Richard Barnes r...@ipv.sx wrote: Indeed, there has already been some coordination between the groups, going back about a year: http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt So my read of the situation is much less dire than James's. As I understand it, the upshot of the initial coordination discussions is that there's not a single, clear RTCWEB+ECRIT story. Instead, there are a few ways you can put them together. In the short run, without upgrading PSAPs, RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP, either at the server, or at the client using something like SIP-over-WebSockets. In the long run, PSAPs can just advertise an RTCWEB service like they would advertise a SIP service today (in LoST). Neither of these is incompatible with RTCWEB or ECRIT as they're being specified today. I expect there are probably some ECRIT considerations that aren't naturally supported in RTCWEB. Things like real-time text come to mind. However, it doesn't seem to me that there's gross incompatibility. --Richard On Sat, May 25, 2013 at 10:18 AM, John C Klensin john-i...@jck.comwrote: --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko jari.ar...@piuha.net wrote: ... I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. compl
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
Indeed, there has already been some coordination between the groups, going back about a year: http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt So my read of the situation is much less dire than James's. As I understand it, the upshot of the initial coordination discussions is that there's not a single, clear RTCWEB+ECRIT story. Instead, there are a few ways you can put them together. In the short run, without upgrading PSAPs, RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP, either at the server, or at the client using something like SIP-over-WebSockets. In the long run, PSAPs can just advertise an RTCWEB service like they would advertise a SIP service today (in LoST). Neither of these is incompatible with RTCWEB or ECRIT as they're being specified today. I expect there are probably some ECRIT considerations that aren't naturally supported in RTCWEB. Things like real-time text come to mind. However, it doesn't seem to me that there's gross incompatibility. --Richard On Sat, May 25, 2013 at 10:18 AM, John C Klensin john-i...@jck.com wrote: --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko jari.ar...@piuha.net wrote: ... I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari, James will probably have a different answer and perspective, but I suggest that retrofits of security-sensitive features are so often problematic to make always not much of an exaggeration. I don't think there is any general solution to the early vs. complete tradeoff [1], nor, as long as we keep trying to deal with things as collections of disconnected pieces rather than systems, to the issues created by WGs with significant overlaps in either scope or technology. What I think we can do is to be particularly vigilant to be sure that the two WGs are tracking and frequently reviewing each other's work. At least RTCWEB and ECRIT are in the same area, which should make that coordination easier than it might be otherwise. john [1] Watch for a note about this that I've been trying to organize for about two weeks and hope to finish and post this weekend.
Re: IETF Meeting in South America
On Fri, May 24, 2013 at 2:03 PM, joel jaeggli joe...@bogus.com wrote: On 5/24/13 10:43 AM, Doug Barton wrote: While it's unlikely that I would be able to attend, I think it's an excellent idea for reasons already better stated by others, and BA is a very nice city. The only suggestion I might add that I haven't seen mentioned yet (and pardon me if I missed it) would be to perhaps schedule the meeting to piggy back on one of the excellent regional meetings that is already well established. Arturo gave a good list, IME LACNIC and LACTLD would be the best/most obvious candidates. By running the IETF meeting either the week before, or the week after one of those meetings we would be able to get quite a bit of cross-pollination, especially with the availability of day passes. The dates for our meetings are already fixed out to november 2022. Given that I don't think there are stone tablets involved, presumably they could still be moved if there were a good reason. It's not like people have already booked plane tickets to BA. hth, Doug
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
Hi Stewart, I think this resolves my issues. Thanks, --Richard On Mon, Apr 8, 2013 at 6:53 AM, Stewart Bryant stbry...@cisco.com wrote: On 02/04/2013 15:28, Richard Barnes wrote: Thanks for following up, and for the re-send. Just to be clear, I do not mean these as blocking points. On the former point, I might just suggest a minor edit to the introduction: OLD: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing under these circumstances. NEW: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing when MPLS-TP is used in a pure Ethernet manner, without any IP forwarding capability. After various rounds of tweeking: This document specifies the options for the determination and selection of the next-hop Ethernet MAC address when MPLS-TP is used between nodes that do not have an IP dataplane. The subtly is the network may be mixed IP capable and non-IP capable. On the latter point, I can understand the desire to make the simple case simple, and the text at the end of Section 2 sends a clear warning. It does seems like GAP would also allow autoconfiguration without further NMS interaction. (Unless the NMS is configuring per-Ethernet-address policies, e.g., forward packets with this label to 00:11:22:33:44:55. Is that the case?) Yes. One case is a network that is generally NMS configured, and wants to use unicast MAC addresses, but wants to allow the craft people to plug in a new linecard without talking to the NMS. In such circumstances the only auto config would be teh MAC addresses. Stewart On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant stbry...@cisco.commailto: stbry...@cisco.com wrote: Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.**alvestrand.no/ietf/gen/art/**gen-art-FAQ.htmlhttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html http://www.alvestrand.no/**ietf/gen/art/gen-art-FAQ.htmlhttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html **). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet- addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
Thanks for following up, and for the re-send. Just to be clear, I do not mean these as blocking points. On the former point, I might just suggest a minor edit to the introduction: OLD: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing under these circumstances. NEW: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing when MPLS-TP is used in a pure Ethernet manner, without any IP forwarding capability. On the latter point, I can understand the desire to make the simple case simple, and the text at the end of Section 2 sends a clear warning. It does seems like GAP would also allow autoconfiguration without further NMS interaction. (Unless the NMS is configuring per-Ethernet-address policies, e.g., forward packets with this label to 00:11:22:33:44:55. Is that the case?) On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant stbry...@cisco.com wrote: Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet- addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch with their needs and methods of network operation. Hopefully this additional background, which I believe is well known to the MPLS-TP community to which this draft is directed, satisfies your concern on the latter point. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Diversity of IETF Leadership
IESG, with name/area: http://www.ietf.org/iesg/past-members.html IAB, with name/affiliation: http://www.iab.org/about/history/ On Wed, Mar 20, 2013 at 10:16 AM, Jorge Contreras cntre...@gmail.comwrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
I do not really think the legal angle is helpful in resolving this problem. (Which country's laws do we need to comply with?) Let's treat these legal ideas as considerations that we should be thinking about, not something where we should be striving for strict compliance. --Richard On Wed, Mar 20, 2013 at 10:27 AM, Mary Barnes mary.ietf.bar...@gmail.comwrote: On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras cntre...@gmail.com wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) [MB] I agree 100%. IETF is not at all qualified to define hiring criteria or practices. Unfortunately, they do it all the time. The model in place IMHO would not stand up to the scrutiny of any major US company's HR dept. And, of course, the HR departments are the ones responsible for ensuring the laws in a specific area are met. [/MB] While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: [IETF] Petition for We the People US Federal Government petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public.
I think you may be over-estimating the filtering power of the Internet-Draft system. On Thu, Mar 7, 2013 at 2:08 PM, Sam Crooks sam.a.cro...@gmail.com wrote: not a Joke, Warren (and IETF). The petition process is the best I have found to put in unsolicited suggestions. The RFI process and public comments are the ways to put in solicited comments on some topic. There is not a good merit-based process to put suggestions and ideas into the government, I am trying to get an effective one created. The IETF Internet Draft process is the most effective I can think of for a grassroots process to take input and kill the Internet trolls who hijack such processes.. I would appreciate your help, as well as the rest of the networking industry's help, in highlighting the issue to people in the federal government who can change it and put in an effective process. There is innovation going on in the government, and they are starting to put in place processes for innovation internally, but the government does not have an effective process for gathering ideas from the public and validating them based on merit. The Whitehouse's We the People website is a popularity contest which occasionally produces interesting things, like the recent Build the Death Star petition response from the Whitehouse. General Services Administration (GSA) is probably one of the most innovative government agencies in relation to IT. NIST and DHS NPPD and the DHS ST directorates are very innovative as well, particularly in regards to cybersecurity and information assurance. State department as well. Casey Coleman of the GSA writes a great blog on the innovation occurring in the government, and is one of the most forward looking CIOs. http://gsablogs.gsa.gov/innovation/ GSA is trying to innovate. Read this article: http://www.govexec.com/management/2013/03/hunting-great-ideas-should-be-everyday-affair-gsa-chief-says/61674/ The Whitehouse is doing some interesting things as well Hackathonshttp://www.whitehouse.gov/blog/2013/03/02/looking-back-white-house-hackathon Exposing government data sets Open Government initiativehttp://www.whitehouse.gov/open/around Data.gov Presidential Innovation Fellows programhttp://www.whitehouse.gov/innovationfellows Help me highlight a great process that works (at least considerably better than petitions) for collecting and vetting ideas from anybody on how and why something should be changed, and perhaps it will be implemented. The petition: http://wh.gov/G29p http://wh.gov/G29p Regards, Sam Crooks http://www.linkedin.com/in/samcrooks/ sam.a.cro...@gmail.com On Thu, Mar 7, 2013 at 10:22 AM, Warren Kumari war...@kumari.net wrote: 'm assuming this is a joke… but my subtlety filters are turned down, so who knows... The Internet Draft process of the IETF works so effectively at filtering out Internet trolls because of the rigor and structure required for a proposal to be submitted. W On Mar 5, 2013, at 9:55 PM, Sam Crooks sam.a.cro...@gmail.com wrote: Hi all: If you agree, please sign this petition. I'd appreciate your help in crossing the thresholds required for consideration. Regards, Sam Text of the Petition: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. I believe that the We the People initiative is a good idea, grassroots-level suggestions, but a less than ideal implementation for collection of innovation suggestions. I propose that the Federal Government implement a process and structure similar to the Internet Engineering Task Force (IETF) Internet Draft and Request For Comment (RFC) processes and organization, which has proven to be *extremely* effective at filtering the Internet trolls, which have hijacked the We the People website and at collecting and acting on valid innovation proposals from anyone with an idea. The Internet Draft process of the IETF works so effectively at filtering out Internet trolls because of the rigor and structure required for a proposal to be submitted. http://www.ietf.org; http://wh.gov/G29p https://petitions.whitehouse.gov/petition/create-request-comment-rfc-process-similar-ietfs-taking-suggestions-innovation-public/CqHFnjJc -- Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water. -- Tom Galvin, VeriSign's vice president for government relations.
Re: Time zones in IETF agenda
http://www.worldtimebuddy.com/ On Wed, Feb 27, 2013 at 8:37 AM, Victor Kuarsingh victor.kuarsi...@gmail.com wrote: On 2013-02-27 4:53 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 27/02/2013 09:28, Brian Trammell wrote: On Feb 27, 2013, at 10:20 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 26 Feb 2013, at 20:28, Martin Rex m...@sap.com wrote: I have a recurring remote participation problem with the IETF Meeting Agendas, because it specifies the time of WG meeting slots in local time (local to the IETF Meeting), but does not give the local time zone *anywhere*. I would appreciate if the local time zone indication would be added like somewhere at the top of the page, to each IETF meeting agenda. So in this interesting discussion of UTC, Martin has actually made an excellent point. Having UTC listings for the agenda would be very helpful, or an alternative agenda showing UTC. +1. Given our high remote participation, I put UTC in the agenda for the MILE WG anyway (usually correctly, even). And given that the IETF often meets on one side or another of the DST change in local time, having an unchanging time reference would be helpful even for attendees. UTC time *and* date please, for people in whichever hemisphere happens to be opposite the IETF. Brian +1. UTC (in addition to whatever local time based on venue) is the clearest way of specifying a time. It's easily converted into other time zones by those who need to do so. Regards, Victor K
Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.
Re: 答复: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
Hey Lou, That text looks fine to me! --Richard On Tue, Feb 5, 2013 at 9:24 AM, Lou Berger lber...@labn.net wrote: Dan/Richard, On 2/4/2013 10:05 PM, Lidan (Dan) wrote: Hi Richard, Thanks for the review of this draft! Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Added the original format of Config, ConfigAck and ConfigNack messages which are defined in RFC4204. I personally think it's a mistake to repeat definitions in non-bis RFCs. I think this increases the possibility of mistakes and confusion (e.g., when the text isn't copied properly or when the original document is replaced). My original thought was to propose text to follow Richard's suggestion of explicitly saying what has changed, but I see such text is there at the start of section 2: LMP Config, ConfigNack and ConfigAck messages are modified by this document to allow for the inclusion of multiple CONFIG objects. The Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204]. The ConfigAck message, which was defined without carrying any CONFIG objects in [RFC4204], is modified to enable explicit identification of negotiated configuration parameters. The inclusion of CONFIG objects in ConfigAck messages is triggered by the use of the BehaviorConfig object (defined below) in a received Config message. Richard, Is this text sufficient? Alternatively, this text can be moved to immediately proceed the BNF. Much thanks Lou (document co-author)
Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ccamp-lmp-behavior-negotiation-10 Reviewer: Richard Barnes Review Date: 2013-02-02 IETF LC End Date: 2012-01-21 IESG Telechat date: 2012-02-07 Summary: Ready, with a couple of minor questions / clarifications. Comment: Overall, this document seems very clear and readable. Thanks! The one concern I have is over the use of likely in the discussion of backward compatibility; I would like to see more precise language there. Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Section 2.2. Nodes which support - nodes that support Ordering of CONFIG objects - ... With different C-type values Section 3.1.MBZ. Might help to clarify that this means that the number of bits MUST be a multiple of 32. (I got a little confused between bits and bytes here.) Section 4. Likely Is it possible for a 4204-compliant implementation to not do one of these? If so then remove likely. If not, then why happens on the exceptional case?
Re: travel guide for the next IETF...
It gets worse if you head west to the Tampa bay... http://www.tampabay.com/news/publicsafety/crime/man-shot-at-st-pete-pizza-joint-had-been-complaining-about-slow-service/1266589 On Jan 4, 2013, at 2:55 AM, Ole Jacobsen o...@cisco.com wrote: You have been warned. http://news.yahoo.com/video/request-ketchup-philly-cheesesteak-leads-001204299.html Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo
Re: I'm struggling with 2219 language again
Anecdotal data point number N+1... As an occasional implementor of IETF specs, I have to say it's much easier to check my conformance if I can just grep for MUST and SHOULD. It's also easy for developers to get in the bad habit of ONLY doing those things that are clearly marked in that way. So ISTM that if you're not tagging things you want done with RFC 2119 language, then you're risking people not implementing them. On Jan 4, 2013, at 1:15 PM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wonderful perennial topic. :) As I always say when this comes up, when writing drafts I've settled on using the 2119 keywords only in their uppercase form, and otherwise using need to, ought to, might (etc.) to avoid all possible confusion. Sure, it's a bit stilted, but we're not writing gorgeous prose here, we're writing technical specifications that need to be completely clear. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDnHCQACgkQNL8k5A2w/vxKmwCfXKjDtMqQiPp4a0udOB8Q9IbA q9QAoNiXj2r/q4yRLp0B/13m6Xxg5YN4 =3PER -END PGP SIGNATURE-
Re: request to make the tools version of the agenda the default
On Nov 30, 2012, at 2:10 PM, Wes Hardaker wjh...@hardakers.net wrote: John C Klensin john-i...@jck.com writes: I think changing the default is fine. I'd also be reluctant to see the normal HTML version go away immediately but would be especially reluctant to see the plain text version go away or even become less accessible (require more clicks or searching to navigate too). I suspect we can all agree that this would be optimal: 1) have the tools version be the default (my original statement) 2) have the html version still present 3) have the text version still present 4) produce an xml version for better parsing (ever try and write an agenda app? Half your time is spent writing a .txt or .html parser) s/xml/json/ Ever try writing an XML app? Half your time is spent writing a .xml parser.
Re: Exceptional cases (was: don't overthink)
would be wrong. The idea here is that applying _punitive_ action (such as removal from a position) retroactively is not fair, Oh, for heaven's sake. This is nothing to do with punishment. This is a straightforward administrative problem. Turning this into an opportunity to exercise a heavyweight and in fact punitive process would be an injustice. If the IETF has wound itself into such bureaucratic knots that we can't just make an exceptional decision in exceptional circumstances, we are in much worse trouble than I thought. A +1 +(much more than 1, actually)
Gen-ART telechat review of draft-ietf-6man-udpzero-06
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-udpzero-06 Reviewer: Richard Barnes Review Date: 2012-10-08 IETF LC End Date: 2012-10-02 IESG Telechat date: 2012-10-11 Summary: Ready Comment: In general, the document is well-written and seems to cover the relevant considerations well. I agree with Barry's DISCUSS that the restrictions in Section 5.1 should be general to all usages of UDP zero checksums, and not specific to tunnels.
secdir review of draft-ietf-abfab-gss-eap-naming-05
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a method for assigning names to information from RADIUS and GSS-EAP, in particular SAML attributes received via the latter. The security considerations in this document are difficult to evaluate because the general architecture is unclear to me, e.g., who attaches these names to things and who reads them. (The naming scheme itself seems well defined.) The text that causes me concern is the following: These names MUST NOT be used for attributes issued by a party other than one closely associated with the source of credentials unless the source of credentials is re-asserting these attributes. The use of MUST NOT here implies that the intent is for the application reading attributes to have assurance that they are closely associated with the source. However, the application has no way of verifying whether this MUST NOT has been adhered to, so the entity setting names is trusted in this regard. The document should note this, and the corresponding risk that the namer will break this MUST NOT. This risk is hard for the reader to evaluate because (AFAICT) the document doesn't specify who sets names in this system. (Passive voice considered harmful.) If the names did not have this implied security semantic, then the identity of the namer wouldn't be an issue. Then this document could just define the format of the names and move on. This is a nonsense MUST: a service MUST make a policy decision Editorial: Page 7: thatwe know Page 8: MAy be absent (or is this an update to RFC 2119? :) ) Page 11: mechansisms are permitted Page 13: Sam hartman
Gen-ART review of draft-ietf-eai-mailinglistbis-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-eai-mailinglistbis-05 Reviewer: Richard Barnes Review Date: 7 September 2012 IETF LC End Date: 29 August 2012 IESG Telechat date: (unknown) Summary: Ready
Re: A nuance of interoperability reports
Seems like it depends on your definitions of abusive and legitimate. Do you have an example? On Feb 21, 2012, at 5:56 PM, Murray S. Kucherawy wrote: We like to see interoperability reports contain information about features of a protocol that are used vs. unused, so that if and when the protocol seeks advancement along the standards track, we can decide whether we want to keep it in the revision. Should we consider a protocol feature only used by abusive actors to be one that deserves to be kept, or is only legitimate use worth considering? -MSK ___ 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: Variable length internet addresses in TCP/IP: history
The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms. I look forward to your design for a forwarding plane based on streaming addresses :) Does anyone really think that we'll need more than 128 bits? --Richard The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. For most variable-length schemes, yes, but not all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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 review of draft-ietf-geopriv-policy-uri-02
That change looks fine to me! Thanks, --Richard On Nov 8, 2011, at 11:33 PM, david.bl...@emc.com wrote: Hi Richard, I think we're close: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network, thus relying on lower-layer security mechanisms. When neither application-layer or network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods, and SHOULD reject PUT and DELETE requests for policy URIs that use the http: URI scheme. This text looks good to me, except that the structure of the final sentence inadvertently neuters the final SHOULD requirement. Can we move that requirement into Section 7.1? The change in Section 7.2 would then be: OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network, thus relying on lower-layer security mechanisms. When neither application-layer or network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods. This change in Section 7.1 would pick up the moved requirement: OLD If other means of protection are available, an http: URI MAY be used. NEW If other means of protection are available, an http: URI MAY be used, but location servers SHOULD reject all PUT and DELETE requests for policy URIs that use the http: URI scheme. END One of my concerns behind wanting this general SHOULD is that there's no assurance that an http: URI will stay confined to the local network that is being relied upon to secure it. Thanks, --David -Original Message- From: Richard Barnes [mailto:rbar...@bbn.com] Sent: Tuesday, November 08, 2011 9:43 PM To: Black, David Cc: martin.thom...@andrew.com; james.winterbot...@andrew.com; hannes.tschofe...@gmx.net; gen- a...@ietf.org; ietf@ietf.org; rjspa...@nostrum.com; geop...@ietf.org Subject: Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02 Hi David, The penalty for getting a quick response for the first time is that the second response takes longer :) Inline. - The additional text in section 3.1 stating that the policy URI is a shared secret with a forward reference to the security considerations section removes the surprise factor. - The additional text on URI unpredictability in section 7.2 recommending a combination of 32 bits of entropy with rate limiting provides concrete guidance to implementers. Thanks, we'll note those changes for the RFC editor (or for a new revision, if our AD prefers). That leaves the issue of confidentiality and integrity requirements in section 7.2: Alternatively, changing required to REQUIRED in the following sentence in Section 7.2 may suffice, although integrity is not mentioned in this sentence: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. I like this phrasing. I'm not sure it's quite REQUIRED (following the MUST implement / MAY use pattern of BCP 61), but I would go for a strong SHOULD. The underlying LCP protocols already guarantee the MUST implement. Suggested text: Section 7.2 OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. The reason for going beyond BCP 61 is that BCP 61 concerns protocols in general, but this is a specific case with additional security requirements because a policy URI is a shared secret. If a policy URI is sent without confidentiality, a likely result is that the policy URI is still shared, but is no longer sufficiently secret (oops). This is particularly dangerous if there are no additional authorization checks on the PUT or DELETE methods for the policy URI, but it's probably ok in some situations if only the GET method is allowed (e.g., policy
Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02
Hi David, The penalty for getting a quick response for the first time is that the second response takes longer :) Inline. - The additional text in section 3.1 stating that the policy URI is a shared secret with a forward reference to the security considerations section removes the surprise factor. - The additional text on URI unpredictability in section 7.2 recommending a combination of 32 bits of entropy with rate limiting provides concrete guidance to implementers. Thanks, we'll note those changes for the RFC editor (or for a new revision, if our AD prefers). That leaves the issue of confidentiality and integrity requirements in section 7.2: Alternatively, changing required to REQUIRED in the following sentence in Section 7.2 may suffice, although integrity is not mentioned in this sentence: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. I like this phrasing. I'm not sure it's quite REQUIRED (following the MUST implement / MAY use pattern of BCP 61), but I would go for a strong SHOULD. The underlying LCP protocols already guarantee the MUST implement. Suggested text: Section 7.2 OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. The reason for going beyond BCP 61 is that BCP 61 concerns protocols in general, but this is a specific case with additional security requirements because a policy URI is a shared secret. If a policy URI is sent without confidentiality, a likely result is that the policy URI is still shared, but is no longer sufficiently secret (oops). This is particularly dangerous if there are no additional authorization checks on the PUT or DELETE methods for the policy URI, but it's probably ok in some situations if only the GET method is allowed (e.g., policy creation and update are handled via some other means such as a secure web portal). For that reason, the proposed SHOULD requirement would be ok with me if a couple of things were added: (i) If an LCP sends a policy URI without confidentiality protection, then the LIS or LS MUST reject the PUT and DELETE methods for that URI. (ii) The PUT and DELETE methods SHOULD NOT be supported for policy URIs that use the http: URI scheme (in contrast to the https: URI scheme). For (i) it'd also be useful to note that the current LCPs never send a policy URI without confidentiality protection in connection with this (already stated in 7.1, but ought to be connected to (i) if that text winds up in a different section). For (ii), I'm not sure what is envisioned by the final sentence in section 7.1: If other means of protection are available, an http: URI MAY be used. What sorts of other means of protection were the underlying motivation? Those other means of protection would be the reason for (ii) being a SHOULD instead of a MUST. I think the general countervailing idea here is that location servers are generally expected to be a local network function (see, for example, RFC 5986). In this context, you benefit some from other protection in that in order to capture information, an attacker has to be fairly close to the victim. There's a strong tie to DHCP security here. On one level, by analogy; DHCP, after all, provides no confidentiality protection, which is acceptable largely because its use is so constrained. At another level, though, we have to keep in mind that one of the goals of this document is to enable policy URIs to be distributed through DHCP. So even if we place stronger controls on policy URIs, DHCP will still be a weaker link. Or, said the other way around, if we require stronger controls for policy URIs (as in your text), then we might as well remove the DHCP transport from the document. Nonetheless, your two caveats look fine to me if we make some accommodation for this constrained case. Proposed text: OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network, thus relying on lower-layer security mechanisms. When
Re: 2119bis
Friendly reminder from BCP 61: Security is a MUST implement http://tools.ietf.org/html/bcp61#section-7 On 8/30/11 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-csi-send-cert-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a certificate profile for use in the Secure Neighbor Discovery protocol for IPv6. Starting from the RPKI cert profile, it adds some refinements for SEND, e.g., EKUs that authorize the subject to act in certain roles within SEND (router, proxy, host). Overall, the document is reasonably well-written, but could benefit from more precision in its use of terminology. There are a few points (noted below) where certificate processing rules are unclear. With regard to the security considerations in particular, I would prefer if they stated the risks slightly more directly (text is suggested below), but in general, the authors address the major security concerns. Detailed comments follow. --Richard Sec 2 Para 1 Suggest changing authority over an to authorization to advertise an. Sec 2 Para 2 Suggest rewording to avoid referring to SIDR WG (which is temporary). Suggested text: The Resource Public Key Infrastructure (RPKI) is the global PKI that attests to allocation of IP address space. Also, instead of SIDR certificate profile, use RPKI certificate profile. Sec 2 Para 3, General I'm confused by the several instances of the phrase address owner in the document (the phrase is not used in RFC 3971). Do you mean host? Sec 3 Para End Entity This definition is incorrect. Refer to RFC 4949. Sec 4 Para 1 The RPKI profile should be applied in *addition* to the RFC 3971 profile, right? Please clarify. Sec 4 Para 2 Why can there only be one RFC 3779 extensions? It doesn't seem like there's a risk in including IPv4 space (e.g., for a dual-stack router that was vouching for IPv4 space in some other application?), or multiple extensions for IPv6 space. Sec 5 This section should note that another deployment model (arguably the most likely) is a combination of these two, in which most resources are certified under the global RPKI, while some (e.g., ULAs) are certified under local TAs. Sec 6 Para 4 The requirement for RFC 3779 extension seems to contradict the use of ETAs as Trust Anchor Material, i.e., the last sentence of the first paragraph in this section. Sec 7 Para The inclusion of ... et seq. It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use? -- Exact matching -- Subset matching (RA within cert) -- The weird subset/intersection algorithm that RFC 3971 defines What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the ROA validation document [draft-ietf-sidr-roa-validation]. Sec 7 Para Certificate-using applications... Suggest changing Certificate-using applications to Relying Parties. Sec 8 This section correctly identifies the main risk with these extensions (namely, issuance of certs with incorrect roles assigned), but it would be helpful to clarify the application-level impact of these bad issuances. Suggested text: Since a SEND certificate attest that its subject is authorized to play a given role in the SEND protocol, certificates that contain incorrect EKU values can enable some of the same attacks that SEND was meant to prevent. For example, if a malicious host can obtain a certificate that authorizes it to act as a router for a given prefix, then it can masquerade as a router for that prefix, e.g., in order to attract traffic from local nodes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Packet mood
I hear they were thinking about making it an IPv6 extension header, but they were afraid it would never get deployed that way. --Richard On Apr 1, 2010, at 2:47 PM, Bob Braden wrote: Fred Baker wrote: So - does RFC 5841 update RFC 3514, or obsolete it? Silly question, Fred. What possible relationship could a TCP option have to an IP option? Bob Braden http://www.ipinc.net/IPv4.GIF ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
[Added IAOC] Iljitsch: Thanks very much for this information. I was not aware of this: The MECC conference center is 2 - 3 kilometers from the city center, where the restaurants are. IAOC: I had been getting used to the idea of Maastricht, with it being historic, nice city center and all. Iljitsch's observation makes me wonder if we learned nothing from Dublin, and are now choosing IETF venues from here: http://en.wikipedia.org/wiki/Extreme_points_of_the_World#Remoteness --Richard P.S. WTFIAOC is worth 65 points in Scrabble. 69 points in the Dutch edition! Ground transport: Maastricht is located in the far southeast of the Netherlands, 215 km (by road) from Amsterdam. The city is located on the Belgian border and is also very close to Germany. There are some smaller airports closer to Maastricht than the ones mentioned below, but those don't serve many destinations and don't connect to the rail network so more hassle and as much or more time to reach Maastricht despite the shorter distance. Only consider these smaller airports if you know what you're doing. You can of course rent a car at one of the airports and drive to Maastricht, and even commute between the MECC and your hotel by car if the hotel is located outside the inner city, but you'll probably need to get into the city for dinner anyway and being a few thousand years old, Maastricht's city center isn't really built for cars. The most convenient airport to use would be Schiphol (Amsterdam) airport. From there, it takes about 2 hours, 35 minutes with one change to get to Maastricht by train with a connection every 30 minutes. A second class one way ticket is 27.50 euros. The last train from Schiphol to Maastricht is at 22:16. The first train to Schiphol arrives at nine. A good alternative is Brussels, from where Maastricht is about two hours with one or two changes and one connection per hour with regular national and international trains. The last connection to Maastricht is at around 21:39. The first train to Brussels airport arrives at nine on weekdays, ten on weekends. There are also a few high speed train connections which save you 30 minutes. If you're arriving in Europe through Frankfurt or Paris, it may not make too much sense to first connect to Amsterdam or Brussels and then sit in a train for a few more hours. You may as well take the train directly from these airports to Maastricht. However, consider that missing train/plane connections is your problem, while plane/ plane connections are the airline's problem. (Financially, at least.) From Frankfurt, there is one connection per hour (weekdays) or one every two hours (weekends) that takes 4 hours, 46 minutes with regular national and international trains. The last connection to Maastricht without high speed trains leaves at around 18:22. The first connection to FRA without high speed trains arrives at 13:36. From Frankfurt it is (of course) faster to take a high speed train, and from Paris it's the only option. The downside of high speed trains is that you can't just hop on like on a regular train, you need to book or reserve a seat on a specific train. Also, they run less often so if you miss one, you're in big trouble. Also check prices before you book (usually available 90 days before the travel date), international trains in general and especially high speed trains can be quite expensive. From Frankfurt, there is an ICE connection several times a day that takes between 3 hours and 3 hours 41 minutes with 2 or 3 changes. The last connection to Maastricht is at 21:09. The first connection to FRA arrives at 10:16, 11:51 on sundays. From Paris, there is a thalys connection every two hours or so in the weekend and a bit more often during weekdays. The journey takes between 3 hours, 15 minutes and 4 hours, 10 minutes, with one or two changes. The last connection to Maastricht is at 20:04 on weekdays and 18:49 on weekends. On weekdays, the first train to CDG arrives at 10:44, on the weekends 11:36. You can also get from Heathrow to Maastricht in 5 to 6 hours with 2 or 3 changes, but as the last connection from Heathrow is around five and from Maastricht the first one arrives at around noon (two hours later on weekends), this seriously limits your flight options. The best place to investigate rail connections is http:// www.bahn.de/ You may also want to check the website of NS, the Dutch railways: http://www.ns.nl/ (but only for Dutch trips, their international planner is incomplete and will often only show longer and more expensive options) and http://www.maastrichtbrusselexpress.nl/ I have no recommendations on where to book train tickets. From Schiphol, the recommended way to get to Maastricht is with a change in Utrecht. Don't go through Amsterdam, it takes longer and it's not covered by a regular ticket. From London, Paris and
Re: Bar BoF on Location Coherence Wednesday at 11:30 AM
This meeting will be held at 11:45 today in the Carmel room. Sorry for the late notice. --Richard On Mar 17, 2010, at 4:11 PM, Richard Barnes wrote: Hey all, This message is announcing a bar BoF (lunch BoF) on Location Coherence -- interoperability between different location protocols and APIs -- for the lunch break on Wednesday of the IETF week. Location is still TBD (ironically). Full announcement here: http://www.ietf.org/mail-archive/web/geopriv/current/msg08377.html Mailing list here: http://groups.google.com/group/geo-loco Thanks, --Richard ___ 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
Bar BoF on Location Coherence Wednesday at 11:30 AM
Hey all, This message is announcing a bar BoF (lunch BoF) on Location Coherence -- interoperability between different location protocols and APIs -- for the lunch break on Wednesday of the IETF week. Location is still TBD (ironically). Full announcement here: http://www.ietf.org/mail-archive/web/geopriv/current/msg08377.html Mailing list here: http://groups.google.com/group/geo-loco Thanks, --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
+1 On Mar 17, 2010, at 9:03 PM, Tony Hansen wrote: +1 On 3/17/2010 12:18 PM, John R. Levine wrote: If we could agree that the final XML was authoritative, and if necessary let them hire someone to fix xmlrfc so it can produce the text version without hand editing or postprocessing, that would be a big step forward. ___ 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: Towards consensus on document format
Circles are not impossible, just a pain: http://tools.ietf.org/html/rfc5491#section-5.2.7 Likewise for normal distributions: http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-04 On Mar 16, 2010, at 2:57 PM, JFC Morfin wrote: I developed tools to convert RFC from/to mediawiki pages. As long as RFC 3935 obliges to use English ASCII, the simplest English ASCII format is the best as it permits easy format conversion. The only real problem I meet is the impossibility to use circles in figures. jfc 2010/3/16 Julian Reschke julian.resc...@gmx.de On 16.03.2010 14:14, Doug Ewell wrote: Brian E Carpenter brian dot e dot carrpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. Indeed. Speaking of which: did we ever *measure* the acceptance of draft- hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. Best regards, Julian ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-pkix-new-asn1-07
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates the ASN.1 descriptions of several security- relevant data objects (e.g., CMS messages and S/MIME objects) from the 1988 version of ASN.1 to the 2002 version, without changing the structure expressed by these definitions -- there are no changes to bits on the wire. The document correctly states that this document itself creates no security issues, because it makes no changes to any protocols (it simply expresses the structure of those protocols in a different, updated syntax). The only minor concern I have is to be sure that the above claims about the lack of changes are true, i.e., that the ASN.1 syntax is correct. To ensure this correctness, I would recommend an expert review focused on the ASN.1, if one has not already been done. --Richard___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
Stéphane, In GEOPRIV, where we have a need to specify a specific endpoint in order to request its geolocation, we were specifically asked by carriers looking at CGN to add a port field to the identifier space: http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions-01#section-3.3.3 --Richard On Nov 13, 2009, at 2:49 PM, Stephane Bortzmeyer wrote: At the Transport Area meeting, Alain Durand, presenting draft-ford-shared-addressing-issues mentioned that we may well have now to always log the source port of a TCP request, not only the source IP address (which may well be shared), if we want traceability. Does anyone know if it is possible with the typical TCP servers? For instance, I find no way to do it with Apache http://httpd.apache.org/docs/2.2/mod/mod_log_config.html. ___ 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: If you found today's plenary debate on standards track tedious...
From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... --Richard On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- all-01.txt Brian ___ 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: Request for community guidance on issue concerning a future meetingof the IETF
+1 Cullen is not inquiring after social policy, he's asking what the practical constraints are likely to be if there is a meeting in China. This is a sensible question, worthy of a thoughtful, well-researched response. I suspect you -- and most of the rest of us -- can't give a definitive answer to these questions for any other venue the IETF has ever met in. As a small example, I doubt many of us have a meaningful clue about the detailed impact of the US's Patriot Act as it changed basic freedoms's for citizens, nevermind non-citizens. The question isn't whether someone on this list has a definitive answer -- or anyone, really. The request was for appropriate due diligence to be done to estimate some parameters that are right now very uncertain. One could perform a similar analysis for other venues, but in most places where the IETF has met, the level of initial uncertainty has been much lower due to the relative clarity of precedent in constitutional, legislative, and judicial terms. (P.S.: Could we make a corollary to Godwin's Law for the PATRIOT Act?) --Richard Scott Lawrence wrote: On Sun, 2009-10-11 at 15:31 -0700, Dave CROCKER wrote: Cullen Jennings wrote: I carefully stayed away from social policy issues 1) What is political speech in China? ... 2) Are there any special rules about publishing and broadcasting? I ... 5) When discussing what I think of as technical issues, many participants regularly treat Taiwan and PRC as two different countries ... Could any discussions like this be viewed as political speech? What are the rules on this? This is your version of staying away from social policy? If it is, I suspect that what is first needed are lessons in the nature of social and political policy. I suspect you -- and most of the rest of us -- can't give a definitive answer to these questions for any other venue the IETF has ever met in. As a small example, I doubt many of us have a meaningful clue about the detailed impact of the US's Patriot Act as it changed basic freedoms's for citizens, nevermind non-citizens. Really, Cullen, it's difficult to overemphasize just how basic a mistake it is for us to pursue your questions. I don't think it's helpful for you to repeatedly try to shut down attempts to get answers to questions that many people on the list have repeatedly said that they think are relevant and important. I don't think that Cullen has asked for opinions from anyone on whether the rules in China are right or wrong - that would certainly be discussing social policy. What he has asked for is discussion of how they will impact the normal functioning of an IETF meeting, and I for one agree that the answers are important in that current context. ___ 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: 答复: Legality of IETF meetings in P RC. Was: Re: Request for communityguidance on i ssue concerning a future meeting of the IETF
Hi Tian, I think the question here is what makes for a politically sensitive discussion. In places where IETF meetings have historically been held, there has been a lot of distance between technical topics and political topics. In the US and much of Europe, for example, discussions of techniques for avoiding firewalls or anonymizing traffic are largely considered technical, not political. (Although people might have political reasons for discussing these topics.) The concern is that in the Chinese context, the sets of technical and political topics could be closer, if not overlapping -- that some technical topics might not be overtly political, but might be close enough to cause trouble. --Richard jiangt wrote: Dear Richard and Ole, I'm an engineer from China. I like to check IETF mailing list and try to keep up with the development trend of IETF. I think that politically sensitive discussions possiblely bring troubles to the meeting, if any. But I do not know why IETF engineers worry about someone to make a political speech in a **technical** meeting and I want to know who plan to make such a speech? BTW, I'm not interested in such a speech when I attend IETF meeting, how about U? Tian -邮件原件- 发件人: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 代表 Richard Barnes 发送时间: 2009年10月10日 8:53 收件人: Ole Jacobsen 抄送: Theodore Tso; Henk Uijterwaal; IETF-Discussion list 主题: Re: Legality of IETF meetings in PRC. Was: Re: Request for communityguidance on issue concerning a future meeting of the IETF (g) many hurt Chinese engineers participate to the IETF and very politely do not react: have them been invited to comment? Everyone on the IETF mailing list has been invited to comment and that certainly includes Chinese engineers. Indeed, I wonder if there is something to be learned from the conspicuous absence of comment by all but a very few Chinese participants. --Richard ___ 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: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
(g) many hurt Chinese engineers participate to the IETF and very politely do not react: have them been invited to comment? Everyone on the IETF mailing list has been invited to comment and that certainly includes Chinese engineers. Indeed, I wonder if there is something to be learned from the conspicuous absence of comment by all but a very few Chinese participants. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-yam-rfc1652bis-pre-evaluation-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides a set of observations on whether the SMTP Service Extension for 8bit-MIMEtransport (RFC 1652) should be advanced from Draft Standard to Standard. It matches the document against the criteria of RFC 2026, and poses questions to the IESG about the acceptability of the document for a full Standard, along three axes: 1. Proposed changes 2. Any other changes necessary (none listed) 3. Downward references I do not believe that this document raises any security concerns beyond those of the underlying document (RFC 1652). All of the proposed changes are simple updates to current references (e.g., adding RFC 5321 in addition to RFC 821). None of the proposed changes or downward references are related to the security of the protocol. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
This brings us to the question of the identifiers: it's certainly true that systems which are anonymous but linkable offer a higher level of privacy than those which do not. However, it's often possible to determine which identifier a given person has (e.g., by observing a specific persons card being read), then you can of course track them by name. In addition, if the identifier-person mapping isn't generated securely and kept confidential, then you may be able to quickly determine a large fraction of the mapping. Just to amplify this, it would be really trivial to gain targeted knowledge of the database just getting close to people that you're interested in tracking (e.g., talking to them, maybe even walking past them). I'm guessing that if you're engaging in industrial espionage, you should at least have some knowledge of who you would like to target. Once you've established the number-to-identity mapping, your sensors can do all the rest. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Being a relatively short-term IETF participant, I lack the history that many on this list have, but since Jari asked for comments, I'll provide some. Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and others that it makes sense to have IESG notes be mandatory for the ISE to include in independent stream RFCs. Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. So I agree with Jari's option (b), that IESG notes should be something that is always applied to the published RFC. --Richard Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ 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: [Tools-discuss] meta-issues on charter discussions
As a side issue, it appears that Ekr is chairing TLS twice, at least according to the linked TLS tools page. --Richard On Mon, Aug 24, 2009 at 3:55 AM, pasi.ero...@nokia.com wrote: The tools WG pages used to have diffs between charter versions (see e.g. http://tools.ietf.org/wg/tls/charters/ -- the delta symbol leads to side-by-side diff between the versions), but it looks like this broke when new www.ietf.org was deployed in July Best regards, Pasi -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Tony Hansen Sent: 21 August, 2009 17:57 To: tools-disc...@ietf.org Cc: ietf@ietf.org Subject: Re: meta-issues on charter discussions This was posted to the ietf list. While the charter history pages are nice, they can be made better using a format similar to how tools.ietf.org presents RFCs and I-Ds: a non-printing list of versions at the top with ways to show differences between versions. Sounds like a job for the tools team. :-) Tony Hansen t...@att.com Thomas Narten wrote: Re: old charters and such. While poking around earlier this week, I found: http://www.ietf.org/dyn/wg/charter/history/ (it is hanging of the WG pages, so not that hard to find.) It appears to be a snapshot of charters whenever they change. But, they change often due to events that are probably not the kind of changes we are thinking about, and there is no indication about what has changed, so there are a lot of copies and wading through them to find stuff appears pretty daunting. And the history only goes back 3 years or so... But they might be a basis for some tools to extract stuff. But, if tools are going to do this, it seems like an archival format other than HTML would be desirable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Tools-discuss mailing list tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-pkix-other-certs-04
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This documents creates a certificate extension that allows the issuer of a certificate to assert that the subject of the certificate is the same as that of a set of other certificates (i.e., that the same entity holds all the corresponding private keys). This extension clearly creates some impersonation risks, but the document provides sufficient advice to CAs to mitigate these risks. Overall, I think the document is basically ready for publication. Some comments, mostly editorial, follow below. --Richard - Section 1, Paragraph 2 s/assoicate/associate/ Section 1, Paragraph 3 To be clear here and decouple this paragraph from the last, I would replace the phrase ... supports such linkage to something like ... allows a certificate issuer to attest that the end entity that holds the private key for the certificate in question also holds other private keys corresponding to other certificates. This change also clarifies why you refer to end entities below instead of just subjects. Section 2, Paragraph 3 Change ... change CA when renewing its certificate to ... change CA when replacing its certificate. Renewal only happens with the same CA. Section 3, ASN.1 fragment Change ::== to ::=. Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para) The first sentence in this paragraph seems very vague -- what does it mean for a use of this extension to be safe? Suggest replacing with a requirement that is notably absent from this paragraph, namely that CAs MUST issue a certificate containing this extension only after they have validated that the holder of the private key for the certificate also holds the private keys for linked certificates. Section 3, Paragraph 6 (same as above) Do you mean to have both requirements in the final sentence as SHOULD NOT? It might be helpful here to note how the purpose a certificate might be determined, e.g., via CP or EKU OIDs. Setion 3, Paragraph 10 The validation procedure in RFC 5280 requires an RP to verify that a certificate has not been revoked (Section 6.1.3, step (a)(3)), so the initial conditional can be omitted. This requirement is really important for this extension, since one reason that certificates get revoked is private key compromise, in which case a party other than the intended subject has possession of the private key (by definition). This situation would allow the attacker to obtain linked certificates even from a CA that complies with this document. Section 3, Paragraph 12 It would be helpful to clarify why this restriction is in place, e.g., Since CA certificates are only used for certificate validation, and this extension has no effect on the validation procedure, this extension is meaningless for CA certificates. Section 5 It's not clear that this section belongs in this document. It would not reduce the clarity of the document to remove it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust
It would seem in the open spirit if the IETF to make this a standing order for t-shirt art, wouldn't it? On Friday, July 31, 2009, Dave CROCKER d...@dcrocker.net wrote: Gregory M. Lebovitz wrote: I have been asked about this several times this week, so I'd like to clarify here for all. Juniper has donated the art for the highly popular IETF74 San Francisco Greg, Many thanks! Especially in light of Bob Hinden's cautionary reference to the Wasa, at the Plenary, I suspect it would be worth exploring also obtaining the layered art on the back of the t-shirt (and on the invitations) of the Wasa. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ 75attendees mailing list 75attend...@ietf.org https://www.ietf.org/mailman/listinfo/75attendees ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-adslmib-vdsl2-07
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an SNMP MIB for managing VDSL interfaces, extending existing MIBs for managing other classes of DSL interfaces. As such, the primary security issues are related to the risks associated with read, create, or write access to various tables and objects. Overall, the Security Considerations does a good job of describing the risks associated with use of this MIB and the security mechanisms that should be used to mitigate them. My only concerns are that: 1. There is no mandatory security mechanism, either for implementation or deployment, and that 2. Risks related to read-only fields may require a slightly more thorough treatment Beyond these two minor issues, the comments below are focused on the clarity of the security discussion, rather than its content. --Richard - The current security considerations section has three main parts: 1. A list of fields with write/create access and associated risks 2. A list of fields with read access that pose especial risks 3. Recommendations as to how to mitigate these risks Comments below are organized accordingly. 1. Objects with write/create access 1.1. The current list seems to be comprehensive, but it can be difficult for the reader to get a general idea of what the high-level risks are and how these relate to the individual Objects. It could be helpful to group these tables and objects under classes of general risks (maybe in subsections), or alternatively, to tag each table or object with an indicator of which classes of risk it introduces. The list I came up with as I was reading was as follows: 1.1.1. Disruption of service 1.1.2. Degradation of service 1.1.3. Information loss or overload 1.1.4. Privilege escalation / unauthorized access to lines/channels 1.1.5. Multiple lines/channels/profiles/templates affected 1.2. The phrase adverse operational effect is too vague. Suggest trying to find something more specific to say (maybe from the above list?) 2. Objects with read access 2.1. It's a good first step to list the fields you do here. I'm wondering though, whether there is some interaction between other readable fields and the writable objects discussed previously. Are there situations where reading objects could allow an adversary to gain information that would allow him to better exploit a write permission he has? E.g., an attacker that can read objects related to monitoring (e.g., counter) might be able to determine what attacks would be detectable by the current monitoring configuration and which would not. It's not necessary (or even necessarily possible) to list all the possible interactions here, but it would be helpful to have a general note that they exist, and possibly a recommendation that any given user be given access only to the objects he needs (e.g. only to objects within a given set of tables), not all readable objects. 3. Recommendations for mitigations 3.1. The reference to Section 8 of RFC 3410 (Standardization Status) seems incorrect. Suggest changing to refer to section 6.4, 7.8, or 7.9, or simply to refer to RFC 3414 and 3415. 3.2. The phrase using IPsec is unclear here. I assume this means using IPsec to connect sites that are remote from each other. 3.3. IPSec should be IPsec 3.4. What is the reason for not requiring implementations to provide support for SNMPv3 security mechanisms? The SHOULD=MUST+exceptions (i.e., RECOMMENDED=REQUIRED+exceptions) pattern could be useful here -- when is it acceptable for an implementation to omit security support? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-geopriv-http-location-delivery
Martin: Regarding #2, I would feel more comfortable with your text if it had the strength of a RECOMMENDATION. Making a specific policy configuration a MUST NOT doesn't make sense. Also, this discussion is missing the possibility of client authentication in TLS, which falls under the same recommendation. Suggested text follows: Old: The LIS MUST NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617]. New (Thomson): A Device that conforms to this specification is not required to support HTTP authentication [RFC2617] or cookies [RFC2965]. Because the Device and LIS do not necessarily have a prior relationship and this protocol is suited to a range of networks, there is no common authentication mechanism that can be used for any access network. A LIS MUST NOT deny access to location information based on the absence of Device authentication, unless it can be guaranteed that all Devices in the access network are aware that authentication is required. New (Barnes): A Device that conforms to this specification MAY omit support for HTTP authentication [RFC2617] or cookies [RFC2965]. Because the Device and the LIS may not necessarily have a prior relationship, it is RECOMMENDED that that the LIS not require a Device to authenticate, either using the above HTTP authentication methods or TLS client authentication. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, That's a specious argument. As several others have noted on this list, it's perfectly feasible for any relying parties (sovereign nations or otherwise) to not use the IANA root, simply by creating their own root. This is a little more complicated than just redirecting IP traffic, but not by much. To quote from Mark's earlier message: Mark Andrews wrote: Stephen Kent writes: You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. --Richard Phillip Hallam-Baker wrote: Steve, The sovereign nations that object to US control of the root are willing to accept the current status quo preciely because they have an exit option. Should the US defect on its obligations and order ICANN to drop Cuba or Palestine out of the root or to take any other action that was considered to be abusive, the countries that objected could simply direct their local ISPs to redirect all IP traffic to the A thru M root servers to another set of servers of their choice. At the moment the ICANN has the theoretical ability to defect, but can only do so at the cost of becomming irrelevant. The global DNS outside the US would swiftly pass to the ITU. With the proposed root arrangement for DNSSEC, this changes. Not only does the US have effective control, it has perpetual control of any apparatus that chains to the ICANN root of trust. This is bad for the US, bad for ICANN and bad for other sovereign states. First, consider the likely source of a defection, some idiot member of Congress from Florida grandstanding for votes. Such a move is going to give the career civil service a fit, particularly the diplomats who prefer to end rather than begin international crises. I have spoken to very enior members of this administration on this topic, they had come to the exact same conclusion themselves. Now consider ICANN. Let us imagine that they do hold the master root key. What is then to stop some armed terrorist nut cases laying siege to the key repository? Their objective might not be to drop a country out, they might want to insert some irredentist domain of their own. Ordinary PKIs are not subject to this type of pressure, because they are not the lynchpin of the global communication system. While the various splinter-roots may appear to be complete jokes, they have had one significant result, they have drawn attention to the issue. In particular very much doubt that the Turkish secret service are too amused at the whole process given some of their experiences. On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kentk...@bbn.com wrote: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ 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-geopriv-http-location-delivery-14
Ben, Thanks for your review. With respect to the HTTP issue you raise, is your claim that the HTTP binding prevents the use of Digest or Basic based on this sentence from Section 6.3? HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. If so, then I think that's a misinterpretation that calls for a clarification. The authors should feel free to correct me, but I think that HTTP-level errors (e.g., the need for authentication, or even a LIS not listening at a given path) can still generate other HTTP response codes (e.g., 401 or 404). It's just that if the only thing that's gone wrong is at the HELD layer -- if it's the positioning that failed, not the communications -- then you have to use a 200. Assuming that all the above is accurate, proposed text: HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. (Other response codes may still be generated at the HTTP layer, if the problem is with the HTTP part of the message, not the HELD part. For instance, if the request needs to be authenticated with Basic or Digest authentication, the server may issue a 401 Unauthorized response as a challenge, or if the indicated path is not valid, then the server may issue a 404 Not Found.) Cheers, --Richard Ben Campbell wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a feature that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. -- section 9.3, 5th paragraph: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location. It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? -- same paragraph: ... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a mitigating mention. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. --Richard Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta ___ 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
SECDIR review of draft-ietf-sipping-update-pai-09
Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document extends the applicability of the SIP P-Asserted-ID header (PAID in brief) to include origination by other SIP entities and use in other SIP methods than were specified in RFC 3325. It also provides recommendations for processing of P-Asserted-ID to require recipients to be more generous in what they receive as syntactically valid. (I'm actually not clear on why this document is really necessary, since as I read it, RFC 3325 doesn't actually forbid the use of PAID in the cases addressed by this document except informally in the table rows in Sections 9.1 and 9.2. But if the WG feels this document provides important clarifications, I don't see this redundancy as a problem.) The document does not raise significant security issues, largely because it is specified to be used only within a Trust Domain (as specified in RFC 3324), which provides many assumptions about the security of the underlying environment in which this header is used. The document clearly states this requirement (use within a Trust Domain), so there is little risk that the document will be understood to be applicable in the general Internet. Several comments related to some ambiguities and inconsistencies in the document follow. --Richard - General: The problems that this document raises with authentication seem kind of irrelevant, in that requirements for authentication are subject to any given domain's Spec(T). For example, Spec(T) may say that it's sufficient a UAC or UAS can send PAID if they've joined the trust domain by establishing an authenticated TLS connection to their next-hop proxy. The document seems to neglect entirely the possibility that the UAS is part of the trust domain (which might be facilitated, e.g., by sip-outbound), in which case it seems sensible to allow PAID in responses. In any case, the first reverse hop can delete PAID from the response if it doesn't regard the UAS as trusted, e.g., if the UAS hasn't previously authenticated (this is the analogue of the comment paragraph in Section 4.2). So I don't really see a need to exclude PAID from ACK and CANCEL request and from responses based on them not being challenge-able. Suggest changing the relevant paragraphs in the Introduction and Security Considerations to say something like If the authentication provisions in your Spec(T) rely on Digest authentication, then you should forbid PAID in ACK, CANCEL, and responses. - General: This seems to be all about PAID. Don't some of the considerations also apply to PPID? PPID is already specified to be inserted by the UAC, but it seems like the addition of other request methods and considerations about multiple URIs and other schemes could be useful. - In Section 4.3: ... the registrar MAY use this as evidence that the registering UA has been authenticated ... This statement seems kind of weird in the case where the 'node' is the UAC. First, there's an unstated assumption that there's a requirement in Spec(T) that UACs authenticate before becoming part of the domain, or otherwise before using PAID. Second, assuming that's the case, the logic here seems either circular or incomplete, depending on who the UAC authenticated to. If the UAC authenticated to the registrar, then there's no need for further proof. If the UAC authenticated to someone else, then the registrar has no idea whether the node is in the trust domain or not, so it has to disregard the PAID -- that is, the registrar needs some other channel to determine whether the UAC is within the trust domain. Suggest adding a clarification here: However, if the node transmitting a P-Asserted-ID header to a registrar is the registering UAC itself, the registrar MUST NOT regard the P-Asserted-ID itself as evidence that the UAC has authenticated (some other authentication technique must be used, such as SIP Identity or Digest Authentication). As an aside, the phrase the registering UA ... represents the identity asserted seems awkward. Suggest s/represents/is represented by/ - In Section 4.5: This section uses the word[s] [un]expected a lot without defining what they mean. Is this about adherence to RFC 3325? Implementation design decisions? Part of Spec(T)? All of the unless Spec(T) caveats here imply that implementations SHOULD allow all of these things, if it's possible that they could be specified by some users' Spec(T). - Section 6: When receiving a response from a node outside the Trust Domain, a proxy has no standardised SIP means to authenticate the node. This paragraph seems unnecessary. It seems like
SECDIR review of draft-ietf-ntp-ntpv4-proto-11
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an update to the Network Time Protocol, a mechanism that Internet hosts can use to synchronize their clocks. I have strong reservations about the security mechanisms specified in this document. The central security requirement for this protocol is that protocol endpoints be authenticated and that messages be integrity-protected. These protections are provided primarily by signing messages with a custom MD5-based MAC (i.e., not HMAC-MD5), as in NTPv3, although extensions are included to enable the use of the Autokey scheme for using X.509 certificates to authenticate digital signatures. Both of these schemes are a little bit troubling. For the MAC scheme: In addition to using a custom MAC instead of a more standard one, the MAC relies on the MD5 hash function, for which there are known algorithms to find collisions. I would expect the document to either or both of: 1. Replace MD5 with a stronger hash 2. Argue that the weaknesses in MD5 do not lead to MAC vulnerabilities The document seems to take the latter approach by referring to an NDSS paper on hash transitions. However, this paper does not address the vulnerabilities of MD5-based MACs in any detail (the closest it comes is to say that because TLS uses HMAC, the current collision-only attacks most likely do not represent a threat), much less consider the special MAC used by NTP (v3 and v4). I would suggest the authors find a better, more specific reference, or incorporate a mechanism for hash agility. For the Autokey scheme: I have not reviewed Autokey thoroughly, but my initial impression is that it is a far more complicated scheme than is necessary for the simple distribution and revocation of keys for NTP. (ISTM that it would suffice to have, e.g., a simple format for specifying keys and KEYIDs, encapsulated in S/MIME and distributed either out of band or in a special payload type.) In any case, it seems inappropriate for a Standards-track document to refer to a cryptographic protocol described only in a university-internal technical report. Such a scheme should be subject to the same standard of review as other cryptographic systems used within IETF protocols. The document properly notes that as specified, broadcast clients are vulnerable to DoS attacks from some broadcast servers, but only says that Access controls and/or cryptographic authentication means should be provided for additional security in such cases. This text should be replaced with something more precise, even if only to say Protections against these attacks is left to future work without specifying what the solution would look like. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
Chris, At recent IETFs, I've found it helpful to have a couple of machines in the terminal room. Having machines that are pre-configured saved me the time of setting up my machine to work with the printers when I just wanted to quickly print out a draft during a break. So it might be useful to keep one our two around, but I agree that no more are really necessary. Thanks for the update, --Richard Dearlove, Christopher (UK) wrote: I believe this to be on-topic for this list based on the summary of on-topic subjects. However I don't see any similar subjects recently, so apologies if there is a batter place, and a pointer to it would be appreciated. I have had it confirmed by the secretariat that the terminal room at IETF 74 will not contain any machines, presumably just network connections. When I first attended an IETF meeting (IETF56) the terminal room contained several machines, sometimes barely enough. But over the years the number has declined, along I suspect with their usage. There have been machine-free terminal rooms in the past. As like most people I've brought a laptop, I haven't monitored the situation closely. But now, if I come to IETF74, I won't have a laptop with me. Corporate policy, based on recent US legal decisions, is that I may not take a laptop (or PDA etc.) into the USA. This is not subject to modification. Obviously even a machine in the terminal room would be a very poor second, but it seems even that is out. There are obviously broader issues regarding US meetings. But I will limit myself here to the narrower issue, and to simply bringing it to attention. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-mmusic-file-transfer-mech-09
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an SDP syntax for signaling MSRP sessions that are to be used *only* for a specific file transfer. I highlight the word only because MSRP can already be used for file transfers, but the intent of an SDP peer to use a particular MSRP session to transfer a file cannot be signaled in SDP. This document adds syntax to SDP for that signaling. Given the fact that MSRP can already handle file transfers, I was expecting this document to address the security trade-offs associated with explicitly signaling these transfers. The current Security Considerations section focuses more on the traditional considerations around confidentiality and integrity of files transferred over this mechanism, without referencing the existing mechanisms in MSRP itself (RFC 4975). Overall, the document is well-written and comprehensible. However, there are a few ambiguities in the main text, and some significant repairs that need to be made to the Security Considerations. SECURITY COMMENTS: 1. The first paragraph of Section 10 is a non-sequitur: Lying about the attributes defined in this document has nothing to do with integrity-protection. The file sender can send a bad file that's still bit-for-bit perfect as it goes over the wire. What this section should recommend instead is that the file receiver MUST validate all available parts of the file-selector attribute (in addition to integrity protection). Similar text should be added to Section 8.2.2 and 8.3.2. This validation prevents the file sender from lying about what he's sending, and it prevents attackers that can't see the signaling from sending bad files to the file receiver. 2. The third paragraph of the Security Considerations (and parts of the first two) should be replaced by a reference to RFC 4975, which has a much more thorough discussion of integrity and confidentiality for MSRP. 3. There is no discussion of (1) authentication of file receivers or (2) authorization of file transfers. Given that this extension enables the pull pattern, this discussion is critical. For example, there's nothing in this document to recommend that my UA not blindly return any file that another UA asks for. I would recommend adding some text that file transfers MUST be authorized by the file sender's local policy, and that this authorization process MAY require that the file receiver be authenticated. The latter requirement will need some discussion of authentication, which can primarily be dealt with by referring to RFC 4975. OTHER COMMENTS: 1. The document discusses in detail when a change of file selector or file-transfer-id should trigger a new transmission. The document also seems to assume that a new transmission is only initiated after the first transmission is canceled. It's not clear (to me, anyway) whether this is in fact necessary, or whether a new file transfer operation (as in Figure 3) could be initiated without canceling the current operation. (Perhaps there's a port constraint here?) 2. In Section 8.2.1, why is name a MAY for inclusion in the file selector, while the others are MUSTs? 3. In Section 8.2.2, shouldn't it be The file receiver ... MUST add at least one of the selectors defined... (instead of SHOULD)? What would it mean for the recipient to send a blank file-selector? Send me a file! Any file!? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-calsify-rfc2445bis-09
Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a document format (iCalendar) for expressing calendaring information. This format does not contain mechanisms for providing security features to the information encoded in it, but there is appropriate text in the Security Considerations to guide protocols that might carry iCalendar documents. My only real concern is the ambiguity of the Binary value data type. The other value data types defined in this document have clear semantics attached that indicate how a compliant parser might handle the encoded data. The Binary type defines how to decode the included data, but not what sort of information this data conveys. Without further context to guide processing of this information, I'm concerned that this could lead to implementations that attempt to guess the type of binary content. I would suggest adding text to Section 3.2.20 of the following character: If this parameter indicates that the type of the property value is BINARY, then the FMTTYPE paramter MUST be set in order to indicate the MIME type of the encoded binary information. In general, though, I think this document is ready to go. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-forces-model-14
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an information model for describing forwarding elements within the ForCES framework. In this model, forwarding elements are constructed as a network of Logical Functional Blocks with a well-defined interconnection topology. The document seems functionally complete and consistent. The document defines an XML syntax for describing FE capabilities and states. This structure (in some semanticaly equivalent encoding) will be the basis for such descriptions within the ForCES protocol. Section 7 makes clear that FE descriptions constructed according to this model will be used to communicate FE topology information for several purposes. Given that attacks on this information while en route between ForCES entities are dealt with in RFC 3746, what seems to me to be missing here is a discussion of what risks an entity can introduce by mis-constructing a model, i.e., by communicating false information within the protocol. For example, could an FE prevent a CE from controlling certain LFBs by omitting them from the topology it reports? Some discussion of these risks would be helpful. Overall, however, I think this document adequately addresses relevant security concerns. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08
Hi Julian, I'd like to try to answer one of your questions: As far as I understand, HELD is used to query for location information. Right now, the details of the query are encoded in a POST body as defined by the XML Schema in http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08#section-7. A GET works the same way as an empty POST request (as shown in 11.1). This really smells like over-engineering. Why aren't these things simple query parameters in a GET request? The short answer is that the WG (and the HELD authors in particular) perceive a need for this protocol to have an extensible request syntax. This document (-http-location-delivery) defines a very basic request-response container for location-request and -response messages. In this basic form, it supports the simple case where the HELD server can determine the client's location based only on the client's IP address. Often, however, the HELD server requires additional information to determine the client's location. The most basic example of this is when the HELD server computes the client's position based measurements of the network, such as 802.11 signal strength measurements. These measurements could be embedded into a HELD request using the extensions to the XML request syntax defined in the following draft: http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements http://tools.ietf.org/html/draft-thomson-geopriv-wimax-measurements It's fair to note that the WG has not adopted any HELD extensions as WG documents. However, GEOPRIV is currently considering whether to adopt them, so it seems to make sense to provide a simple way to extend the request syntax. Cheers, --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
GEOPRIV and ECRIT experiments at IETF 72
I wanted to let folks know about an experiment that some folks from the GEOPRIV and ECRIT working groups have been working to set up at IETF 71 to see if we can deliver some basic location-based applications (including emergency calling), using the IETF network as a platform. The prinicpal challenge in creating location-based applications is getting location in the first place. This experiment is getting location via the IETF network: When you send the location server a request for your location, it looks up which AP you're connected to and returns the location of that AP (if it knows it). Based on this location platform, we've created a few different applications, including -- Basic location mapping -- ECRIT emergency calling -- Location-enhanced Jabber presence -- LoST-based discovery of nearby points of interest (e.g., museums) Much more information is available on the web page we've created at the following URI: http://geopriv.googlepages.com/ Please feel free to send email to me if you're interested in participating or helping out in any way, or if you have any feedback on the experiment. Thanks --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: GEOPRIV and ECRIT experiments at IETF 72
... and of course, I mean IETF 72 in the first paragraph ... Richard Barnes wrote: I wanted to let folks know about an experiment that some folks from the GEOPRIV and ECRIT working groups have been working to set up at IETF 71 to see if we can deliver some basic location-based applications (including emergency calling), using the IETF network as a platform. The prinicpal challenge in creating location-based applications is getting location in the first place. This experiment is getting location via the IETF network: When you send the location server a request for your location, it looks up which AP you're connected to and returns the location of that AP (if it knows it). Based on this location platform, we've created a few different applications, including -- Basic location mapping -- ECRIT emergency calling -- Location-enhanced Jabber presence -- LoST-based discovery of nearby points of interest (e.g., museums) Much more information is available on the web page we've created at the following URI: http://geopriv.googlepages.com/ Please feel free to send email to me if you're interested in participating or helping out in any way, or if you have any feedback on the experiment. Thanks --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Review of draft-ietf-geopriv-http-location-delivery-07
$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $ S 4.3.1. Devices that establish VPN connections for use by other devices inside a LAN or other closed network could serve as a LIS, that implements the HELD protocol, for those other Devices. Devices within the closed network are not necessarily able to detect the presence of the VPN and rely on the VPN device. To this end, a VPN device should provide the address of the LIS server it provides, in response to discovery queries, rather than passing such queries through the VPN tunnel. How do you envision this happening? Isn't this going to require changing every VPN protocol? I think some more text would be appropriate here... It requires location information to be obtained before the tunnel is setup. OK, but I still don't understand how this is going to work. Say that I'm on a local network with a DHCP server and the VPN server is a couple of hops away. How does the VPN device provide the address of the LIS server to me? When you operate a network and you want this stuff to work then you have to consider this aspect. In the past a few folks have suggested to write a BCP about how different deployments may deal with this aspect but I believe it is far too early todo so for a BCP. The problem is that I'm not sure that this is an issue that can be solved by the network operator. In the example I described, it sounds to me like new protocol work may be required. The current document specifies the use of HELD as a protocol between an endpoint and its local network (i.e., as a location configuration protocol). In that sense, the use case you mention doesn't arise, or rather, the use case can be worked around by appropriate configuration of the LIS by the access network operator (to know how network segments are connected on the VPN). I think this issue merits more of an applicability statement than new protocol work. Well, lots of protocols would benefit from not having IP address spoofing, but again, you're making a levy on network operations on a global scale, no? If you want to deal with certain attacks then you may want todo something about it. Sorry, I don't think I get what you're saying here. What the document is trying to say is that because HELD uses the requestor's IP address as a location identifier, if the LIS is trying to assure that location is actually only provided to the host that originates a request, then it must have assurance that the source IP address of the request is that of the originator, i.e., that the source address of the request has not been spoofed. If there is no requirement for that level of assurance, then there is no requirement for anti-spoofing. On the other hand, given that the LIS is notionally operated by the access network operator, this is actually a local requirement: If you, the network/LIS operator, require this degree of assurance then you MUST implement measures to prevent IP address spoofing. (Note, however, the conditionality.) --Richard ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
As some of you might have noticed, some GEOPRIV participants ran a small experiment, using the IETF network as a base for location-based services. We had a few folks try it, and learned a lot, but three main things: 1. Interworking with the IETF NOC was really pleasant (Thanks, guys!) 2. James Winterbottom's location server worked really well and integrated easily with the IETF network. 2. The client software I wrote successfully interworked with the location server in test cases, but failed badly in real life Overall, prototyping these technologies was a really positive experience for us, one that I would recommend to other WGs. We're certainly planning on making another effort at it in Dublin! --Richard Jari Arkko wrote: I really enjoyed the IPv6 experiment, thanks to everyone who was involved. Obviously, the experiment and a couple of other recent things (like moving to AMS service) made things move forward in a number of different places, our own computers, IETF computers, various people's own and company sites, etc. Perhaps the most notable achievement here was ipv6.google.com. That was really great, thank you Google! But the experiment was useful also in other ways, not only as an operational/deployment action. The two experiments that I attended (NANOG and IETF) have changed my and maybe other people's opinions too on some of the technical issues. I think it helps us see clearer on what are the things that the IETF needs to do in this space. We will see follow-ups on this. We should also implement future IPv6 experiments and network deployments. But why I'm really sending this e-mail is to suggest that IPv6 might not be the only topic for such future efforts. Here's a challenge for the RAI folks: What about SIP, as in every plenary participant making SIP calls to each other. Doable? Challenge for our IT folks: Internationalized Internet Drafts, including file names. Doable? ietf.pana in addition to ietf.1x. Doable? Etc Jari ___ 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
GEOPRIV Experiment at IETF 71
Hi all, Wanted to let folks know about an experiment that some participants from the GEOPRIV working group have put together for this IETF. Using the IETF network infrastructure as a location source, we've set up a location server [1] that offers location information over the HTTP-based HELD protocol [2]. It works like this: ++ +-+ +-+ | Client |---HELD| LIS |---| IETF (NetDisco [3]) | ++ +-+ +-+ 1. Client submits HELD request 2. LIS queries NetDisco (over an ad-hoc interface) for location of an IP 3. NetDisco returns civicAddress XML for the AP to which the requested IP is connected, e.g.: civicAddress xmlns=urn:params:xml:ns:pidf:geopriv10:civicAddr countryUS/country A1Pennsylvania/A1 A3Philadelphia/A3 A6Market/A6 STSStreet/STS HNO1201/HNO PC19107/PC ROOMFranknlin 1/2/ROOM /civicAddress 4. LIS inserts civicAddress into PIDF-LO into locationResponse and returns to Client The HELD server is written in PHP, and is based on the open-source HELD LIS written by Andrew Co. [4]. We have two clients for you to try out: 1. I wrote a small Java application [5] that pulls location from the HELD server and posts it as the status of a Jabber account. For instance, while I was in SIPPING this afternoon, my status was: Current location: Civic Address: Franklin 1/2 1201 Market Street Philadelphia, PA 19107 Note: This app runs *alongside* your usual Jabber client, as a separate client, so you don't need to change anything about how you use Jabber. Requires Java 1.6. 2. Along with the open-source LIS from Andrew Co, there's Java client library and GUI that shows most of the features in draft-ietf-geopriv-http-location-delivery-05, including the creation and management of location references (URIs that refer to location). You can download it at [6] (Note: (1) you need to download both the client library and the GUI; (2) requires Windows and Java 1.6.) 3. Karl Heinz Wolf from Nic.at has enhanced the Zap! SIP client so that it will access location and send it out in SIP messages [7] If you do give these tools a try, please send feedback to me and to the GEOPRIV working group list, [EMAIL PROTECTED]. Thanks a lot, --Richard [1] http://lis.ietf71.ietf.org/ [2] draft-ietf-geopriv-http-location-delivery-05 [3] http://www.netdisco.org/ [4] http://held-location.sourceforge.net/ [5] http://lis.ietf71.ietf.org/downloads/geojabber-1.0.zip [6] http://lis.ietf71.ietf.org/downloads/HELD_Client-Executable.zip http://lis.ietf71.ietf.org/downloads/HELD-Client-GUI-test-app.zip [7] http://ecrit.labs.nic.at/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] Dublin Hotel Contract was Re: IETF 72 -- Dublin!
Ole, I noticed the same thing when I was making my booking. As a precaution, I put a note in the Comments block saying that I expect the terms of the IETF contract to be followed, with a copy of the terms from Ray's email. --RB Ole Jacobsen wrote: I can confirm that the confirmation letter from the hotel does not reflect the terms stated by Ray, but this is presumably just a limitation of their automated system. For example, the letter says: These rates are not available for groups or conferences, which is exactly the opposite of what's going on here. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
