Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
Hi, Whatever the information is used for, or not used for, I think it would be useful to know the number of remote participants, and where they are located. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -Original Message- From: SM [s...@resistor.net] To: Christer Holmberg [christer.holmb...@ericsson.com] CC: John C Klensin [john-i...@jck.com]; ietf@ietf.org [ietf@ietf.org] Subject: Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception Hi Christer, At 13:54 24-07-2013, Christer Holmberg wrote: >Why couldn't remote participants register to the meeting like all >other participants? > >Remote participation would of course still be free, but it would >allow remote participants to subscribe to the attendee list in the >same way as other participants. A quick scan of that list shows the following topics: - coffee, sims - mailing list for IETF women and the following comment: "I'm not sure why I should be required to give my contact information to get a document prepared by the Brussels airport for Brussels passengers." >In addition, it would provide better knowledge to IETF about the >number of remote participants, where they are physically located >(which might be useful input when planning future meeting locations) etc. I doubt that the IETF chooses its meeting location based on where the remote participants are located. I'll go off-topic first. Mr Reschke once asked "I was just trying to understand *why* the archive can't be at <http://www.ietf.org/tao/archive>". Mr Housley replied that "I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory". Mr Hansen provided some technical details about how that can be done. The point here is it might be better to have a good answer as some IETF participant might deconstruct the answer and find the flaw in it. Mr Klensin's message was about how to find out about the 87all mailing list. Participants within the inner circle know how to find it. The rest of the participants will not be able to find that information as it is not easily accessible through the www.ietf.org<http://www.ietf.org> web site. There is probably a lack of information about what information is provided through the ietf-announce@ mailing list. Regards, -sm
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
Hi, Why couldn't remote participants register to the meeting like all other participants? Remote participation would of course still be free, but it would allow remote participants to subscribe to the attendee list in the same way as other participants. In addition, it would provide better knowledge to IETF about the number of remote participants, where they are physically located (which might be useful input when planning future meeting locations) etc. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -Original Message- From: Brian E Carpenter [brian.e.carpen...@gmail.com] To: Scott Brim [scott.b...@gmail.com] CC: John C Klensin [john-i...@jck.com]; Tim Chown [t...@ecs.soton.ac.uk]; ietf@ietf.org list [ietf@ietf.org] Subject: Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception On 25/07/2013 05:01, Scott Brim wrote: > The point of having a separate list for participants was to avoid > spamming the ietf list. > > It can be open to everyone to subscribe to, since anyone can see the > archives, HOWEVER I recommend that only registered participants be > allowed to post. Ahem. Either remote participants are allowed to post, or they need a list of their own. I would envisage a fair amount of chatter about specific remote-participation issues, like "this new codec isn't working for me, is it OK for anyone else using on ?" Brian
RE: The death John McCarthy - LISP, HIP & GSE
I am sure these are the kind of "discussions" people had in mind when they suggested that we should make better and more effective use of the e-mail lists for our work in IETF... Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dave Cridland [d...@cridland.net] Sent: Monday, October 31, 2011 7:10 PM To: Robin Whittle Cc: IETF-Discussion Subject: Re: The death John McCarthy - LISP, HIP & GSE On Sun Oct 30 09:45:43 2011, Robin Whittle wrote: > The "both" was not meant to include you But yet that's clearly what you said, suggesting that splitting hairs over whether the definite article implies a singleton, despite protestations from the authors to the contrary, is possibly not approriate either. Describing you as "Robin Whittle, the Australian engineer" would be entirely accurate, yet would not imply you are the only engineer on that continent - merely that if there were any confusion over which Robin Whittle I might be referring to, that sobriquet might assist. Similarly, referring to "LISP, the Locator/Identifier Separation Protocol" seems reasonable, and disambiguates from other uses of LISP, such as speech defects, programming languages, and so on. It does not imply, to my eyes, that the speaker believes it to be the one true protocol, any more than "lisp - the speech defect" implies that nobody must consider any other speech defect. On a final note - from me at least - if people genuinely do take offence on behalf on a deceased computer scientist because some other group of people chose to name their protocol similarly to said late scientist's programming language, I am astonished. We seem to have developed a global culture that leaps to a kind of offence-by-proxy at the slightest thing, I realise, but really, I find it hard to believe that people can be actually *offended* at the name of a protocol. Perhaps, like Robin's confusion above, I am misunderstanding what the term "offended" means. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ 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: Requirement to go to meetings
Hi, I don't have an opinion regarding the number of f2f meetings. But, as we've discussed before, I think we could make more out of the summer meetings (considering any e-mail etc activities taking place before and after them) by moving them away from the main summer vacation period. So, no meetings in july and august. Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Peter Saint-Andre [stpe...@stpeter.im] Sent: Wednesday, October 26, 2011 6:38 PM To: John C Klensin Cc: ietf@ietf.org Subject: Re: Requirement to go to meetings On 10/25/11 3:48 PM, John C Klensin wrote: > > > --On Tuesday, October 25, 2011 10:19 -0700 Fred Baker > wrote: > >> >> On Oct 25, 2011, at 8:55 AM, Ping Pan wrote: >> >>> the original issue remains: please make IETF meetings easier >>> and cheaper for us to go to. ;-) >> >> I think that a lot of people would like that. There are a >> number of problems that need to be solved to make them cheaper >> to attend. >> >> One is the issue of air fare and hotel cost; these have been >> brought up before. 25 years ago, all meetings were in the US, >> as were most of the participants. People came from Europe and >> Australia at significantly greater cost, but for the average >> attendee, putting all meetings in the US reduced meeting cost. >> It's now 25 years later, and that logic doesn't remotely start >> to work. >> ... > > Ok, Fred, let me enter one suggestion into this discussion that > would actually cut total costs, recognize and take advantage of > the observation that an increasing number of WGs are holding > virtual interim meetings, and reduce pressures on meeting time > conflicts and trying to get everything done in 4 3/4 days. > > Eliminate one of the face to face meetings entirely -- go to two > a year and either hold the 4 3/4 day schedule or, better cut it > back to four. Reducing the number of meetings a year from three to two makes sense. Naturally, we'd need to work through the implications (e.g., the NomCom schedule is defined in terms of three meetings a year). Plus, it's a natural complement to having reduced the number of maturity levels from three to two. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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: Requirement to go to meetings
> Cheaper, yes. Easier? > > Sure, a 5-hour flight to Paris sure beats a 12-hour flight to New York > plus a 4 hour flight to > Minneapolis, but you end up in Paris, and if the conference hotel is > too expensive for your > corporate budget (it usually is for mine), you have to go really far > away to find a hotel that > fits the budget and is not a fleabag. OTOH any city in the US except > the really huge ones > (NY or LA) you can find perfectly good hotels that feature breakfast, > Internet and a spacious > room for way lower than the Hilton rates, and not at all far from the > conference. In Anaheim > I found a hotel at half price at 10 minutes walk time from the Hilton. > And maybe it's just me, > but with US hotels, it's far easier to tell the fleabags from the > acceptable hotels than in > Europe. > > Asia is even tougher. Flying to Taipei will take me to Paris and Hong > Kong. And I have no > idea how to tell a good hotel from a bad one. I'll have to trust the > travel agent. ...or TripAdvisor. People from other parts of the world probably have the same problem when travelling to US, but with a little bit of research effort I think it's pretty easy to get a picture of the hotel, how far it is from the meeting etc. Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Hyatt Taipei cancellation policy?
Hi, >In the past the IETF provided a shuttle service from the >overflow hotel(s). > >It would be nice to know if one is planned for Taiwan. I don't really see why that would be needed in this case, as it seems that the public transportation options are good (at least according to Google Maps), and the distance is not that far. Also note that there ARE other alternative hotels, closer to the meeting. Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, August 31, 2011 21:06 > To: Ole Jacobsen; Dean Willis > Cc: ietf@ietf.org > Subject: RE: Hyatt Taipei cancellation policy? > > > Hi, > > Also note that, according to Google maps, it is possible to > take a bus from the overflow hotel to the meeting. It > requires a 400 meters walk from the hotel to the bus stop, > but that should be managble even for an IETF attendee... > > The total travel (walking+bus) is 13 minutes. > > Regards, > > Christer > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
Hi, Sometimes the drafts says that something SHOULD be done, but the justification is unclear to the reader, so it can be difficult to interpret the meaning correctly. So, I think it would cause less confusion if drafts made a better job of describing WHY something is a SHOULD, or MUST. Something like SHOULDBECAUSE :) Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Hector [sant9...@gmail.com] Sent: Wednesday, August 31, 2011 10:07 PM Cc: IETF discussion list Subject: Re: 2119bis Murray S. Kucherawy wrote: >> The only difference between "SHOULD" and "MAY" is that the implementor / >> deployer needs a good excuse to not implement / employ a "SHOULD." >> That's not the same as "IGNORE". > > But that's a big difference. I think some people are being cavalier > about the "good excuse" part, and that's where I have a problem. > RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words "ought", "encouraged" and "suggest strongly" can be used to connote something that is strongly urged. There is no possibility to interpret SHOULD as nothing else as an optional implementation and thus can be ignored. Of course, the presumptions are: - Faith in your engineering peers, - Due Diligence decision to decide to ignore it, and - understanding if it was implemented, it could be ignored by consumers. If that is not enough, we have a huge deployment history where SHOULDs was ignored and implemented as an option for operators, and we have history where a SHOULD was changed to a MUST and it caused problems. If your interpretation was correct, this change would not have been necessary. IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT concept and never had. If people read it that way, it probably did not cause a problem. So no big deal. But if they expected others to MUST-IMPLEMENT a SHOULD and broke down because of that expectation, then I suggest they didn't read RFC2119 correctly. ___ 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: Hyatt Taipei cancellation policy?
Hi, Also note that, according to Google maps, it is possible to take a bus from the overflow hotel to the meeting. It requires a 400 meters walk from the hotel to the bus stop, but that should be managble even for an IETF attendee... The total travel (walking+bus) is 13 minutes. Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Ole Jacobsen > Sent: 31. elokuuta 2011 0:31 > To: Dean Willis > Cc: ietf@ietf.org > Subject: Re: Hyatt Taipei cancellation policy? > > > Dean, > > Before you give up completely I would check out: > > http://wikitravel.org/en/Taipei > > Taxis are not expensive, the Metro even less so, and there > are at least some budget hotels nearby. I expect the local > hosts to provide more information soon -- they already have > some info on the website. > > I agree about the Hyatt hotel price. > > 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: o...@cisco.com URL: http://www.cisco.com/ipj > Skype: organdemo > > > On Tue, 30 Aug 2011, Dean Willis wrote: > > > On 8/23/11 9:24 AM, John C Klensin wrote: > > > > > > So I'm opposed to a USD 200 (or any other number) firm limit on > > > hotel rates. At the same time, I continue to wish that the IAOC > > > would be more open with the community about how these > decisions are > > > made and, in particular, how the tradeoffs between > sponsorship (and > > > hence lower costs to the IETF for meeting infrastructure and > > > arrangements) and meetings costs to attendees are made... open > > > enough that the community could give substantive guidance on the > > > subject, guidance that I assume the IAOC would follow if it were > > > coherent and plausible. > > > > > > > Quite right. There's more than just the hotel rates. > > > > My budget is about $2500 US per IETF meeting. That has to cover > > airfare, the IETF meeting fee, the hotel, meals, service charges, > > ground transport, mobile phone roaming, incidentals, etc. > > > > $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF > > THE FREAKING QUESTION. Having the "backup" hotel a 10 > minute taxi ride > > away is out of the question -- I can't afford taxis. If I > can't walk, I can't go. > > > > So guess what? I told the wife last night that I wasn't > planning to go > > to the Taiwan meeting. I wanted to go, but I just don't see > how it can > > happen. Maybe I'll win the lottery between now and then... > > > > I'm disappointed. I'm hurt. I'm angry. And the trend has just been > > getting worse and worse with every venue. I want the IAOC's > heads on a > > platter (preferably an inexpensive, disposable platter, > like maybe the > > lid off an old pizza box) for signing us up to this venue. > And I want > > a travel budget no larger than mine for the people we send > to future meetings. > > > > If we can't find a reasonably inexpensive place to have a meeting, > > DON'T HAVE THE MEETING! > > > > > > -- > > Dean Willis > > ___ > > 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: Hyatt Taipei cancellation policy?
...and, at least in this case, if you look at similar hotels (e.g. the Starwood properties) in the area, you'll find that even the current pre-book-non-refundable-no-breakfast-in-some-cases-no-internet rates will be higher than the rate offered to us. There are also cheaper hotels, so it's all about having the benefits of staying at/very-close-to the meeting, or having to do some walk. > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Andrew Sullivan > Sent: 23. elokuuta 2011 23:34 > To: ietf@ietf.org > Subject: Re: Hyatt Taipei cancellation policy? > > On Tue, Aug 23, 2011 at 11:29:34AM -0700, David Morris wrote: > > > For this to be a meaningful disccusion re. the success or > lack there > > of, we need to compare what we have vs. similar sized groups in the > > same season, etc. at the same venue. > > _And_ having negotiated at the same time, as Ray pointed out > already in this thread. Every time one of these discussions > comes up, people seem to forget that the negotiations are > happening several years in advance of the actual event. > Agreements about the future almost always require the party > buying to take some risk that they will be paying more than > the going rate at the time the actual sale date arrives. In > the case of hotel agreements, the block negotiator takes some > risk that there will be a lower price or otherwise better > terms actually available at the time of the block being used. > The hotel takes some risk that the block negotiator is > unable to deliver the actual room occupancy negotiated. Each > is making a bet. > > If you don't like the cancellation terms (or other terms of > the bet), don't participate in it: don't make a reservation > in the IETF block. > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com > ___ > 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: "technical" plenary [was: A modest proposal for Friday meeting schedule]
>>In any case, the IRTF Report, IAB Report and RSOC Report could certainly be >>made in the other plenary. > >Or omitted entirely, since they are duplicative of data which would be better >communicated in writing. ...and/or use some Internet technology, by producing YouTube report videos, that people can watch whenever they have time :) Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: whine, whine, whine
>>* There is no usable bus from the airport (it runs only at commuter >> hours) and a taxi costs C$32.50 > >You're absolutely right about this. The people of Québec are >not happy about this situation and often complain in the >media. It makes for a bad first impression. We'll try to >organize taxi pools somehow, stay tuned and read 81attend...@ietf.org. > >Assuming the others bullets were jokes... ;) One could wish so, but you obviously haven't seen what kind of things people use to whine about when it comes to IETF meetings... :) Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
Cullen, When we last talked, you said that your main is the fact that unreliable responses might be sent even in the case of Require:100rel. That has now been solved, so I am very surprised by your comments. Also, the draft WAS back in the WG when the proposed solution was presented. Why didn't you say anything then Regarding the usage, I have been provided text (mostly by Robert) regarding the usability, limitations etc. Why haven't you said anything before if you didn't like it Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Cullen Jennings > Sent: 7. helmikuuta 2011 20:45 > To: IESG IESG; ietf@ietf.org IETF > Subject: Re: Last Call: > (Session Initiation Protocol (SIP) Response Code for > Indication of Terminated Dialog) to Proposed Standard > > > I was somewhat surprised to see this back in LC. I am still > not aware of any use case where this actually helps. I > searched the IETF and WG lists for email with the subject > draft-ietf-sipcore-199 and I do not see a single email that > suggests there is support for this draft or the changes in it > since the previous LC. > > This draft has no use that I understand how it helps - it is > at best a very limited optimization. The SIP standards is > already too complicated with too many extensions. I believe > this draft makes SIP worse.Thought the draft mandates that > systems need to work even when the 199 are lost, I do not > think that is how the proponents of the work intent to use. I > could be very wrong but I presume that people intent to use > to control middle boxes that control media gates. It's broken > for that but given that is not discussed in the draft, it's > hard to discuss how it is broken and what would be needed to fix it. > > I do not support publishing this draft as standards track > without actual WG discussion on what the problem is this > draft solves and if there is WG consensus that problem is > worth solving. > > > On Feb 7, 2011, at 10:02 AM, The IESG wrote: > > > The IESG has received a request from the Session Initiation > Protocol > > Core WG (sipcore) to consider the following document: > > - 'Session Initiation Protocol (SIP) Response Code for Indication of > > Terminated Dialog' > > as a Proposed Standard > > > > This is the second IETF last call for this document. The > previous last call was on version -02. > > While resolving review comments, an issue with the > interaction of the > > 199 response and the 100rel extension was identified and > addressed by > > the SIPCORE working group. A full summary of the changes > are available in section 13 of the document. > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive > comments to the > > ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, > comments may > > be sent to i...@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > This specification defines a new Session Initiation Protocol (SIP) > > response code, 199 Early Dialog Terminated, that a SIP > forking proxy > > and a User Agent Server (UAS) can use to indicate towards upstream > > SIP entities (including the User Agent Client (UAC)) that an early > > dialog has been terminated, before a final response is > sent towards > > the SIP entities. > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > ___ > > IETF-Announce mailing list > > ietf-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > ___ > 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-sipcore-keep-10
Hi Roni, >Summary: This draft is almost ready for publication as a Standard track RFC. > >Major issues: > > >Minor issues: > >1. In the document you mention that the keep alive can be negotiated in each >direction. I understand the dialog case, is this true >for the case of registration, if yes how is it done from the registrar. If not >true maybe add some text in 4.2.2. Good point. It is NOT true for the case of registration, when sending of keep-alives can only be negotiated from the registering party to the registrar. I suggest adding the following text to the end of section 4.2.2: "NOTE: Sending of keep-alives associated with a registration can only be negotiated in the direction from the registering SIP entity towards the registrar." - >Nits/editorial comments: > >1. In section 4.1 in the first note “If a SIP entity has indicated >willingness to receive keep-alives from an adjacent SIP entity, >sending of keep-alives towards the same SIP entity needs to be separately >negotiated”. > >Who is the same SIP entity mentioned in the end of the sentence. I assume you >meant “towards the adjacent SIP entity”. (I assume you mean "Why" instead of "Who") You are correct. I propose to change to: "towards that adjacent SIP entity", to make sure that the text is referring to the entity that indicated willingness to send keep-alives, and not some other adjacent SIP entity. >2. In the first paragraph of 4.3 and 4.4 you use “must” should it be “MUST” As far as I know it shall be "must" when referring to something defined in another specifiction. >3. In 4.3 in the third paragraph “it MUST start to send keep-alives” change >to “it MUST start sending keep-alives” I'll change as suggested. >4. In figure 2 in the 200 OK response to Alice the VIA is missing. Correct. I'll change "Alice: UAC;keep=30" to "Via: Alice;keep=30". >5. In section 7.4 third paragraph “ When Alice receives the response, she >determines from her Via header >field that P1 is willing to receive keep-alives associated with the dialog.” >Should be Bob and not P1. Correct. I'll change as suggested. Thanks for your comments! Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: All these discussions about meeting venues
Hi, >>I might add that if the excluded party feels this is oppressive, I am >>sorry. It is not intended to be. But, at some level, sooner or later, >>you have to be willing to say "I'm the problem here, not the remaining >>999 people who have lesser constraints" > >So, if some venues work quite well, and some pose great difficulties for a >minority, we should ignore this (presumably because of the charm of the >difficult ones). I think one question is: WHO is responsible for dealing with a specific "problem"? Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft new version: draft-ietf-simple-msrp-sessmatch [was: secdir review of draft-ietf-simple-msrp-sessmatch]
Hi, Based on the secdir comments/discussions regarding sessmatch, we have submitted a new version of the draft (-07). The major changes are: - It is clarified that the MSRP URI comparison rules are not changed, and that the rules are not used for session matching - It is clarified that the draft does not change the TLS authentication mechanisms, and that there are some existing usage restrictions that the draft does not solve. Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: All these discussions about meeting venues
Hi, >One suggestion for Beijing where the level of English with bus/taxi drivers >etc will be low maybe to publish a page linked from the main meeting page with >something like "Can you please take me to the >Shangri-La Hotel" in Chinese so attendees can just print it out and hand it to >the driver when they land at the airport (although a quick search reveals many >free online translators I suspect this could >catch a few people out). If you look, you'll find an info card on the hotel web page, with a map and names written in english and chinese. It is always good to have a map, in case the driver doesn't know the place based on the address. Also, if you want to go somewhere from to hotel, my experience is that the hotel staff is always very willing and helpful to write down the name of the place where you want to go in chinese, and/or even explain to the taxi driver where you want to go. Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi, I think Ben gave my clarification :) Regards, Christer > -Original Message- > From: Ben Campbell [mailto:b...@estacado.net] > Sent: 9. syyskuuta 2010 1:15 > To: Christer Holmberg; Cullen Jennings > Cc: draft-ietf-simple-msrp-sessma...@tools.ietf.org; Ted > Hardie; IESG IESG; The IETF; sec...@ietf.org > Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch > > (as individual) > > On Sep 2, 2010, at 8:37 AM, Christer Holmberg wrote: > > > Hi Cullen, > > > >> Do these changes allow an SBC on the signaling path to change the > >> contents of the MSRP messages without the end points being able to > >> detect that? I'm sure it will be easier to answer this > once we have a new draft. > > > > Sessmatch does not make it any easier for an SBC in the > signalling path to change the content of the MSRP messages. > > > > For an SBC to do MSRP message modification it will have to > implement MSRP B2BUA functionality - no matter if sessmatch > is supported by the endpionts or not. > > I'm going to have to push on this one a little bit: > > I think it _does_ make it easier for an SBC to change MSRP > messages because it makes it easier for the SBC to put itself > into the media path in the first place. This is no different > than for any other sort of media. > > The need to implement MSRP b2bUA functionality exists if the > SBC changes the To-Path and From-Path headers. It may or may > not be required if it wants to change _bodies_, depending on > whether that change requires chunk-reassembly or changes the > length of the body. And assuming, of course, there is no > end-to-end protection on the MSRP messages in the first > place--and we all know that in practice there probably won't be. > > I think what Christer is talking about is, if sessmatch did > not exist, then if an SBC were to insert itself into the MSRP > media path, it would be _forced_ then to rewrite the To-Path > and From-Path in each MSRP request to match the change it > made in the SDP. If it did not do so, the endpoints would > detect the change and treat it as an error. That is, > sessmatch does not enable the insertion in the first > place--it just makes things cheaper from a processing perspective. > > Note that any end-to-end integrity protection on the SDP, > such as RFC4474 or s/mime, will prevent SBC insertion, with > or without sessmatch. Just like for any other media. > > > > > > Regards, > > > > Christer > > ___ > > 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: Optimizing for what? Was Re: IETF Attendance by continent
>>Personally I don't care that much where the meetings take place - I am >>more interested WHEN they take place. For me it is the PEOPLE that >>make a meeting good or bad - not the location. There are people >>working in much worse conditions than we are, and still >>they manage to >>do a great job. > >Humans can do amazing things in truly abysmal conditions but >how this is relevant is beyond me unless the contest is to >see how miserable we can make ourselves (3 meetings/year in >Minneapolis, anyone?). The point is that we in IETF are a bunch of lazy and spoiled children. I am not saying that we should see how miserable we can make ourselves on purpose. I am saying that if there is a will, there is a way. Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Optimizing for what? Was Re: IETF Attendance by continent
I guess the chinese (and other affected nationalities) can speak for themselves, but as far as I know it is not that easy to get a US visa - even with company backup etc. I have never heard about people having problems getting a chinese visa, but maybe such problems exist also. Personally I don't care that much where the meetings take place - I am more interested WHEN they take place. For me it is the PEOPLE that make a meeting good or bad - not the location. There are people working in much worse conditions than we are, and still they manage to do a great job. Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Yoav Nir > Sent: 6. syyskuuta 2010 10:06 > To: IETF-Discussion list > Subject: RE: Optimizing for what? Was Re: IETF Attendance by continent > > True. > > But the visa issues seem to be the worst part of any US IETF. > Travel, food and finding a hotel are typically much easier in > most US venues then European venues. > > People from Europe, Japan, Australia, and some other > countries don't need a visa at all to go to an IETF meeting > in the US. People from China, India and the other countries > are generally backed by employers, who can vouch for their > travelling "on business", and generally should not have any > trouble obtaining the US visa. > > I would go so far as to say that getting a US visa seems > easier than getting one to China. Who are the people for whom > it's easier to visit a European country than it is to visit the US? > > On balance, I think US venues are generally better suited, > and lead to less angst than either European or Asian venues. > Even if they're in a cold place like Minneapolis. > > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Christer Holmberg > Sent: 06 September 2010 08:17 > To: Andrew G. Malis; Glen Zorn > Cc: Randall Gellens; IETF-Discussion list; Hadriel Kaplan > Subject: RE: Optimizing for what? Was Re: IETF Attendance by continent > > > Hi, > > I assume Hawaii has the same visa issues as the rest of US... > > Regards, > > Christer > > > > ___ > 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: Optimizing for what? Was Re: IETF Attendance by continent
ICE? So, that's the reason why it takes forever to enter US. They use RFC 5245 at the border... Regards, Christer > -Original Message- > From: Glen Zorn [mailto:g...@net-zen.net] > Sent: 6. syyskuuta 2010 10:21 > To: Christer Holmberg; 'Andrew G. Malis' > Cc: 'Randall Gellens'; 'IETF-Discussion list'; 'Hadriel Kaplan' > Subject: RE: Optimizing for what? Was Re: IETF Attendance by continent > > Christer Holmberg [mailto:christer.holmb...@ericsson.com] writes: > > > Hi, > > > > I assume Hawaii has the same visa issues as the rest of US... > > Of course, and the same heavily armed ICE agents. As an > aside, the only other place I've ever encountered armed > border guards was at the Austrian/Slovakian border (before > the fall of the Berlin Wall). > > ... > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Optimizing for what? Was Re: IETF Attendance by continent
Hi, I assume Hawaii has the same visa issues as the rest of US... Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Andrew G. Malis > Sent: 6. syyskuuta 2010 1:39 > To: Glen Zorn > Cc: Randall Gellens; IETF-Discussion list; Hadriel Kaplan > Subject: Re: Optimizing for what? Was Re: IETF Attendance by continent > > I've been to several conferences at the Hilton Hawaiian > Village in Waikiki. Both the hotel and the attached > convention center are large enough to host several IETFs > simultaneously. > > Cheers, > Andy > > On Tue, Aug 31, 2010 at 11:08 PM, Glen Zorn wrote: > > Hadriel Kaplan [mailto://hkap...@acmepacket.com] writes: > > > > ... > > > >> > > >> > Why Kauai? You list detailed reasons why Hawaii is logical and > >> > solves for many of the problems, but you don't say why > this island. > >> > >> Because it's the nicest, obviously. :) > > > > I strongly disagree: the leeward coast of Maui (in > particular, Kihei & > > south) is far better. Kauai is way too rainy... > > > >> > >> > >> > > >> >> We can even rotate islands if people get bored. > >> > > >> > Well, there are extensive conference facilities on Oahu, the Big > >> > Island, Maui, and Kauai. I have no information as to if > they would > >> > work for a group of our size and with our need for > breakout rooms. > >> > >> I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in > >> Poipu) every few years, but they were a smaller group. There aren't > >> many restaurants nearby, but I certainly don't remember > anyone ever > >> complaining about it. ;) > > > > 3GPP2 used to (still does?) meet in Wailea every December. Although > > that is also a much smaller group than the IETF, the hotels > dwarfed it > > so it might be possible to find a reasonable venue for the IETF. > > However, I think that this is just an idle fantasy: the > IETF has too > > much moral fiber to meet someplace that might actually be fun ;-). > > > >> > >> -hadriel > >> ___ > >> 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 > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi Cullen, >Do these changes allow an SBC on the signaling path to change the contents of >the MSRP messages >without the end points being able to detect that? I'm sure it will be easier >to answer this once we have >a new draft. Sessmatch does not make it any easier for an SBC in the signalling path to change the content of the MSRP messages. For an SBC to do MSRP message modification it will have to implement MSRP B2BUA functionality - no matter if sessmatch is supported by the endpionts or not. Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi Ted, Comments inline. >Thanks for your message and your consideration of the points I raised. >Given the scope of changes below, my first suggestion is that the author team >actually >go ahead with a draft incorporating these changes, so that we can discuss >based on the actual text. I also suspect that a second last call will be >necessary as >a result. Yes, we intend to do that. >> GENERAL >> === >> >> First, the draft does NOT propose any changes to the TLS authentication >> procedures – that will be clarified. The changes are only related to the >> procedure for matching an incoming MSRP message to an MSRP session that >> has been negotiated using SDP – once any TLS authentication procedure has >> already taken place. >> >> So, in case of TLS and name based authentication, if an SBC/ALG modifies >> the a=path MSRP URI, the TLS authentication WILL fail. That is the current >> behavior, and sessmatch doesn’t change that. >> >> We understand that this fact needs to be clearly indicated in the draft. >> >> Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs >> and SIP aware firewalls can be in the SIP signaling path without acting as >> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays >> the SBC/ALG needs to act as MSRP B2BUA, as today. >> >> Sessmatch aims to extend the usability of MSRP peer to peer communication to >> scenarios where simple ALGs/SBCs are used, and at least in our experience >> customer interest for standard MSRP has grown (from more or less zero) >> dramatically due to sessmatch. And, OMA, which previously used a >> *non-standard* >> version of MSRP (with no interoperability with standard MSRP), has also >> agreed >> to switch to sessmatch (even if it required a number of changes in their >> specifications). >> >> Second, the intention of sessmatch is not to modify the MSRP URI matching >> rules, >> but rather to not use MSRP URI matching for session matching. >> > >This is the key point in your message, at least from my perspective. >This basically means that all of section 6 of RFC 4975, which clearly >describes those URIs >as the session identifiers: > > > URIs using the "msrp" and "msrps" schemes are used to identify a > session of instant messages at a particular MSRP device, as well as > to identify an MSRP relay in general. > >needs to be replaced and all the logic that depends on it must be reviewed. >The current >draft does not indicate that section 6 is being normatively updated, >and yet this is the key point of the work. You are moving from a >namespace-scoped identifier to an >unscoped identifier, and you will require both justifications of that (some >given below) >and mechanics for that described in more detail. Section 6 does also say: "The session-id part identifies a particular session of the participant." ...and: "The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself." So, I guess some additional text regarding the userinfo component might be needed. We'll look into it. >In particular, I do not believe it is clear in the discussion so far whether >the identifier may ever be scoped by the authority section >of the URI or whether it is always treated as unscoped. If the latter, it is >unclear to me >whether the right notion here isn't simply to create a new non-URI identifier. Well, that would not be backward comaptible, would it? As we said, as long as there are no SBCs in the path, sessmatch is fully backward compatible with RFC 4975. Of course, we could define a new MSRP message element, but wouldn't we then also need an option-tag in order to require the remote endpoint to support it? >> Please also note that when we talk about SBCs/ALGs, we refer to entities that >> normally do NOT have the capability to act as MSRP B2BUAs. >> >> We will comment the individual comments based on the assumptions above. >> >> >> Comments from Richard >> = >> >>>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 changes the URI matching algorithm used in MSRP. MSRP sessions >>>are typically initiated using SDP bodies in SIP. These SDP >>>bodies contain MSRP URIs that the peers use to contact each other. >>>When one peer receives a request to initiate a session, he verifies that the >>>URI being requested is one that he initiated in SDP, thereby using the URI >>>as a >>>shared secret to authenticate that the originator of the session actually >>>received the SDP body in question. >>> >>>According
RE: IETF Attendance by continent
Hi, I agree with Jari. In my opinion, the discussion whether we should change the meeting calendar (not having meetings during summer vacation months etc) was much more interesting and useful. Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Jari Arkko > Sent: 2. syyskuuta 2010 0:07 > To: ietf@ietf.org > Subject: Re: IETF Attendance by continent > > I think we are over-analyzing this. Do not be too focused on > the numbers, or whether current points to > 1, 1.7, or 2. I think it is more important to think about > where the IETF is headed and where Internet and networking > work seems to be happening in the world. > From that perspective I would personally prefer to see > 1:1:1, and in any case, > venue/contract/sponsor/planninghorizon/unforeseenevent > probably cause more fluctuation than what our possible more > fine-grained policy would give. > > In other words, "close enough" and let the IAOC worry about > the details. > > 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
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi, The purpose of this e-mail is to address the secdir comments given by Richard Barnes and Ted Hardie. Due to summer vacations, standardization meetings etc it took a while to put the e-mail together, and we appologise for that. GENERAL === First, the draft does NOT propose any changes to the TLS authentication procedures – that will be clarified. The changes are only related to the procedure for matching an incoming MSRP message to an MSRP session that has been negotiated using SDP – once any TLS authentication procedure has already taken place. So, in case of TLS and name based authentication, if an SBC/ALG modifies the a=path MSRP URI, the TLS authentication WILL fail. That is the current behavior, and sessmatch doesn’t change that. We understand that this fact needs to be clearly indicated in the draft. Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs and SIP aware firewalls can be in the SIP signaling path without acting as MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays the SBC/ALG needs to act as MSRP B2BUA, as today. Sessmatch aims to extend the usability of MSRP peer to peer communication to scenarios where simple ALGs/SBCs are used, and at least in our experience customer interest for standard MSRP has grown (from more or less zero) dramatically due to sessmatch. And, OMA, which previously used a *non-standard* version of MSRP (with no interoperability with standard MSRP), has also agreed to switch to sessmatch (even if it required a number of changes in their specifications). Second, the intention of sessmatch is not to modify the MSRP URI matching rules, but rather to not use MSRP URI matching for session matching. Please also note that when we talk about SBCs/ALGs, we refer to entities that normally do NOT have the capability to act as MSRP B2BUAs. We will comment the individual comments based on the assumptions above. Comments from Richard = >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 changes the URI matching algorithm used in MSRP. MSRP sessions >are typically initiated using SDP bodies in SIP. These SDP >bodies contain MSRP URIs that the peers use to contact each other. >When one peer receives a request to initiate a session, he verifies that the >URI being requested is one that he initiated in SDP, thereby using the URI as a >shared secret to authenticate that the originator of the session actually >received the SDP body in question. > >According to the current SDP specification, this comparison is performed over >the whole URI; this document restricts the comparison to the "session-id" >component, omitting the host, port, and transport components. The goal of the >document is to facilitate a certain class of man-in-the-middle attack, namely >to allow a signaling intermediary to insert a media intermediary. The >restriction on the URI comparison is needed in order for the media intermediary >not to have to modify URIs in MSRP packets to reflect the modifications to URIs >in SDP bodies performed to redirect traffic through the media intermediary. When an MSRP UA receives an MSRP packet it performs msrp session matching in order to verify that the msrp packet belongs to an existing SDP negotiated msrp session at the UA. RFC4975 prescribes that URI matching should be used for session matching. We argue that the namespace scoping of the session-id values that use of URI matching brings is unnecessary. The 80-bit randomness of the session-id and the fact that it was the UA itself that decided on the session-id value and can ensure that it is unique within the UA makes the session-id sufficiently unique for session matching. Sessmatch is not changing the MSRP URI matching algorithm, it is changing the session matching algorithm not to use MSRP URI matching. >I have a few significant reservations about this document: > >1) This extension makes it more difficult for MSRP entities to secure their >communications against attackers in the signaling path. The current model >provides a basic integrity protection, in that signaling intermediaries cannot >redirect traffic to an arbitrary third party; they must at least advise the >third party about how to modify MSRP packets. The proposed modification would >remove even this cost. If we do not introduce the sessmatch change then the only alternative for MSRP connections to be able to be set up when SBCs or SIP aware firewalls are in the SIP signaling path is for these to introduce MSRP B2BUA support. This is probably not feasible for most SBCs and SIP aware firewalls, and if it actually were feasible then it would mean as big a security problem, or
RE: IETF Attendance by continent
+1. Regards, Christer > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Jari Arkko > Sent: 10. elokuuta 2010 9:20 > To: IETF discussion list > Subject: Re: IETF Attendance by continent > > FWIW, I do think that choice of July as the meeting time is > not the best in terms of avoiding collisions with people's > vacations. Say, early June or September would probably have > less conflicts with family vacations, daycare shutdown > periods, and the like. It would probably make it possible for > more people to join the meeting. Of course, any change in the > meeting dates would be slow. The current meeting calendar > goes to November 2017... > > 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
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi, We have some ideas on how to address the issues and move forward, but due to summer vacations we will unfortunately most likely not be able reply to Ted's and Richard's e-mails before august. Just to let you know. Regards, Christer > -Original Message- > From: Ted Hardie [mailto:ted.i...@gmail.com] > Sent: 29. kesäkuuta 2010 20:37 > To: Christer Holmberg > Cc: Richard L. Barnes; sec...@ietf.org; i...@ietf.org; The > IETF; draft-ietf-simple-msrp-sessma...@tools.ietf.org > Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch > > In-line. > > On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg > wrote: > > > > Hi Ted, > > > >>I join Richard in believing that this document makes changes beyond > >>that which could be understood as "updating" the MSRP URI scheme > >>processing. > >> > >>To highlight one particular aspect, RFC 4975 does not require > >>session-ids to be present, a fact noted both in the ABNF > and in this > >>text: > >> > >>4. The session-id part is compared as case sensitive. A URI without > >> a session-id part is never equivalent to one that includes one. > >> > >>A matching scheme which relies on a URI section which is not > >>guaranteed to be present has some interesting problems > ahead of it. If > >>this effectively makes their use mandatory, that requires a > change to > >>the fundamental ABNF and text. > > > > An MSRP URI in an SDP offer or answer for an MSRP session > MUST include a session-id part, so I believe the comment is > >based on incorrect assumptions. > > This is not indicated in the URI matching sectio > > > > > > Section 6 of RFC 4975 says: > > > > "The session-id part identifies a particular session of the > > participant. The absence of the session-id > > part indicates a reference to an MSRP host device, but > does not refer to a particular session at that device." > > > > The full section from which that quote is taken is: > >The MSRP URI authority field identifies a participant in a > particular >MSRP session. If the authority field contains a numeric > IP address, >it MUST also contain a port. The session-id part identifies a >particular session of the participant. The absence of the > session-id >part indicates a reference to an MSRP host device, but > does not refer >to a particular session at that device. A particular value of >session-id is only meaningful in the context of the associated >authority; thus, the authority component can be thought of as >identifying the "authority" governing a namespace for the > session-id. > > This proposal changes the concept of a namespace authority > present in the URI matching section of RFC 4975. I am sorry > if my wry reference to this in my previous message was hard > to follow; I should have known better. > To be more plain, this proposal fundamentally changes the > matching semantics of the URI set out in RFC 4975, by > requiring a match on only a portion of the URI. At a bare > minimum, this would require noting a normative update to > section 6 and 6.1 of RFC 4975, which this draft does not do. > In reality, this is unlikely to be sufficient, as URI > matching semantics do not generally have the concept of > ignoring the authority in providing a match (at least in my > reading of the RFC > 3986 "ladder of comparison" text). That means you'd have to > special case the MSRP matching semantics, rather than have > the URI be parsed and compared using a standard library. > > Creating a new URI scheme without re-using authority may be a > better approach; this would require more work, but it is > cleaner than this appears to be. > > > > >>I also note that the security considerations, in addition to having > >>some fairly disingenuous language about the impact of this change, > >>seems to fail to mention MSRPS URIs and what, if any, impact this > >>would have on them. > > > > There are no impacts to MSRPS URIs. I assumed it would be > implicitly understood since MSRPS URIs are not mentioned in the draft. > > > > However, we could explicitly make it clear by modifying the > first sentences of section 5: > > > > "The change of session matching procedure does not impact the > > format of MSRP URIs, > > disregarding if the "msrp" scheme or the "msrps" > scheme is used. > > However, MSRP endpo
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi Ted, >I join Richard in believing that this document makes changes >beyond that which could be understood as "updating" the MSRP >URI scheme processing. > >To highlight one particular aspect, RFC 4975 does not require >session-ids to be present, a fact noted both in the ABNF and >in this text: > >4. The session-id part is compared as case sensitive. A URI without > a session-id part is never equivalent to one that includes one. > >A matching scheme which relies on a URI section which is not >guaranteed to be present has some interesting problems ahead >of it. If this effectively makes their use mandatory, that >requires a change to the fundamental ABNF and text. An MSRP URI in an SDP offer or answer for an MSRP session MUST include a session-id part, so I believe the comment is based on incorrect assumptions. Section 6 of RFC 4975 says: "The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device." >I also note that the security considerations, in addition to >having some fairly disingenuous language about the impact of >this change, seems to fail to mention MSRPS URIs and what, if >any, impact this would have on them. There are no impacts to MSRPS URIs. I assumed it would be implicitly understood since MSRPS URIs are not mentioned in the draft. However, we could explicitly make it clear by modifying the first sentences of section 5: "The change of session matching procedure does not impact the format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used. However, MSRP endpoints can only check that the session-id part of the MSRP URI..." Regards, Christer > On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes > wrote: > > 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 changes the URI matching algorithm used in > MSRP. MSRP > > sessions are typically initiated using SDP bodies in SIP. > These SDP > > bodies contain MSRP URIs that the peers use to contact each other. > > When one peer receives a request to initiate a session, he verifies > > that the URI being requested is one that he initiated in > SDP, thereby > > using the URI as a shared secret to authenticate that the > originator > > of the session actually received the SDP body in question. > > > > According to the current SDP specification, this comparison is > > performed over the whole URI; this document restricts the > comparison > > to the "session-id" component, omitting the host, port, and > transport components. > > The goal of the document is to facilitate a certain class of > > man-in-the-middle attack, namely to allow a signaling > intermediary to > > insert a media intermediary. The restriction on the URI > comparison is > > needed in order for the media intermediary not to have to > modify URIs > > in MSRP packets to reflect the modifications to URIs in SDP bodies > > performed to redirect traffic through the media intermediary. > > > > I have a few significant reservations about this document: > > > > This extension makes it more difficult for MSRP entities to secure > > their communications against attackers in the signaling path. The > > current model provides a basic integrity protection, in > that signaling > > intermediaries cannot redirect traffic to an arbitrary third party; > > they must at least advise the third party about how to modify MSRP > > packets. The proposed modification would remove even this cost. > > Moreover, it raises the cost of providing integrity protection to > > messages, since Alice must now employ both integrity and > > confidentiality protections on an end-to-end basis; if her messages > > are only integrity-protected, then a proxy can remove the > integrity protection and redirect traffic without it being > observable to Alice. > > > > The document needs to clarify what the impacts are for > authentication > > in secure modes of MSRP. In particular: > > -- The distinction between "self-signed" and "public" > certificates is > > inappropriate. The proper distinction is between the name-based > > authentication in Section 14.2 of RFC 4975 and the > fingerprint-based > > authentication in Section 14.4. -- In either case, changing > the host > > name need not result in an authentication failure, since the media > > intermediary can simply authenticate as itself to both endpoints, > > having changed the respective MSRP URIs appropriately. > > -- There is currently no requirement that a
RE: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard
Hi, I am not I understand what this draft has to do with MITM attacks. This is related to which MSRP UA becomes "active", by applying COMEDIA. ACM is a separate thing from SESSMATCH - which is the reason the WG decided to split it into two drafts in the first place (originally ACM and SESSMATCH was a single draft). Regards, Christer From: simple-boun...@ietf.org [simple-boun...@ietf.org] On Behalf Of Cullen Jennings [flu...@cisco.com] Sent: Monday, June 07, 2010 7:34 PM To: ietf@ietf.org Cc: sim...@ietf.org; IETF-Announce Subject: Re: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard I can not see why this draft is needed other than making MITM attacks easier. I request that this not proceed until we can figure out what is going to happen to draft-ietf-simple-msrp-sessmatch then decide if these changes to MSRP are needed or if the existing mechanism are sufficient. On Jun 7, 2010, at 8:39 AM, The IESG wrote: > The IESG has received a request from the SIP for Instant Messaging and > Presence Leveraging Extensions WG (simple) to consider the following document: > > - 'An Alternative Connection Model for the Message Session Relay Protocol > (MSRP) ' >as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, > comments may be sent to i...@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-09.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18161&rfc_flag=0 > > ___ > Simple mailing list > sim...@ietf.org > https://www.ietf.org/mailman/listinfo/simple Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) to Proposed Standard
Hi, The intention is not to "mandate" that MSRP allows man in the middle attacks. The text simply states that it doesn't change what can already be done. If you think that the text gives a wrong picture regarding that, and what is possible what to protect with SIP, I am happy to modify the text. Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Cullen Jennings [flu...@cisco.com] Sent: Monday, June 07, 2010 7:31 PM To: IETF Mailing List; IESG IESG Subject: Re: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) toProposed Standard This draft is a standards track update to MSRP that mandates that MSRP allow man in the middle attacks. I am strongly opposed to this change and feel that it would be a violation of the spirit of BCP 61 as well as just a bad idea. The "security is OK" is based on the idea that MITM attacks are already possible so this makes it now worse - see section 5 where it says However, since a man-in-the-middle would in any case be able to modify the domain information in both the SDP and the MSRP messages" I don't agree with the assumption that SIP can not protect against MITM attacks and therefore it is OK to mandate support for MITM attacks in MSRP. Who did the security review for this draft? Cullen On Jun 7, 2010, at 8:40 AM, The IESG wrote: > The IESG has received a request from the SIP for Instant Messaging and > Presence Leveraging Extensions WG (simple) to consider the following document: > > - 'Session Matching Update for the Message Session Relay Protocol (MSRP) ' >as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, > comments may be sent to i...@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19446&rfc_flag=0 > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.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: China blocking Wired?
Hi, I've been to China a few times, entering 2 different airports, and personally I've never had any issues with immigration. It's always been fast and without hassle. No what-are-you-doing-here type of questions. No look-into-the-camera. No put-your-finger-here. Only a quick look at the passport and a "Ok" :) And, no checking of the luggage or questions regarding what stuff I'm carrying. At least once I've had a couple of lap-tops with me. Regards, Christer From: "Spencer Dawkins" To: "Dean Willis" , "John C Klensin" Reply-to: spen...@wonderhamster.org Subject: Re: China blocking Wired? X-RSN: 1/0/933/11208/49983 X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=933&k2=49983 I try not to follow up to postings on this topic, but since I can comment on specifics... >> Many of us have been to China multiple times. I am not aware of >> anyone who has been granted a business or professional visa, and >> who has gone and behaved professionally, having nearly the >> problems with entry or exit that have been typical of the US in >> recent years (even returning US citizens). I've encountered >> some long lines, bad multilingual signage, and miscellaneous >> confusion on occasion, but China clearly has no monopoly on >> those. > > For example: As I understand it, one is allowed to bring only one camera > and one computer, not two of each. Will this affect camera-and- computer > loving IETFers? Possibly, if it's still true. Does the camera in your > cell phone count against the quota? How about the one built in a Macbook? Nope. I entered China in November (Shanghai, for an IPv6 transition workshop the week before IETF 76) with the same two computers that I usually carry to IETF meetings - my work laptop, and an ASUS netbook that I use to drive projectors (which also has a webcam built in), and a cell phone that has a camera built-in, along with my camera. I was admitted to China with no discussion of any of these items. Past performance is not an indicator of future topics of interest, but that's the way it went. Thanks, Spencer, who is amazed that the lines to enter the US from Matamoros are longer than the lines to enter China in either Hong Kong or Shanghai... and move more slowly, even for US citizens! ___ 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: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability Negotiation) to Proposed Standard
>Except in closed situations like 3GPP, how would the UA know whether to insert this new attribute? Those who think that the current behavior does not cause problems do not need to care about the attribute :) And, even in the current text: how does the UA know whether it needs to send the second "synchronization" offer? I guess one option is to provision it. Regards, Christer > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf > > Of Ingemar Johansson S > > Sent: 07 October 2008 13:38 > > To: ietf@ietf.org > > Cc: Flemming Andreasen; Ingemar Johansson S; > [EMAIL PROTECTED]; Christer > > Holmberg > > Subject: RE: [MMUSIC] Last Call: > > draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability > > Negotiation) to Proposed Standard > > > > Hi > > > > In draft-ietf-mmusic-sdp-capability-negotiation it is proposed that > > the transport in the m-line is modified in the SDP answer. > While this > > is a good idea in order to reduce the number of > offer/answer exchanges > > it can in fact cause problems with intermediaries that for instance > > compare offer and answer SDP's. The problem may be > exacerbated further > > with the addition of extensions to the framework. > > > > Section 3.12 in the draft says: > > "The solution to this problem is to upgrade the intermediary to > > support the SDP Capability Negotiation framework". > > We find the conclusion unsatisfactory as the problem is that such > > upgrades are not done overnight and there will therefore, for a > > foreseeable future, exist middleboxes in the network that does not > > understand the SDP Capability Negotiation Framework. > > > > Our proposal to solve this issue is to introduce an > indicator in the > > SDP that tells that the actual configuration MUST only be > indicated on > > the a=acfg line. A proposed SDP attribute for this may be > > "a=spdcapneg-acfg-indication-only". > > > > In essence it means that (if the indicator is included in > the SDP) the > > first offer/answer exchange will only be done to get the actual > > configuration (a=acfg...). This would affect section 3.6.2 in the > > draft. > > If the indicator is included in the offer SDP it makes a 2nd > > offer/answer exchange a MUST in order to complete the offer/answer > > exchange. Section 3.6.3 specifies a "SHOULD" regarding the > behavior if > > the actual cofiguration and the SDP does not match. It is possible > > that "SHOULD" must be changed to "MUST" here. > > > > A UA that for some reason knows that intermediaries don't > understand > > the new framework it will add the said SDP attribute at the session > > level in the offer-SDP. > > Indications that intermediaries don't understand the new > framework may > > for instance in the 3GPP IMS case be that for a specific > 3GPP release > > the said attribute is mandated, a possible location for > such a text in > > this particular case is 3GPP TS26.114. > > > > We believe that the addition of the new functionality to > the framework > > will increase acceptance for the SDP Capability Negotiation > framework > > greatly and this without breaking the framework. > > > > PS. This issue has been raised previously in the MMUSIC WG, > still we > > want to bring this up again for your consideration. > > > > Regards > > > > Ingemar Johansson > > Christer Holmberg > > > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > ___ > mmusic mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/mmusic > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
