headers
Mark Andrews | 1 Sep 2010 03:05

Re: DNSSEC


In message <AANLkTinwMO6Sw-rvfrax-_VNN8x1kejc9iAkrNQGBf2v <at> mail.gmail.com>, Phil
lip Hallam-Baker writes:
> Whether or not the IAB zone is signed is of negligible consequence.
> 
> But the fact that the IAB zone signatures had expired is a highly
> significant data point: DNSSEC administration is not quite as easy as
> some of the glib claims of its more enthusiastic supporters would lead
> one to believe.

It's more a matter of choosing the right tools.  I've got signed
zones that haven't been hand signed in 3 years using a 2 month
signature validity interval.  The nameserver just re-signs the
records as they fall due.  That's several thousand automatic updates
of the zones in that period.  Yes, I've changed the non DNSSEC
content of the zones in that time.

This isn't a protocol issue.  It's a tools issue and DNSSEC tools
from all vendors are improving.

It's also extremely easy to construct tools that can warn you to
re-sign if you are doing it by hand.  You could replace awk with
perl and have a cross platform tool.  Such tools can easily be
added to network management platforms as they are just small
scripts.  If you don't have a network managment platform use
cron.

e.g.

% dig axfr dv.isc.org  <at> bsdi.dv.isc.org | awk '$4 == "RRSIG" && $9 < WARN { print }' WARN=`date -u -v +7d +%Y%m%d%H%M%S`
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glen Zorn | 1 Sep 2010 05:08

RE: Optimizing for what? Was Re: IETF Attendance by continent

Hadriel Kaplan [mailto://HKaplan <at> 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
(Continue reading)

Permalink | Reply | 17 comments |
headers
Randall Gellens | 1 Sep 2010 06:15

RE: Optimizing for what? Was Re: IETF Attendance by continent

At 10:08 AM +0700 9/1/10, Glen Zorn wrote:

>   > > 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...

On this point I am in agreement with Glen.  However, any of the 
Hawaiian islands would be a great choice, given the ease of travel 
arrangements, the warm weather which reduces the need for much of the 
luggage (no need for warm clothes), and the general difficulty of 
being disagreeable in such an environment.  Many of the conference 
facilities are open-air, with roofs and protection from rain but 
still providing ample fresh air and natural light.

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Anything labeled "NEW" and/or "IMPROVED" isn't.  The label means the
price went up.  The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
means the price went way up.
Permalink | Reply | 2 comments |
headers
Yoav Nir | 1 Sep 2010 08:35
Picon
Favicon

Re: IETF Attendance by continent


On Aug 31, 2010, at 4:56 PM, Iljitsch van Beijnum wrote:

>> Consider that contributors
>> usually start as newcomers, attend several meetings, then write a draft,
> 
> I don't know about you, but I wrote drafts before my first meeting.

Me too. I actually had an RFC published two months before attending my first meeting.

As an employee (rather than an independent consultant) if I ask my bosses to go to an IETF meeting, their
first question is what am I going to do there.  A good answer is that I want to present this draft in that
working group, participate in this discussion at another working group, and meet this person to talk
about that subject.

If I just said I want to go to some meetings, and listen to stuff, and see if I hear anything interesting,
they'd tell me to use the audio stream for that.

OTOH we've all seen a whole bunch of people at meetings who always sit in the back, faces buried in their
laptops, and never participating in any discussion.  I'm not sure what value their employer gets from
their participation, but I guess both models exist.
Permalink | Reply | 1 comment |
headers
Clint Chaplin | 1 Sep 2010 08:55
Picon

Re: Optimizing for what? Was Re: IETF Attendance by continent

On Tue, Aug 31, 2010 at 9:15 PM, Randall Gellens <rg+ietf <at> qualcomm.com> wrote:
> At 10:08 AM +0700 9/1/10, Glen Zorn wrote:
>
>>  > > 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...
>
> However, any of the Hawaiian
> islands would be a great choice, given the ease of travel arrangements, the
> warm weather which reduces the need for much of the luggage (no need for
> warm clothes),

IEEE 802 wireless interim meetings in September have been at the
Waikoloa Resort for the last few years.  The meeting rooms are so
heavily air condituoned that the attendees now know to bring a sweater
to the meeting.

>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Anything labeled "NEW" and/or "IMPROVED" isn't.  The label means the
> price went up.  The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
> means the price went way up.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glen Zorn | 1 Sep 2010 09:36

RE: Optimizing for what? Was Re: IETF Attendance by continent

Clint Chaplin [mailto:clint.chaplin <at> gmail.com] writes:

> On Tue, Aug 31, 2010 at 9:15 PM, Randall Gellens <rg+ietf <at> qualcomm.com>
> wrote:
> > At 10:08 AM +0700 9/1/10, Glen Zorn wrote:
> >
> >>  > > 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...
> >
> > However, any of the Hawaiian
> > islands would be a great choice, given the ease of travel
> arrangements, the
> > warm weather which reduces the need for much of the luggage (no need
> for
> > warm clothes),
> 
> IEEE 802 wireless interim meetings in September have been at the
> Waikoloa Resort for the last few years.  The meeting rooms are so
> heavily air condituoned that the attendees now know to bring a sweater
> to the meeting.

Bad luck/poor communication?  The meetings I've attended there (both IEEE &
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Gondrom | 1 Sep 2010 11:05
Favicon

Re: IETF Attendance by continent

 On 09/01/2010 07:35 AM, Yoav Nir wrote:
> On Aug 31, 2010, at 4:56 PM, Iljitsch van Beijnum wrote:
>
>>> Consider that contributors
>>> usually start as newcomers, attend several meetings, then write a draft,
>> I don't know about you, but I wrote drafts before my first meeting.
> Me too. I actually had an RFC published two months before attending my first meeting.
>
> As an employee (rather than an independent consultant) if I ask my bosses to go to an IETF meeting, their
first question is what am I going to do there.  A good answer is that I want to present this draft in that
working group, participate in this discussion at another working group, and meet this person to talk
about that subject.
>
> If I just said I want to go to some meetings, and listen to stuff, and see if I hear anything interesting,
they'd tell me to use the audio stream for that.
>
> OTOH we've all seen a whole bunch of people at meetings who always sit in the back, faces buried in their
laptops, and never participating in any discussion.  I'm not sure what value their employer gets from
their participation, but I guess both models exist.
You are right, I did so too (and presented my first draft at the first
meeting). However, I would say it was a bit exciting and the quality of
my I-D improved drastically after the meeting and receiving direct
(face-to-face) feedback and advise from a number of people at the
meeting. If I wouldn't have gone there, it might also have been my last
I-D. And there is a lot going on beyond the meeting itself (or its audio
stream which we didn't have back then when I started), e.g. the informal
follow-up conversations with others after the meeting triggered by their
questions and comments and feedback from the WG chair or AD on a draft
and how to progress after the meeting can be equally valuable as the
meeting itself.
(Continue reading)

Permalink | Reply | 0 comments |
headers
DESCOMBES Thierry | 1 Sep 2010 11:29
Picon
Picon

IPFIX and netflow timestamps

Hello,

I am currently developing a collector NetFlow / IPFIX. I have read (and printed RFCs 5655, 5101, 5102 ...) and I did not understand where and how is defined the " Corresponding encoding specifications for types: dateTimeSeconds / dateTimeMilliseconds (used with types flowStartSysUpTime, flowEndSysUpTime, systemInitTimeMilliseconds, flowStartMicroseconds, flowEndMicroseconds, flowStartDeltaMicroseconds, flowEndDeltaMicroseconds).
I came across a post ( http://www.ietf.org/mail-archive/web/ipfix/current/msg03947.html ), which explicitly describes a data format ... but in the RFC, I can not find the same information.

I am trying to decode the flow with an accuracy of one second. Is there a simple and standard way to do that ? (Or should I deal with the possible combinations with these fields ?)

Thanks in advance.
Regards

Thierry Descombes
LPSC - CNRS 
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Sep 2010 11:53
Favicon

Re: NAT behavior for IP ID field

On 31 aug 2010, at 22:04, John Kristoff wrote:

> I'm trying to locate an RFC that spells out the behavioral
> requirements, expectations or guidelines for NAT handling of the IP ID
> field, particularly for UDP messages.

> If this is not written down anywhere, do NATs generally rewrite the ID
> field with or without the MF bit set?

I don't know.

We had a discussion about this in the BEHAVE working group while working on stateful IPv6-to-IPv4
translation. Unless I missed something, the ID field needs uniqueness for any combination of source,
destination IP addresses and protocol. Assuming the source address doesn't change, this means an ID
counter should be maintained per destination address + protocol pair, so the maximum number of packets
can be transmitted for each such pair before an ID value is reused. This would be the optimal host behavior,
and NATs should act like hosts in this regard. Reusing the ID field from the original packet has a much
higher chance of seeing the same ID field for outstanding fragments of a different flow, which can cause
undetected data corruption in 1 in 65535 cases when the TCP/UDP checksum doesn't
  catch this.

Note that DF=1 doesn't save you from all of this, as RFC 2402 says:

   Mutable (zeroed prior to ICV calculation)
             Type of Service (TOS)
             Flags

So it is legal to rewrite the DF bit from 1 to 0. I also know that this happens in the wild because I used to do this
at one time.
Permalink | Reply | 4 comments |
headers
Marshall Eubanks | 1 Sep 2010 16:56
Picon

Re: IETF Attendance by continent

On Aug 28, 2010, at 1:25 PM, Scott Brim wrote:

> On 08/28/2010 12:28 EDT, Adrian Farrel wrote:
>> And even closer to 3:2:2 ?

I think that people have unreasonable expectations about what we can do here.

There are 3 meetings per year, and 3 meeting regions being considered, and we are generally considering
something between 1 and 3 years out at any time. 

Suppose that the time horizon is 2 years. Then, an equal meeting schedule is 

2:2:2 (which is equivalent to 1:1:1, of course).

If we shift one meeting, we have

3:2:1  (the current proposal) - or 1:0.66:0.33

If we shift 2 meetings, we have 

4:1:1  - or 1:0.25:0.25

and that's it. Without having no meetings in some region, 1:1:1, 3:2:1, or 4:1:1 is all we can chose between
with a 2 year horizon. 

(You have to chunk the meetings somehow to get these ratios; doing by calendar years is a very reasonable
chunk that fits well with the way that meetings are scheduled.)

Suppose that our time horizon is 3 years - then an equal meeting schedule is

3:3:3 and we can shift meetings to produce

4:3:2 - or 1:0.75:0.5
4:4:1 - or 1:1:0.25
5:2:2 - or 1:0.4:0.4
5:3:1 - or 1:0.6:0.2
6:2:1 - or 1:0.33:0.16
7:1:1 - or 1:0.14:0.14

and that's it (without dropping some region entirely). 

So, for example, instead of 3:2:2 (or 1:0.66:0.66) I would recommend 4:3:2 for the next 3 years
(the closest triplet using an absolute value sum metric on the differences). 4:3:2 would be easier to do
than 3:2:2 based on the way we schedule and review meeting locations.

Now, of course, meeting locations do get moved, and 4:3:2 might easily turn into 4:4:1 or 3:3:3 based on
contingencies. 

I do not think it is reasonable to apply a time horizon of > 3 years to IETF meeting locations. Attendance is
changing too rapidly for that.

Regards
Marshall 

> 
> +0.2
> _______________________________________________
> Ietf mailing list
> Ietf <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Permalink | Reply | 11 comments |

Gmane