Re: Admission Control to the IETF 78 and IETF 79 Networks

[SM]

Hi Ole,
At 11:33 AM 7/2/2010, Ole Jacobsen wrote:

Could you please summarize in one paragraph exactly what problem
you have with this setup?


I do not have any problem with the setup.  I support what Ted Hardie 
said in the last paragraph of his message.


Regards,
-sm 


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

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Actually, I wish we had done something in this area sooner in the hope
of creating a forcing function to make the authentication mechanisms
in WiFi more appropriate.

It has taken ten years for WiFi to get to a state where an adequate
credential mechanism is supported, and it is still clunky. And they
still don't have a decent mechanism to support the typical coffee shop
type access mode.


On Thu, Jul 1, 2010 at 11:26 AM, Fred Baker  wrote:
> While it is new in IETF meetings, it is far from unusual in WiFi networks to 
> find some form of authentication. This happens at coffee shops, college 
> campuses, corporate campuses, and people's apartments. I think I would need 
> some more data before I concluded this was unreasonable.
>
> On Jul 1, 2010, at 8:08 AM, SM wrote:
>
>> Hello,
>> At 14:55 30-06-10, IETF Chair wrote:
>>> I am writing to let you know about a change in the IETF meeting network.
>>> At IETF 79 in Beijing, the IETF network will be connected to the open
>>> Internet with absolutely no filtering.  However, we have agreed with our
>>> hosts that only IETF meeting participants will have access to the
>>> network.  Following sound engineering practices, we will deploy
>>> admission control mechanisms as part of the IETF 78 meeting network in
>>> Maastricht to ensure that they are working properly before they are
>>> mission critical.
>>
>> Most IETF participants probably know that the consensus of the IETF is 
>> documented through BCPs and other Standards Track RFCs.  If the text in the 
>> RFC isn't clear, there is room for disagreement.  If it is ill-defined, 
>> someone will go and find the loophole.  If the above text was in a BCP, we 
>> could nit on the definition of IETF meeting participants.  It is clear to 
>> people unfamiliar with the IETF that IETF meeting participants means people 
>> who have registered for the IETF meeting.
>>
>> I have been told that an IETF meeting does not have security guards at the 
>> door to verify who has a badge to determine whether the person is registered 
>> for the meeting.  If someone walks into an IETF meeting, the person can 
>> enjoy the cookie for free and even provide a contribution at the mic.  The 
>> person enjoys the same privileges as people who have paid for meeting 
>> attendance fee.
>>
>> I'll take the opportunity to thank Karen O'Donoghue for keeping the IAOC 
>> minutes up to date.  The IAB could do with some help in that area.
>>
>> Some of you may recall that the Beijing venue contract was discussed on this 
>> mailing list last year.  It resulted in some resolutions as follows:
>>
>> "Whereas the Host has assured the IAOC that 'a normal IETF
>>  meeting can be legally held in China and that no pre-screening
>>  of material or monitoring of session content is required or will
>>  be done,'
>>
>>  Whereas the IAOC, based on the assurances of the Host and a
>>  history of the venue successfully hosting major international
>>  conferences that relate to our industry, believes a normal IETF
>>  meeting can be held at the venue,
>>
>>  Whereas the IAOC heard all arguments made on the list, and
>>  made its determination on the ability to hold a successful
>>  meeting i.e. run it in a fashion as we always have, using the
>>  tools that we always have, with a critical mass of the
>>  traditional participants, discussing the usual topics."
>>
>> The fashion in the IETF is to have an open network.  There isn't any 
>> admission control and credentials are not required to enjoy the benefit of 
>> free and full Internet access.  The IETF may run out of cookies; it never 
>> runs out of bandwidth.
>>
>>> I am writing to let you know what to expect in both Maastricht and Beijing.
>>
>> And it is expected that the comments on this thread will follow sound IETF 
>> practices when it comes to mailing list discussions. :-)
>>
>> Regards,
>> -sm
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> http://www.ipinc.net/IPv4.GIF
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tsvwg-ecn-tunnel-08
Reviewer: Ben Campbell
Review Date: 2010-07-01
IETF LC End Date: 2010-07-06
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as a proposed standard. I have a 
couple of procedural questions that should be considered first, as well as a 
few editorial comments.

Major Issues: None.

Minor Issues:

-- RFC Editor request (immediately after ToC): "In the RFC index, RFC3168 
should be identified as an update to RFC2003. 
RFC4301 should be identified as an update to RFC3168."

This seems odd. I assume the intent is that this draft says that things from 
3168 should be applied to 2003, therefore updating 2003, etc? If so, wouldn't 
it be more correct to say that _this_ draft updates 2003 and 3168? 

-- 7, first paragraph: "The guidance below extends RFC4774, giving additional 
guidance on designing any alternate ECN semantics
that would also require alternate tunnelling semantics."

Should this draft be listed as updating 4774? Also, you've declared this 
section non-normative. What does it mean to non-normatively extend a BCP?

Nits/Editorial:

-- General:

Idnits gives some warnings. Please check.

There is quite a bit of text labeled to be removed by the RFC editor. Would it 
make sense to go ahead and remove them, and save the RFC editor the work? 
(Although, I wonder, if parts of that text is useful during the review process, 
if they would not also be useful to readers of the RFC?)

4.4, first paragraph: "a complaint"

Did you mean "compliant"?

-- 5.2, last paragraph:"as they document safe practice."
 Is that _existing_ safe practice? I.e is your intent to assert implementations 
already follow these practices, safe or otherwise?

-- 5.3.1, last bullet:"… the IETF Security Area now considers copying 
acceptable given the bandwidth of a 2-bit covert channel can be managed."

Can you supply a reference for that assertion?

-- IANA Considerations

Why remove the IANA  section? It gives us useful historical info, even if, as. 
In this case, it's empty. Also, the section should probably be numbered like 
the rest.

-- 8, List Heading: "Specialist security issues:"

Did you mean "special"?

-- Section 9:

This section seems mostly redundant to the introduction.

-- Endnotes: "Editorial Comments"
 
Are these (other than the one explicitly labeled to remove) going to stay in 
the final version? If so, I personally find the usual IETF approach of 
imbedding a note inline as an indented paragraph easier to follow.

-- Appendix D (and other Appendices to be removed) 

It's probably worth directing the removal label to the RFC editor, to reduce 
any chance of it being overlooked.

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

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Bob Hinden]

Mike,

> Going back to the IAOC, I would ask whether this requirement was known at the 
> time of the previous Beijing discussion?  If so, why wasn't it brought up at 
> that point in time and as part of the discussion on venue acceptability.  If 
> it was added later, when was it added, and why wasn't the requirement made 
> known to the broader IETF prior to announcing the solution? Finally, I know 
> this is a hypothetical, but would this requirement have tipped the IAOC 
> decision the other way had it been known at the same time of the previous 
> discussion?
> 
> I don't mean to pick on either you or the IAOC - you both are doing a 
> reasonable job steering among the shoals of the needs of the various 
> constituencies - just consider this an inquiry into how the IETF should 
> decide on how to decide whether a venue is acceptable. 

I don't remember exactly when this came up, probably after the previous Beijing 
discussion.  It came up as part of the discussion with the host that in order 
to provide a non-filtered Internet connection as required in the MOU, they 
would need a mechanism to limit network access to only IETF meeting attendees.  
Since we were not there to provide a network to non-IETF attendees and doing 
simple admission control was common in venues like NANOG., I didn't think this 
was an unreasonable request, nor would it keep us from having a normal IETF 
meeting.  I would also note the that there is a lot of variance in different 
IETF venues, such as voltage, food, local languages, etc., etc.  I saw this as 
something in that class of differences, not as as something that would keep us 
from having a productive IETF meeting.

The IEFF NOC volunteer team has been working closely with the local host team 
to develop something that is as light weight as possible and still meet their 
requirements.

Hope this is helpful.

Bob






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

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ole Jacobsen]

SM,

Could you please summarize in one paragraph exactly what problem
you have with this setup?

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



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

Re: Admission Control to the IETF 78 and IETF 79 Networks

[SM]

At 08:26 01-07-10, Fred Baker wrote:
While it is new in IETF meetings, it is far from unusual in WiFi 
networks to find some form of authentication. This happens at coffee 
shops, college campuses, corporate campuses, and people's 
apartments. I think I would need some more data before I concluded 
this was unreasonable.


I didn't conclude that it was unreasonable for reasons that are not 
mentioned above.


At 08:41 01-07-10, Dave CROCKER wrote:
attendance includes many local folk.  Once upon a time, IETF 
meetings constituted an extremely collegial environment among folks 
who knew each other.  Today, attendance is much more diverse.


Yes.

At 08:50 01-07-10, Ole Jacobsen wrote:

 I would have to disagree. You were probably not even born when we
 had real terminal rooms with real terminals and computers and mean
 looking security guards who very much did check badges. As stewards


No comment.


 of the IETF meeting resources, I would say that it is perfectly
 reasonable for the IAOC (or the local host) to control access to
  to only meeting participants. There is no principal
 difference between cookies and network here as far as I am concerned.
 And as others have pointed out, access control to WiFi networks is
 the norm rather than the exception, even when they are "free".


Two points:

 1. Resources are finite
 2. There can be abuse

Having an open IETF network should not be read as an encouragement 
for abuse or to make abusive use of the resources.  Some people may 
read it as an encouragement to do that.  As long as that number is 
insignificant, it's not a problem.  These people should not read this 
as meaning that they will get away with abuse.


In my initial message I mentioned that "the person enjoyed the same 
privileges as those who have paid".  Strictly speaking, that's a side 
effect of not enforcing access control.  My message should also not 
be read as an encouragement not to pay to attend the meeting.  The 
IETF might not be sustainable without the revenue from attendance fees.


At 12:05 01-07-10, Russ Housley wrote:

Not totally right.  The person with a badge can get one or more slips
with anonymous registration ID/passwords.  The badge-holder can then
share the slip with accompanying persons (such as spouse or kids or <
let's not go there ;-) > ).


The paragraph about that in the announcement did not go unnoticed.

At 12:38 01-07-10, Martin Rex wrote:

Is there no more Terminal room on IETF these days with LAN access,
where access to the area is monitored but access to the network
is not de-anonymized?


There were such access at some point.  The IAOC may be able to 
confirm whether it will still be available.


At 16:19 01-07-10, Michael StJohns wrote:
I agree with the above statement, but its really beside the 
point.  The issue is not that the IETF and IETF attendees are 
required to obey the laws of the venue, but rather whether or not 
the IETF chooses to hold a meeting in a venue where the law is 
sufficiently ... restrictive, draconian, capricious, ?? ... 
to  require the IETF to change its model of operation.


There was a long discussion about that because the venue was 
selected.  My previous message was not to focus on that.


This was specific to the "hotel gets to cancel the meeting on a 
whim" issue, but seems somewhat applicable to this topic.  We're 
instituting a new set of mechanisms , specific to this venue, not 
driven by changes requested or suggested by the IETF. So we're not 
doing this as  "run it in a fashon as we always have".


Yes.

I would expect this (per user login) to fade away after Beijing - 
unless and until the IAOC and IETF agrees that its necessary for the 
longer term.  And I don't believe that discussion has been had.


Yes.

With respect to this - it's too late to change the venue - and we're 
at the whim of the venue governments and regulations so we're pretty 
much stuck.  I'm hoping that further restrictions or changes will 
not be imposed, but don't know that I'm confident that will be the case.


That's the reason why I didn't consider it as reasonable to argue 
about this change.  This does not mean that I would consider it as 
unreasonable if you or someone else was to raise such an argument.


Going back to the IAOC, I would ask whether this requirement was 
known at the time of the previous Beijing discussion?  If so, why 
wasn't it brought up at that point in time and as part of the 
discussion on venue acceptability.  If it was added later, when was 
it added, and why wasn't the requirement made known to the broader 
IETF prior to announcing the solution? Finally, I know this is a 
hypothetical, but would this requirement have tipped the IAOC 
decision the other way had it been known at the same time of the 
previous discussion?


These questions came to mind.  I preferred not to ask them.

I don't mean to pick on either you or the IAOC - you both are doing 
a reasonable job steering among the shoals of the needs of the 
va

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Douglas Otis]

On 7/1/10 8:26 AM, Fred Baker wrote:

While it is new in IETF meetings, it is far from unusual in WiFi networks to 
find some form of authentication. This happens at coffee shops, college 
campuses, corporate campuses, and people's apartments. I think I would need 
some more data before I concluded this was unreasonable.
   
Beijing is truly a big city.  Some reports show China has more Internet 
users than North America, with other regions being a distant third. 
Isn't restricting access using a MAC address passé?  Within these 
hundreds of millions of users, are popular intrusion tools, such those 
distributed on Ubuntu CDs being marketed as "Free Internet", that are 
able to quickly crack WEP, and even WPA.  Brute force techniques for 
WPA2 might even utilize low cost online services of clustered video 
cores run against captured initial four-way handshakes which should 
discourage use of simple pass phrases.


A reasonable chance of keeping access away from this savvy population, 
will likely require enterprise WPA2.  Otherwise, it might become popular 
during the event to use high-gain antennas to obtain uncensored access.  
Distribution of such content could prove embarrassing, especially when 
logs reveal it came over IETF networks.


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

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Robert Moskowitz]

On 07/01/2010 11:50 AM, Ole Jacobsen wrote:

You wrote:

"It is clear to people unfamiliar with the IETF that IETF meeting
participants means people who have registered for the IETF meeting."

  Correct.

"I have been told that an IETF meeting does not have security guards
at the door to verify who has a badge to determine whether the person
is registered for the meeting. If someone walks into an IETF meeting,
the person can enjoy the cookie for free and even provide a
contribution at the mic. The person enjoys the same privileges as
people who have paid for meeting attendance fee."

  This is also true, but it is clearly not DESIGNED to let anyone
  participate for free in our meetings. I'd call this a "side-effect"
  that, if abused, would be remedied with exactly the kind of guards
  and badge checkers you envision. Participation in our PROCESS is open
  and can be achieved through mailing lists. Participation in our
  meetings has a real cost associated with it regardless of how it is
  funded. You are well aware of the fellowship program for example.

"The fashion in the IETF is to have an open network. There isn't any
admission control and credentials are not required to enjoy the
benefit of free and full Internet access. The IETF may run out of
cookies; it never runs out of bandwidth."

  I would have to disagree. You were probably not even born when we
  had real terminal rooms with real terminals and computers and mean
  looking security guards who very much did check badges. As stewards
  of the IETF meeting resources, I would say that it is perfectly
  reasonable for the IAOC (or the local host) to control access to
to only meeting participants. There is no principal
  difference between cookies


Remeber the Dallas IETF in DEc '95 when the hotel staff had to form a 
barrier to keep the MLM group also at the hotel away from our cookies 
and breakfast Cokes?  :)



and network here as far as I am concerned.
  And as others have pointed out, access control to WiFi networks is
  the norm rather than the exception, even when they are "free".

Cheers,

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



___
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

ISI Relationship with RFC Editor Ends

[IETF Administrative Director]

ISI's relationship with the RFC Editor ended on Wednesday, June 30, 2010.
That relationship began on March 21, 1977 when Jon Postel joined the
University of Southern California Information Sciences Institute and
brought the RFC Editor responsibilities with him.

Today, there are more than 5,900 RFCs, of which, almost 5,000 have been
processed, edited, and published at ISI. This reflects a tremendous
commitment on the part of ISI.  Just as the Internet�s history is marked
by individuals stepping forward to take the lead, so too organizations
such as ISI have shown leadership and dedication beyond what anyone had
the right to expect.

The RFC series demands a commitment to quality and consistency; to
process and transparency. Open standards and open access to standards are
cornerstones of the Internet�s success. And so the importance of the RFC
Editor role cannot be overstated.

For more than 30 years, USC�s Information Sciences Institute provided the
bedrock of organizational support the global Internet community needed.

Throughout ISI�s stewardship, the RFC Editor continuously improved the
RFC editorial processes, provided education and support to the IETF
community, and ensured the RFC archive was fully, freely available to
people from all over the world.

It�s hard to imagine a more humble-looking document series than the RFCs,
with their monospaced ACII text, austere formatting, and hard coded
headers and footers. Nor could you call the RFCs famous. As Jon himself
once said, �being in the limelight has its minuses�.

Yet the impact of this series has been, and continues to be earth
shattering. 

The IETF, the IAB, the IRTF and the Independent Submissions' work is
documented in the RFCs. All of us are joined by a common belief that the
Internet can improve the quality of life for people everywhere. 
For us, the RFCs are our holy books. Our folk lore. Our history. And our
guides. Vint Cerf once called them � in an RFC of course � �the Great
Conversation�.  �Hiding in the history of the RFCs,� he said, �is the
history of human institutions for achieving cooperative work.�

So then, the RFC Editor is our scribe, our diarist, historian, and our
keeper of standards (in all senses of that phrase).  For more than three
decades, ISI and its dedicated staff - including Jon Postel, Joyce
Reynolds and Bob Braden - performed that role and for that we are all
deeply in your debt.

Russ Housley, IETF Chair
Olaf Kolkman, IAB Chair
Aaron Falk, IRTF Chair
Lynn St.Amour, President/CEO, Internet Society

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

RE: secdir review of draft-ietf-simple-msrp-sessmatch

[Christer Holmberg]

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 endpoints can only check that the 
> session-id part of the MSRP URI..."
> >
> 
> This doesn't seem to me to actually work, based on Richard's 
> comments, unless what you mean to say is "if MSRPS is in use, 
> nothing in this draft can be used".  That gives you different 
> matching semantics for MSRPS (authority must be present and 
> must be matched using TLS semantics) vs MSRP (only session-id 
> is checked) which is at the very least a violation of the 
> principle of least surprise (no other foo over TLS protocol 
> works that way that I know of ).
> 
> regards,
> 
> Ted
> >
> > Reg