Re: IASA Experiments and responsibilities (was: Re: Some more background on the RFID experiment in Hiroshima)

[Ole Jacobsen]

John,

You said:

"But when, after the announcement, when the community expresses
considerable concerns, I expect the IASA (and, as appropriate
the sponsor) to engage directly on the questions and to treat
the decisions as a policy matter in which the community has to
be involved."

At the risk of being accused of spending far too much time and 
bandwidth on this particular topic, let me just say that the community 
IS involved as you can clearly see from the discussion on this
list. The WIDE people are paying close attention and I expect there 
to be yet more information forthcoming and the appropriate disclaimers 
and statements of any side effects (risks) involved.

I fundamentally disagree that "considerable concerns" have been 
expressed, instead I think good questions have been asked and issues
discussed that are all part of the experiment.

Risks are a fact of life. There is a risk that the T-shirts may 
contain chemicals you are allergic too, there is even a risk that
you could get mugged in Hiroshima (althought my personal estimate
is that you are about 100 times less likely to experience that as
compared to say, Chicago). The risk that (somehow) the RFID cards
will/can be read by a third party and used for some undesirable
purpose, I think is very low, but I agree that we should at least
outline the potential scenario and allow the attendee to make up
his/her mind regarding participation.

You are absolutely right that the IAOC has more pressing matters
to worry about.

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: Some more background on the RFID experiment in Hiroshima

[Dean Willis]

On Sep 14, 2009, at 12:41 PM, Ole Jacobsen wrote:



It means that the data will be deleted at the end of the expiriment
once the analysis is done. Educated guess: within 30 days of the end
of the meeting, I know how busy the folkds running the meeting are.
The bluesheets, on the other hand, are retained.

There is no need to retain this data once summaries and comparisons
are done.


That's a reasonably good statement of the retention policy.

For today's news about the unintended consequences of the release of  
experimental data, I refer you to:


http://www.foxnews.com/story/0,2933,549941,00.html?loomia_ow=t0:s0:a16:g2:r2:c0.083617:b27702080:z0

In short, 35 year old research maps relating to possible Hawaiian lava  
flows are being used to deny insurance coverage to homeowners, even  
though this isn't what the maps were intended for and despite the maps  
having been declared as hopelessly out-of-date by their producer.


You see, the maps are effectively in the public domain. Their use,  
retention policy, and level of validity  were not clearly described in  
the licensing terms given by the map makers. So the only thing anybody  
can do about it is make newer, better, maps, which both the homeowners  
and insurance companies are likely to fight because it would affect  
somebody's costs or profits. All politics are economical, and all  
science is political.


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

Re: Some more background on the RFID experiment in Hiroshima

[Dean Willis]

On Sep 13, 2009, at 11:22 PM, Ole Jacobsen wrote:



How is any of this relevant to an EXPERIMENT ???



A maxim about experimentation: If the design of and data resulting  
from any experiment are made available, people may use these results  
to test hypotheses that were not necessarily envisioned by the  
experiment designers. In other words, people are likely to do things  
with the result of the experiment that we don't necessarily have in  
mind. This is a given, and is not necessarily a bad thing. Indeed, it  
is how a great many discoveries are made.


But the experimenters (and/or their sponsors) are not without  
liability in today's unfortunately litigious world.  By making the  
results available, we have made some level of express or implied  
warranty about those results. There may also be some liability toward  
the experimental subjects (those of us with RFID tags, or those of us  
interacting with tagged persons). For example, people might use the  
experimental results in prosecution of patent lawsuits. If there are  
errors in the data, or if it can be argued that there were flaws in  
the experiment that were not disclosed to the users of the data, we  
could potentially be liable for damages.


So any collection, retention, and/or release of data has to be  
protected by explicit disclosure of policy and known limitation. The  
"implicit warranty" has to be made explicit, and in our case it most  
likely had better explicitly say that we're not making any assertions  
about the validity of the data, the collection method, the names or  
locations of the participants, or anything else. We should probably  
also document the data retention policy, which in this case is  
probably "We may dispose of these data at any time and are not  
obligated to preserve or retain them or to make them available at any  
future date." Further, we may wish to release the data with some sort  
of explicit licensing terms that include this explicit non-warranty of  
the experiment's validity.


--
Dean

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

Re: Non-smoking rooms at the Hiroshima venue?

[Alexa Morris]

At this point it does appear that all non-smoking rooms at the ANA  
Hotel have been allocated.


However, the hotel has assured us that every room -- smoking or non- 
smoking -- will be "freshened" prior to our arrival. This is a special  
step that they are taking specifically to accommodate our somewhat  
unusual needs.  In addition, the windows in the rooms open slightly,  
which will provide some fresh air.


Alexa


On Sep 14, 2009, at 9:25 AM, Ben Campbell wrote:



On Sep 1, 2009, at 1:00 PM, Alexa Morris wrote:

60% of our room block is considered non smoking but, as our room  
block is on the smaller side, it is possible that all non smoking  
rooms are indeed sold out. We have contacted the hotel to see how  
we can best work through this issue, but at the moment it is only  
3am in Hiroshima so it will be a number of hours before we hear  
back. We will update everyone as soon as we know more.


Did I miss any updates on this? Any word back from the hotel?

Thanks!

Ben.



---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ben Campbell]

Hi Ahmad,

Please see inline for my suggested text for the retransmission issue.  
Otherwise, I agree this closes the open issues.


Thanks!

Ben.

On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote:


Hi Ben,
Hopefully we can close on all of the open issues.
Please see inline.

Regards,
Ahmad



-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Subject: Re: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10

This is a followup on revision 12, since it came out

before I got to

revision 11:

Overall, I think this revision is much better. Most of my concerns
have been addressed, but I have a few minor ones remaining.

Specific comments:


-- Section 10.1, 2nd bullet:

I don't think we resolved my concern about the SHOULD  in the last
sentence. To recap, I think that needs to either be a MUST, or the
draft should offer guidance about the reasoning for the SHOULD and
the consequences of not following it. I'm picking on this one in
particular because it seems like not sending a BRA when

the A bit was

set is likely to cause retransmissions on the part of the

initiator.


[Ahmad]
If the MN does NOT have a binding in its BUL for the HoA

address that

is included in the Type 2 Routing header, the mobile node

should not

respond back (that was specifically discussed in details on the wg
ml).
It is like instructing the MN to delete a session that does

not exist.

Although, the (A) bit is set, it is up to the mobile node

whether to

send a BRA or not. I do not believe we need to mandate that via a
MUST.
I am sure some handset vendors will not like that at all.


Did the work group consider that if a MN doesn't respond, it
can expect to get a bunch of retransmissions--each of which
it will need to parse, check for bindings, etc.; possibly
eating more resources than responding in the first place would have?

I could understand if the concern was that the MN might get
irrelevant (or even malicious) BRIs from arbitrary sources,
but since they should only be arriving from trusted peers
over established SAs, I find the choice surprising.

But in any case, my concern was that it should be a MUST _or_
it should have discussion of the consequences of not doing
it. A line or two mentioning why this is a should, under what
circumstances it makes sense to not respond, and most
importantly pointing out the potential for needless
retransmission would help.


[Ahmad]
Yes we discussed that, but there are cases when the MN is not able to
send a BRA, for example, losing coverage, etc. "SHOULD" still a very
strong requirement, the node MUST do it unless there is a very good
valid reason not to.



But, please see below.








Also, the last sentence does not seem to make grammatical

sense after

the edits.


Thx, here is the new text, please let me know if you are

okay with it.


 o  If the Acknowledge (A) bit is set in the Binding Revocation
Indication and its Binding Update List contains an

entry for the

IP address in the Type 2 routing header, the mobile node MUST
send
a Binding Revocation Acknowledgement.  However, in all other
cases
when the Acknowledge (A) bit is set in the BRI, the mobile node
SHOULD sends a Binding Revocation Acknowledgement following
Section 10.2.


That's better, depending on the resolution of the SHOULD
discussion above.


[Ahmad]
Here is the text with the proposed addition as suggested above:

  o  If the Acknowledge (A) bit is set in the Binding Revocation
 Indication and its Binding Update List contains an entry for the
 IP address in the Type 2 routing header, the mobile node MUST  
send
 a Binding Revocation Acknowledgement.  However, in all other  
cases

 when the Acknowledge (A) bit is set in the BRI, the mobile node
 SHOULD sends a Binding Revocation Acknowledgement following
Section
 10.2. In the case when the MN does not send a BRA message in
response
 to a BRI with the Acknowledge (A) bit is set, the MN may  
receive a


 retransmit of the BRI message.

Is that acceptable?



Mostly. I would say "one or more" retransmissions, as they are likely  
to get several. Also, keep in mind this causes additional work for the  
initiator, who would have to retransmit in the first case. Perhaps  
something to the effect of:


 "Note that anytime the MN does not send an requested acknowledgement  
to a BRI, the initiator is likely to retransmit the BRI multiple  
times. This causes additional load on the initiator who sends the  
retransmissions, as well as on the MN that will receive and process  
them."









-- Same section, 4th bullet:

This one  still seems to ignore the A bit value. Given the
other edits, am I correct in assuming that you expect a BRA
if the A bit was set, otherwise a silent discard?


[Ahmad]
I believe we discussed this a little before. It is a fatal

error and

the
MN should never receive a BRI with the (P) bit set. That why this
behavior is the same regardless of the (A) b

Re: IASA Experiments and responsibilities (was: Re: Some more background on the RFID experiment in Hiroshima)

[John C Klensin]

--On Sunday, September 13, 2009 22:00 -0700 Ole Jacobsen
 wrote:

> 
> John,
> 
> With all due respect: The WIDE folks, host of IETF 76, have
> offered to  showcase a technology that is being used
> increasingly for all kinds of  things including public
> transportation system, door entry, and various  other
> interesting applications. We've labelled this as an experiment 
> and we've given everyone the option to NOT participate and
> we've  encouraged a discussion of the many issues surrounding
> privacy and  security that might arise by deploying such
> technology. We've also,  with the help of the host, outlined
> some of the technical details and  received feedback that I am
> sure will help improve many operational  and privacy/security
> aspects of the experiment, details of which are  being
> designed as we speak. As you know, Asia in general and Japan
> in  particular is very high-tech and I am sure most IETF
> attendees will  find the experiment interesting.

Yes.  But, as to the substance, I think Eric's comments are very
relevant here.   As I pointed out in my note to Don, this ceases
to be a "host experiment" as soon as the IASA gets involved, and
the IASA certainly appears to be involved... and is making
policy decisions without adhering to what I believe to be the
requirements for IASA policy decisions.  

There are countries in which the use of security cameras is very
widespread too, but I wouldn't expect the IETF --the same IETF
that has occasionally taken very strong positions against bans
on encryption technologies to protect privacy -- to endorse them.

To be clear, I think it is entirely reasonable for a host to
propose something like this, either as a "technology
demonstration" or as an "experiment" (I think of the two as
different; YMMD).   I think it is entirely reasonable for the
IASA to say "tentatively ok" without turning that into a big
deal or public process, and make an announcement to the
community about the plan, and I see that as having been done.
But when, after the announcement, when the community expresses
considerable concerns, I expect the IASA (and, as appropriate
the sponsor) to engage directly on the questions and to treat
the decisions as a policy matter in which the community has to
be involved.  And that is different from saying "it is an
experiment", "...help improve many operational  and
privacy/security aspects of the experiment", without any signs
of being willing to entertain the null hypothesis of "maybe this
isn't a good idea without time and resources for more
consideration and openness".

>...
> Just to be clear, the IAOC did not initiate the RFID
> experiment, and  you are correct that the community did not
> ask for it. The WIDE folks are working very hard to provide us
> with a great meeting, and as part of this effort they are
> showcasing some cool technologies. The RFID system is one such
> technology.

But, as I said to Don, not a technology demonstration that the
IASA needs to facilitate on the one hand and then pretend does
not involve policy decisions about secretariat and other
involvements on the other.

   john


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

Re: IASA Experiments and responsibilities (was: Re: Some more background on the RFID experiment in Hiroshima)

[John C Klensin]

--On Monday, September 14, 2009 10:06 -0400 Donald Eastlake
 wrote:

> John,
> 
> I can back most of your statement and the things you do but
> that below is just absolutely absurd.
> 
> The RFID badge thing originated in the >HOST< not in IASA. It
> is entirely within normal facilities arrangement and
> negotiation to use pre-existing badge arrangements,
> particularly where there is an easy opt out. An IETF meeting
> is not some computer cracker meeting trying to provide
> anonymity. However interesting the general case of various ID
> and information privacy arrangements may be, RFID or bar code
> or photo ID or color coded deely-bopper or whatever badges are
> perfectly reasonable as facilities provided by the HOST on a
> one time basis when it is easy to opt out.
> 
> I request that you apologize to the long suffering volunteers
> that make the IETF meeting facilities work for your
> unwarranted abuse.

Donald,

There are, it seems to me, two rather separate issues here.  

One is the general theme of whether the IASA is performing
according to the responsibilities and obligations of BCP 101 and
its own rules. Those are responsibilities, obligations, and
rules for which the IAD and members of the IAOC presumably
signed up.   Now maybe much of the community doesn't care
whether they do those things or not.  I don't think that
absolves the IASA from those responsibilities, but YMMD.

The second is what a sponsor gets to do when they decide to
sponsor an IETF meeting.  Our policies on that subject have
evolved over the years.  My recollection is that several
requests/suggestions to run exhibition halls in conjunction with
IETF meetings have been turned down.  You and I can both
remember the time when sponsors had to ask secretariat
permission to set up a table near the registration area that
displayed a sponsor logo and were routinely told "no".  But the
point is that these are policies and that having a sponsor give
out T-shirts or RFID badges are policy decisions too... policy
decisions that are made somewhere in the IASA structure, not
decisions a sponsor can make unilaterally unless sponsorship
agreements have changed dramatically (and in ways that should be
visible to the community).

Equally, it is a policy decision to make attendance lists (with
any details attached to them at all) available for sponsor use
and another one for the Secretariat to engage in any sort of
"matching" or "comparison to blue sheets" activities.

To repeat the comment I made in my note, I'm not personally
opposed to any of these things.  I'm just concerned about how
the IASA is making the policy decisions and dealing with the
comments from the community to which they are supposed to be
responsive ... or abandoning those policy decisions to the
sponsor without any clear oversight.   Judging from Ole's
comments, I think the IASA _is_ taking some responsibility here
--contrary to your apparent belief that this is entirely a
sponsor initiative.  I am pleased that the IASA is doing so...
at the same time that I'm concerned about whether their
priorities are correct to spend time on this optional activity
given the required things that are not getting done.

However, let's assume that this really were a host decision
independent of the IASA and that our sponsorship agreements
permitted or encouraged such things.  Then I'd expect the model
to be opt-in, not opt-out, I'd expect the database of user names
(or other identifiers) and badge numbers to be kept isolated
from secretariat databases, and I'd expect the responses about
the handling of the content of those databases to be coming from
the sponsor, not members of the IAOC.  YMMD about that, but, as
soon as the secretariat is involved and/or things are going into
the envelopes, there is an IASA policy decision involved, not an
independent host action.

So, sorry, no apology here.

 john

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

Re: Some more background on the RFID experiment in Hiroshima

[Ole Jacobsen]

It means that the data will be deleted at the end of the expiriment 
once the analysis is done. Educated guess: within 30 days of the end 
of the meeting, I know how busy the folkds running the meeting are. 
The bluesheets, on the other hand, are retained.

There is no need to retain this data once summaries and comparisons
are done.

Ole

On Mon, 14 Sep 2009, Alissa Cooper wrote:


> 
> Does this mean the database will be deleted after the comparison is done? Or
> does it mean the database will be deleted when the bluesheet data is deleted
> (i.e., never)?
> 
> Alissa
> 
> 
> 
> 
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Alissa Cooper]

On Sep 10, 2009, at 3:23 PM, Ole Jacobsen wrote:


Data rentention
---

The data collected in this experiment will only be used for basic
statistical purposes. Since there is a blue-sheet component to this
experiment it will be useful to compare the real bluesheet data with
the electronic equivalent, but the official (legal) attendance record
will still be based on the paper version. And the database will then
be deleted.



Does this mean the database will be deleted after the comparison is  
done? Or does it mean the database will be deleted when the bluesheet  
data is deleted (i.e., never)?


Alissa






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

Re: Some more background on the RFID experiment in Hiroshima

[Marc Petit-Huguenin]

Marshall Eubanks wrote:
> 
> On Sep 14, 2009, at 12:29 PM, Scott Brim wrote:
> 
>> Excerpts from Eric Rescorla on Sun, Sep 13, 2009 11:09:31PM -0700:
>>> At Sun, 13 Sep 2009 21:19:53 -0700 (PDT),
>>> Ole Jacobsen wrote:


 Eric,

 The local hosts are reading the messages on this list and will take
 appropriate steps including:

 * Not displaying the ID number <--> attendee mapping anywhere

 * Not assigning numbers sequencially
>>>
>>> That seems like a good start. As Richard and I have both indicated,
>>> however, this system seems to have substantial residual privacy
>>> risk, even if the identifiers are assigned completely unpredictably
>>> (and note that non-sequential and unpredictable are not at all the
>>> same thing).
>>
>> So don't carry it.  Or carry it in your faraday cage passport holder.
> 
> Maybe we could do a test of this as part of the meeting. I often tell
> people that a metal lunch box or
> aluminum foil should be sufficient, but it might be good to see how good
> they (plus the holders you can buy)
> really are.
> 
> Also, since the RFID readers can be bought easily (they're probably at
> Fry's), I would hope to hear of some good hack uses of this technology.

I worked on RFID readers last year as part of an aborted tentative[1] to improve
remote attendance for IETF meeting.  I expected the kind of problems that people
are (rightly so) worrying about currently, so I did a little bit of research on
the privacy part.  125Khz tags needs to be completely enclosed in a Faraday cage
with a double layer of conductive material. OTOH 13.56 Mhz tags can be isolated
with a single layer of conductive material, and it works fine even if the
material is only on one side or the card.  I chose 13.56 Mhz tags because, at
the difference of 125 Khz tag that can only carry a serial id, 13.56 Mhz tags
can store data (i.e. name, affiliation) and I do like the idea of having only to
destroy a card to improve my privacy (when it is in a database somewhere, it is
no longer yours).

Anyway, I designed a prototype of a card holder that permit to read the RFID
card and the printed information when open, and prevent to read both when 
closed:

http://ietf.implementers.org/rfid.jpg



[1] http://ietf.implementers.org/IETF20081118.pdf

-- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

Hi Ran,

I have specific responses in-line, but I'll start with a summary of sorts
for less patient readers.

IMHO, the current text places a responsibility on the IESG to deal with
"exceptional circumstances" but fails to provide the tools to execute that
responsibility.  After 27 years in government, I have a lot of experience
with assignment of responsibility without authority, and none of it was
positive.

I completely accept the community's consensus that IESG notes should be
reserved for the egregious cases, if any should emerge, but I would like to
see a process for achieving that goal where *necessary*.  Making notes
mandatory is one possible mechanism, although others might be preferable.  I
personally support the position outlined in Jari's 9/13/09 email...

On 9/12/09 7:20 AM, "RJ Atkinson"  wrote:

> Earlier, Tim Polk wrote (in part):
> % And are we really helping anyone by not clarifying the
> % relationship between the document and other RFCs?
> %
> % Shouldn't we provide this information as a
> % service to the reader?
> 
> Tim,
> 
> I like you, but your reasoning on this topic comes
> across as very confused or incompletely informed.
> 

Both of which may be true... but I'll give it another shot anyway.

> The information you discuss is ALREADY available and
> HAS BEEN available for well over a DECADE now.
> 
> To be frank, the status is also very very clear to anyone
> who actually glances at any modern RFC.
> 
> 1) Each modern RFC has a "Category" field in the header
> on the first page.  This dates back at least to RFC-1517,
> which was published in September 1993 -- 16 years ago.
> 
> 2) Separately, and for redundancy, the "Status of This Memo"
> field has made that information available in less
> abbreviated form.
> 
> To pick two arbitrary examples from ~15 years ago that
> illustrate both that the markings are QUITE CLEAR at even
> a quick glance AND that these markings go back MANY years
> now:
>
> A) RFC-1704 "On Internet Authentication"
> 
> 1) "Category: Informational" (top left corner)
> 2) "Status of this Memo" says in entirety:
> "This document provides information for the Internet
> community.  This memo does not specify an Internet
> standard of any kind.  Distribution of this memo
> is unlimited."
> 
> B) RFC-1626 "IP MTU for use over ATM AAL5"
>  
> 1) "Category: Standards Track" (top left corner)
> 2) "Status of this Memo" says in entirety:
> "This document specifies an Internet standards track
> protocol for the Internet community, and requests
> discussion and suggestions for improvements.  Please
> refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the
> standardization state and status of this protocol.
> Distribution of this memo is unlimited."
> 

I don't know think that this is a core issue, since it is addressed in the
headers and boilerplates document, but I don't think Category and Status of
Memo provide all the information needed.  Even assuming the reader looks at
the boilerplate and understands provided information, there is a difference
in my mind between an informational (or experimental) RFC that comes from
the IETF process or the IRTF process than one that is an independent
submission.  It is information the reader might want to factor into any
implementation or deployment decisions, but is not available.

> 3) As I understand things, and on this I might be a bit
>out-dated as to the current state of things, there is
>a concrete proposal to also add to each RFC (starting
>in the near future and continuing forward) the specific
>"Document Stream" (i.e. IETF, IRTF, IAB, Independent
>Submission) via which a particular RFC was published.
> 
>I have no objection to that addition.  I don't think that
>it is really necessary, given (1) and (2) above, but it
>seems to make some folks more comfortable and I don't
>immediately see any harm in that addition.
> 

I actually think this is a very good addition, precisely because I believe
(1) and (2) are insufficient.  If the reader reads and understands the
boilerplate, we have the 98% solution.  (I personally have my doubts about
reading and understanding the boilerplate, but I believe that is the
criteria the community would have the IESG apply: "Assuming the reader
understands the headers and boilerplate, is a note really needed?")

> 
> ANALYSIS:
>Noel's recent note pointing to Donald Eastlake's note
>is an accurate summary of the situation.  We have substantial
>actual operational experience indicating that IESG notes
>are handled appropriately by the RFC Editor team.  There
>is zero evidence of a problem.   So there is no reasonable
>cause to make IESG notes on non-IETF-trac

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

On 9/14/09 10:13 AM, "RJ Atkinson"  wrote:

> 
> 
> On  14 Sep 2009, at 10:00, Polk, William T. wrote:
>> IMHO, the current text places a responsibility on the IESG to deal
>> with
>> "exceptional circumstances" but fails to provide the tools to
>> execute that
>> responsibility.  After 27 years in government, I have a lot of
>> experience
>> with assignment of responsibility without authority, and none of it
>> was
>> positive.
> 
> It is interesting to better understand your perspective.
> 
> I would have read the "current text" in a nearly inverted meaning:
>providing "authority to deal with someone trying to make an
>'end run' around the IETF in some area of current IETF effort",
>by requesting the RFC-Editor to add an IESG note in such a case,
>but not requiring the IESG to do so.
> 

It is a fair observation... The word "responsibility" doesn't appear, so
that is just the way I interpret it.  Since this option is reserved for
"exceptional" cases, I guess I think the IESG would have an obligation to
address the issue, but that may be an AD-specific reading.

> To me, the most relevant datum is that we have more than 15 years
> of operational experience with the current setup, and zero actual
> problems.
> 

If we are lucky, this a painful exercise to establish process that will not
need to be tested in practice.  I certainly hope that is the case.

> [...stuff deleted here...]
> 
>>> 3) As I understand things, and on this I might be a bit
>>>   out-dated as to the current state of things, there is
>>>   a concrete proposal to also add to each RFC (starting
>>>   in the near future and continuing forward) the specific
>>>   "Document Stream" (i.e. IETF, IRTF, IAB, Independent
>>>   Submission) via which a particular RFC was published.
>>> 
>>>   I have no objection to that addition.  I don't think that
>>>   it is really necessary, given (1) and (2) above, but it
>>>   seems to make some folks more comfortable and I don't
>>>   immediately see any harm in that addition.
>>> 
>> 
>> I actually think this is a very good addition, precisely because I
>> believe
>> (1) and (2) are insufficient.  If the reader reads and understands the
>> boilerplate, we have the 98% solution.
>> 
>> (I personally have my doubts about reading and understanding the
>> boilerplate,
> 
> This parenthetical bit just above is confusing, and (at least to me)
> non-obvious.
> 
> Why would someone who can read sufficiently well to understand
> the content of an RFC have trouble distinguishing between the
> "Status of this Memo" texts AND also have trouble understanding
> the RFC's "Category" field ?
> 

It's not that the reader can't, it's that they *won't*.  I don't believe
readers always read the boilerplate, and I don't think many readers bother
to research the difference between the categories.  I find even long time
members of the IETF Community can debate whether a particular document
should be PS vs. BCP vs. Informational for a long time, so I am sure that
the nuances will be lost on the casual reader.

However, my limited expectations of the reader are irrelevant beyond
confirming my pessimistic nature.  I think the test we should apply is for
people that will read and understand the boilerplate.  (Otherwise, they
wouldn't see the IESG note anyway!)

>> but I believe that is the
>> criteria the community would have the IESG apply: "Assuming the reader
>> understands the headers and boilerplate, is a note really needed?")
> 
> I'm glad that you agree that seems to be the (most of the)
> community's perspective.
> 
> [...stuff deleted here...]
> 
>> [I wouldn't assume that anyone speaks for the IESG on this topic,
>> especially
>> me!  This represents my personal views only.]
> 
> Fair enough.
> 
> Thanks for the explanations.  At a minimum, I think I understand
> your perspective much better.
> 

+1

Tim

> Yours,
> 
> Ran Atkinson
> r...@extremenetworks.com
> 
> 

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

RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ahmad Muhanna]

Hi Ben,
Hopefully we can close on all of the open issues.
Please see inline.

Regards,
Ahmad
>
> >> -Original Message-
> >> From: Ben Campbell [mailto:b...@estacado.net]
> >> Subject: Re: Gen-ART LC and Telechat Review of 
> >> draft-ietf-mext-binding-revocation-10
> >>
> >> This is a followup on revision 12, since it came out 
> before I got to 
> >> revision 11:
> >>
> >> Overall, I think this revision is much better. Most of my concerns 
> >> have been addressed, but I have a few minor ones remaining.
> >>
> >> Specific comments:
> >>
> >>
> >> -- Section 10.1, 2nd bullet:
> >>
> >> I don't think we resolved my concern about the SHOULD  in the last 
> >> sentence. To recap, I think that needs to either be a MUST, or the 
> >> draft should offer guidance about the reasoning for the SHOULD and 
> >> the consequences of not following it. I'm picking on this one in 
> >> particular because it seems like not sending a BRA when 
> the A bit was 
> >> set is likely to cause retransmissions on the part of the 
> initiator.
> >
> > [Ahmad]
> > If the MN does NOT have a binding in its BUL for the HoA 
> address that 
> > is included in the Type 2 Routing header, the mobile node 
> should not 
> > respond back (that was specifically discussed in details on the wg 
> > ml).
> > It is like instructing the MN to delete a session that does 
> not exist.
> > Although, the (A) bit is set, it is up to the mobile node 
> whether to 
> > send a BRA or not. I do not believe we need to mandate that via a 
> > MUST.
> > I am sure some handset vendors will not like that at all.
> 
> Did the work group consider that if a MN doesn't respond, it 
> can expect to get a bunch of retransmissions--each of which 
> it will need to parse, check for bindings, etc.; possibly  
> eating more resources than responding in the first place would have?
> 
> I could understand if the concern was that the MN might get 
> irrelevant (or even malicious) BRIs from arbitrary sources, 
> but since they should only be arriving from trusted peers 
> over established SAs, I find the choice surprising.
> 
> But in any case, my concern was that it should be a MUST _or_ 
> it should have discussion of the consequences of not doing 
> it. A line or two mentioning why this is a should, under what 
> circumstances it makes sense to not respond, and most 
> importantly pointing out the potential for needless 
> retransmission would help.

[Ahmad]
Yes we discussed that, but there are cases when the MN is not able to
send a BRA, for example, losing coverage, etc. "SHOULD" still a very
strong requirement, the node MUST do it unless there is a very good
valid reason not to.

But, please see below. 

> 
> 
> >
> >>
> >> Also, the last sentence does not seem to make grammatical 
> sense after 
> >> the edits.
> >
> > Thx, here is the new text, please let me know if you are 
> okay with it.
> >
> >   o  If the Acknowledge (A) bit is set in the Binding Revocation
> >  Indication and its Binding Update List contains an 
> entry for the
> >  IP address in the Type 2 routing header, the mobile node MUST 
> > send
> >  a Binding Revocation Acknowledgement.  However, in all other 
> > cases
> >  when the Acknowledge (A) bit is set in the BRI, the mobile node
> >  SHOULD sends a Binding Revocation Acknowledgement following 
> > Section 10.2.
> 
> That's better, depending on the resolution of the SHOULD 
> discussion above.

[Ahmad] 
Here is the text with the proposed addition as suggested above:

   o  If the Acknowledge (A) bit is set in the Binding Revocation
  Indication and its Binding Update List contains an entry for the
  IP address in the Type 2 routing header, the mobile node MUST send
  a Binding Revocation Acknowledgement.  However, in all other cases
  when the Acknowledge (A) bit is set in the BRI, the mobile node
  SHOULD sends a Binding Revocation Acknowledgement following
Section
  10.2. In the case when the MN does not send a BRA message in
response 
  to a BRI with the Acknowledge (A) bit is set, the MN may receive a

  retransmit of the BRI message.

Is that acceptable?

> 
> >
> >>
> >> -- Same section, 4th bullet:
> >>
> >> This one  still seems to ignore the A bit value. Given the
> >> other edits, am I correct in assuming that you expect a BRA
> >> if the A bit was set, otherwise a silent discard?
> >
> > [Ahmad]
> > I believe we discussed this a little before. It is a fatal 
> error and  
> > the
> > MN should never receive a BRI with the (P) bit set. That why this
> > behavior is the same regardless of the (A) bit is set or not. If you
> > feel that some clarification about the (A) bit needs to be 
> added, I  
> > can
> > say,
> > .. regardless if the Acknowledge (A) bit is set or not, 
> the mobile
> > node MUST silently discard the BRI message.
> 
>  From previous discussion, I thought we had converged on the 
> idea that  
> the A-bit should always be authoritative, rather than havi

Re: Some more background on the RFID experiment in Hiroshima

[Marshall Eubanks]

On Sep 14, 2009, at 12:29 PM, Scott Brim wrote:


Excerpts from Eric Rescorla on Sun, Sep 13, 2009 11:09:31PM -0700:

At Sun, 13 Sep 2009 21:19:53 -0700 (PDT),
Ole Jacobsen wrote:



Eric,

The local hosts are reading the messages on this list and will take
appropriate steps including:

* Not displaying the ID number <--> attendee mapping anywhere

* Not assigning numbers sequencially


That seems like a good start. As Richard and I have both indicated,
however, this system seems to have substantial residual privacy
risk, even if the identifiers are assigned completely unpredictably
(and note that non-sequential and unpredictable are not at all the
same thing).


So don't carry it.  Or carry it in your faraday cage passport holder.


Maybe we could do a test of this as part of the meeting. I often tell  
people that a metal lunch box or
aluminum foil should be sufficient, but it might be good to see how  
good they (plus the holders you can buy)

really are.

Also, since the RFID readers can be bought easily (they're probably at  
Fry's), I would hope to hear of some good hack uses of this technology.


Regards
Marshall




I think it's fair to say that the people running this experiment
haven't done anything like full disclosure of the relevant
risks--and it's not even clear that they understand them themselves.


Please help them

___
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: Some more background on the RFID experiment in Hiroshima

[David Conrad]

Eric,

On Sep 13, 2009, at 11:09 PM, Eric Rescorla wrote:

As Richard and I have both indicated,
however, this system seems to have substantial residual privacy
risk, even if the identifiers are assigned completely unpredictably
(and note that non-sequential and unpredictable are not at all the
same thing).


I'm curious: do you carry a cell phone?

Regards,
-drc

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

Re: Some more background on the RFID experiment in Hiroshima

[Scott Brim]

Excerpts from Ole Jacobsen on Mon, Sep 14, 2009 12:05:25AM -0700:
> I suppose we could do what 
> the Fastrak people did when they sent me the RFID gizmo for bridge
> tolls: They included a foil-lined bag and explained that the system
> was being used to monitor traffic (as well as collect tolls) and if
> I didn't want to participate I could put the gizmo in the bag.

Side story: when a car of mine was totalled in Brooklyn and towed to
New Jersey, I forgot to take the E-ZPass "tag" off and I later got a
trace of which bridges the tow truck had taken.  

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

Re: Some more background on the RFID experiment in Hiroshima

[Scott Brim]

Excerpts from Eric Rescorla on Sun, Sep 13, 2009 11:09:31PM -0700:
> At Sun, 13 Sep 2009 21:19:53 -0700 (PDT),
> Ole Jacobsen wrote:
> > 
> > 
> > Eric,
> > 
> > The local hosts are reading the messages on this list and will take 
> > appropriate steps including:
> > 
> > * Not displaying the ID number <--> attendee mapping anywhere
> > 
> > * Not assigning numbers sequencially
> 
> That seems like a good start. As Richard and I have both indicated,
> however, this system seems to have substantial residual privacy
> risk, even if the identifiers are assigned completely unpredictably
> (and note that non-sequential and unpredictable are not at all the
> same thing). 

So don't carry it.  Or carry it in your faraday cage passport holder.

> I think it's fair to say that the people running this experiment
> haven't done anything like full disclosure of the relevant
> risks--and it's not even clear that they understand them themselves. 

Please help them

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

Re: Some more background on the RFID experiment in Hiroshima

[Scott Brim]

Dean, all these excellent issues have to be dealt with if/when use of
RFIDs becomes a normal part of IETF logistics.  It's not.

Excerpts from Dean Willis on Sun, Sep 13, 2009 09:33:56PM -0500:
> Seriously, it does have major implications for intellectual property
> lawsuits.
> 
> Let's say JoeBob attends a meeting of the FRILL working group, then
> goes home to patent a nifty new innovation in FRILL, which is then
> bought for $1 by a patent troll when JoeBob's company goes broke
> because his board of directors blew their investment capital on
> stocking their break room with headcheese. Said patent troll then
> sues some defendant, whose legal team later notices that said FRILL-
> enhancement had been discussed at IETF 211 while JoeBob, the
> inventor, was in the room, thereby invalidating the patent (and
> making JoeBob look like a doofus).
> 
> Okay, so that's not an example with too many negatives, unless
> JoeBob decides to sue us for making him look like a doofus.
> 
> Now let's presume that some people remember (and that some other
> people don't remember) JoeBob being in the room during the
> discussion, but IETF"s RFID tracker log shows that JoeBob was
> hanging out with me in the bar. Does IETF's failure to maintain the
> record that invalidates the patent make us liable to the defendant?
> 
> Or worse yet, IETF can't produce the RFID logs in response to a
> court order, because somebody goofed and deleted them. Was this a
> conspiracy to protect the patent troll? Who got bribed to make it
> happen? How many hundreds of thousands of euros we would like to
> spend on the paperwork related to the various discovery motions we
> might have to endure?
> 
> In other words, any retained information increases liability, both
> for the accuracy of the retained information and for the
> preservation of the retained information. That's why we must both
> have a policy about how that information is obtained and preserved,
> and we must live up to that policy, whatever it says.
> 
> Of course, the easiest policy is to retain no information. But even
> that has its consequences. For example, is deliberate ignorance
> consistent with industry best-practices? How does this interact with
> the Sarbanes-Oxley requirements of our sponsors? And why would a
> startup company stock its break room with headcheese anyhow?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Non-smoking rooms at the Hiroshima venue?

[Ben Campbell]

On Sep 1, 2009, at 1:00 PM, Alexa Morris wrote:

60% of our room block is considered non smoking but, as our room  
block is on the smaller side, it is possible that all non smoking  
rooms are indeed sold out. We have contacted the hotel to see how we  
can best work through this issue, but at the moment it is only 3am  
in Hiroshima so it will be a number of hours before we hear back. We  
will update everyone as soon as we know more.


Did I miss any updates on this? Any word back from the hotel?

Thanks!

Ben.

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[RJ Atkinson]

On  14 Sep 2009, at 10:00, Polk, William T. wrote:
IMHO, the current text places a responsibility on the IESG to deal  
with
"exceptional circumstances" but fails to provide the tools to  
execute that
responsibility.  After 27 years in government, I have a lot of  
experience
with assignment of responsibility without authority, and none of it  
was

positive.


It is interesting to better understand your perspective.

I would have read the "current text" in a nearly inverted meaning:
  providing "authority to deal with someone trying to make an
  'end run' around the IETF in some area of current IETF effort",
  by requesting the RFC-Editor to add an IESG note in such a case,
  but not requiring the IESG to do so.

To me, the most relevant datum is that we have more than 15 years
of operational experience with the current setup, and zero actual  
problems.


[...stuff deleted here...]


3) As I understand things, and on this I might be a bit
  out-dated as to the current state of things, there is
  a concrete proposal to also add to each RFC (starting
  in the near future and continuing forward) the specific
  "Document Stream" (i.e. IETF, IRTF, IAB, Independent
  Submission) via which a particular RFC was published.

  I have no objection to that addition.  I don't think that
  it is really necessary, given (1) and (2) above, but it
  seems to make some folks more comfortable and I don't
  immediately see any harm in that addition.



I actually think this is a very good addition, precisely because I  
believe

(1) and (2) are insufficient.  If the reader reads and understands the
boilerplate, we have the 98% solution.

(I personally have my doubts about reading and understanding the  
boilerplate,


This parenthetical bit just above is confusing, and (at least to me)
non-obvious.

Why would someone who can read sufficiently well to understand
the content of an RFC have trouble distinguishing between the
"Status of this Memo" texts AND also have trouble understanding
the RFC's "Category" field ?


but I believe that is the
criteria the community would have the IESG apply: "Assuming the reader
understands the headers and boilerplate, is a note really needed?")


I'm glad that you agree that seems to be the (most of the)
community's perspective.

[...stuff deleted here...]

[I wouldn't assume that anyone speaks for the IESG on this topic,  
especially

me!  This represents my personal views only.]


Fair enough.

Thanks for the explanations.  At a minimum, I think I understand
your perspective much better.

Yours,

Ran Atkinson
r...@extremenetworks.com


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

Re: IASA Experiments and responsibilities (was: Re: Some more background on the RFID experiment in Hiroshima)

[Donald Eastlake]

John,

I can back most of your statement and the things you do but that below
is just absolutely absurd.

The RFID badge thing originated in the >HOST< not in IASA. It is
entirely within normal facilities arrangement and negotiation to use
pre-existing badge arrangements, particularly where there is an easy
opt out. An IETF meeting is not some computer cracker meeting trying
to provide anonymity. However interesting the general case of various
ID and information privacy arrangements may be, RFID or bar code or
photo ID or color coded deely-bopper or whatever badges are perfectly
reasonable as facilities provided by the HOST on a one time basis when
it is easy to opt out.

I request that you apologize to the long suffering volunteers that
make the IETF meeting facilities work for your unwarranted abuse.

Donald
=
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com



On Mon, Sep 14, 2009 at 12:31 AM, John C Klensin  wrote:
> Ole,
>
> I'd like to encourage you and your IAOC/Trustee colleagues to
> think about this in a slightly different light, consistent with
> other concerns I've expressed recently.
>
> Without taking any position about the idea itself, some
> significant fraction of the community seems to believe that this
> type of RFID experiment is a policy matter.  Another portion,
> perhaps overlapping, believes that a version of the "eat our own
> dogfood" principle says that we should set an example by
> utilizing RFID only properly and with due consideration.  Some
> of that group believes that "properly and with due
> consideration" includes at least some technical security and
> privacy issues, others (again possibly overlapping) believe that
> the IETF should not be performing experiments with information
> collection that can even potentially identify individuals unless
> there are clear and public privacy policies in place.
>
> I can find nothing in BCP 101 that encourages or authorizes the
> IASA to go off and perform policy experiments on its own
> initiative.  I haven't seen any signs of a proposal for a 3933
> process experiment in this area.  Such a proposal, or an
> IESG-initiated effort with a Last Call, presumably would have
> involved an I-D and a reasonable possibility for the community
> to determine whether the relevant ducks were lined up.
>
> I also find nothing in the "guidelines [...]for regular
> operational
> decision making" (required by RFC 4071, Section 3.5, first
> paragraph) that authorizes this sort of experiment.  Indeed,
> despite that requirement, I'm not sure I can even find such
> guidelines.  The only thing I can find is the "IAOC
> Administrative Procedures" at
> http://iaoc.ietf.org/documents/IAOC_Administrative_Procedures_7-17-08.pdf,
> but they seem to be addressed to issues other than "regular
> operational decision making" and, despite the date on the file,
> the procedure document itself doesn't show an adoption date and
> the Policy and Procedures page
> (http://iaoc.ietf.org/policyandprocedures.html) seems to
> indicate that they are just a draft.
>
> In looking for that material, I did find the Communications
> Policy, which appears to be a substitute for the Guidelines
> called for by RFC 4071.   It makes interesting reading.  For
> example:
>
>        -- Section 5.3.4 calls for the IAOC to "adopt annual
>        goals for the IASA and the IAD by December of each year
>        for the succeeding year".  The Reports page of the web
>        site (http://iaoc.ietf.org/reports.html) contains a line
>        for such "Annual IASA Goals", but it isn't even a link,
>        so apparently either there are no such goals or the IAOC
>        doesn't believe that making them available to the
>        community is a priority.
>
>        -- Section 5.3.7 calls for an "Operations Report" to be
>        submitted to the IAOC monthly and posted on the web
>        site.  There is no evidence of integrated Operations
>        Reports on the web site.  Not a single one.  There are,
>        however, separate Financial Statements (three so far for
>        2009 -- but those are covered separately in Section 5.2
>        of the Communications Plan and are hence irrelevant to
>        the Section 5.3.7 requirement) and Monthly Reports from
>        the IANA (not the IAD).
>
>        -- Section 5.3.8 says "The IAOC shall publish an IAOC,
>        financial, and vendor performance report online one week
>        before the IETF Meeting".  I don't recall seeing that
>        report on a regular basis, only oral presentations at
>        the IETF plenaries.   The "Plenary Reports" page
>        (http://iaoc.ietf.org/plenary_reports.html) shows only
>        IANA and RFC Editor reports associated with IETF
>        meetings in the last several years.  Indeed, the last
>        "IETF Ops Report" shown there is from IETF 68 (Prague in
>        2007, before this Communications Policy was adopted)

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joe Touch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



RJ Atkinson wrote:
...
> BOTTOM LINE:
>   There seems to be clear consensus amongst folks outside
>   the IESG that (1) there is no current problem and (2)
>   no process change is warranted to make IESG notes mandatory
>   on non-IETF-track documents.

+1

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkquTaQACgkQE5f5cImnZrslVwCglTLLQLG+CyzUvJcTQclN93NC
n8YAnj3TKxXsqEHjvsl0Ur2+OAa7uh1y
=T1Qd
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Ole Jacobsen]

Neither privacy/security nor discussion of such is being neglected or
discouraged. That's part of the experiment too.

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



On Mon, 14 Sep 2009, Steven M. Bellovin wrote:

> I'm with Eric on this.  Part of our dog food is a decent regard for
> security and privacy; we shouldn't neglect in the name of
> experimentation.
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Steven M. Bellovin]

I'm with Eric on this.  Part of our dog food is a decent regard for
security and privacy; we shouldn't neglect in the name of
experimentation.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Scott Brim]

So far this has been an interesting experiment in trying to have an
experiment within the IETF culture.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Stephane Bortzmeyer]

On Mon, Sep 14, 2009 at 12:05:25AM -0700,
 Ole Jacobsen  wrote 
 a message of 53 lines which said:

> I am sure the organizers never expected this amount of feedback
> either,

They don't know the IETF, then :-) They can expect a lot of feedback
on sushi and cookies, too.

> particularly not since the technology has been in regular use in
> Japan for many years.

The fact that some technology is already widely used certainly does
not mean that we should shut up about its security risks. I
appreciated Eric Rescorla's well-informed and well-explained analysis.

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

Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

[Pasi.Eronen]

I've reviewed the ROHCoIPsec draft set (not wearing any hats), and
have couple of comments. Most important first:

1) None of the drafts really describe the reason why the ROHC ICV is
included. It was not present in the early drafts, and was added after
long and complex discussions. I would strongly encourage summarizing
those discussions in one of the drafts -- otherwise, the reader cannot
really figure out why the ROHC ICV is included (since the packets are
already protected by the AH/ESP ICV), and what risks omitting the ROHC
ICV might have.

2) ipsec-extensions, Section 3.3, doesn't really correctly describe
the MTU-related processing in RFC 4301. The three cases refer to IPsec
implementations that both process unprotected ICMP messages and
actually receive them (they're often filtered in the network), and
thus have a Path MTU estimate value.  But an IPsec implementation that
doesn't process (or receive) unprotected ICMP messages does not even
have a Path MTU estimate value...

3) According to RFC 4224, ROHC segmentation does not work over
reordering channels. Thus, it seems suggesting that ROHC segmentation
could be used instead of pre-encryption fragmentation (e.g.
ipsec-extensions, Section 3.3) -- and in general, allowing
segmentation at all -- seems misguided (it's unnecessary complexity
that would be IMHO best left out).

4) None of the drafts have any RFC 2119 keywords (MUST/SHOULD/etc).
They SHOULD use those to make it less ambiguous what is the required
behavior (and what is optional) to claim compliance with these drafts.

5) In ikev2-extensions, Section 2.1.2 it is not very clear which of
the attributes are just one-way notifications (the sender of the
attribute tells the other end what it can handle), and which are
negotiated (the initiator tells the other end what it supports; the
responder then selects one, and tells what it selected).

I would suggest adding text like "Note that different ATTRIBUTE_NAME
value can be used in each direction" for those attributes that are
just one-way (I think at least MAX_CID, ROHC_PROFILE -- for MRRU and
ROHC_ICV_LEN, I don't know which way they're supposed to work).

6) ikev2-extensions, Section 2.1.2, says "The key for this Integrity
Algorithm is computed using the same method as is used to compute
IPsec's Integrity Algorithm key ([IKEV2], Section 2.17)."  I don't
think this is sufficient to get interoperable implementations; more
details are needed.

In addition, there's couple of places that probably need some
clarifications and/or minor fixes:

7) ikev2-extensions, Section 2.1.2, ROHC_ICV_LEN: The text talks about
"announcing their preference"; how is the actual ICV length determined
from these preferences?

8) ikev2-extensions, Section 2.1.2, ROHC_INTEG: Should also describe
what happens if the responder doesn't accept any of the algorithms
proposed by the initiator (not doing ROHC at all would be one obvious
alternative; NO_PROPOSAL_CHOSEN another).

9) ikev2-extensions, Section 2.1.1, says "The most significant bit in the
field is the Attribute Format (AF) bit." No, according to Figure 2
"AF" is a separate field, not part of the "ROHC Attribute Type" field.

10) ipsec-extensions, Section 3.2, says "The authentication data must
not be included in the calculation of the ICV." This is very vague,
considering that we have several different authentication data/ICVs
here. Is the intent to say "The ROHC ICV field is not included in the
calculation of the ROHC ICV", or something else?

11) ikev2-extensions, Section 4: "6-65536 Unassigned" should be 
"6-32767 Unassigned".

Best regards,
Pasi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 standard?

[Iljitsch van Beijnum]

On 12 Sep 2009, at 1:46 , JORDI PALET MARTINEZ wrote:


For this and other RFCs, we started some years ago the work at
http://www.ipv6-to-standard.org



Just waiting for the IESG to take on it ...


So? What's the holdup?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Some more background on the RFID experiment in Hiroshima

[Ole Jacobsen]

On Sun, 13 Sep 2009, Eric Rescorla wrote:
> 
> That seems like a good start. As Richard and I have both indicated,
> however, this system seems to have substantial residual privacy
> risk, even if the identifiers are assigned completely unpredictably
> (and note that non-sequential and unpredictable are not at all the
> same thing). 

I will leave it to the local organizers to disclose and explain the 
experiment further. I am no privacy and security expert, but it seems
to me rather unlikely that anyone needs to be concerned about being
"tracked" when the practical distance from reader to card is about
18 inches. In having these discussions we've probably highlighted a
number of *potential* risks much more than what the average credit 
card or cell phone customer is informed of. I suppose we could do what 
the Fastrak people did when they sent me the RFID gizmo for bridge
tolls: They included a foil-lined bag and explained that the system
was being used to monitor traffic (as well as collect tolls) and if
I didn't want to participate I could put the gizmo in the bag.

> I'm not trying to be difficult, but I'm not overly impressed with the
> defense that people keep offering that this is an experiment and
> people can opt out. If this were being done as an experiment at a
> university, you would be expected to go in front of a human subjects
> committee and demonstrate that your subjects had given informed
> consent, probably wouldn't be harmed, etc.

What about a "commercial" or "business" setting? The hotel in 
Stockholm where many (most?) of the IETFers stayed had RFID cards for 
key entry to the hotel rooms.

> Now, obviously, this isn't an academic setting, but I think it's 
> fair to say that the people running this experiment haven't done 
> anything like full disclosure of the relevant risks--and it's not 
> even clear that they understand them themselves. [It would also be 
> consistent with common practice for people to specifically opt in, 
> not out.]

Effectively that's what will happen. At registration, you will be 
offered the card, you can obviously refuse to accept it. As for
full disclosure of relevant risks, having this discussion is hopefully 
leading to a set of observations that can be supplied to each 
attendee. And yes, it isn't fully designed yet, but I am sure the
organizers never expected this amount of feedback either, particularly 
not since the technology has been in regular use in Japan for many 
years.

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