Subject: Re: [Gen-art] Gen-ART review of draft-krishnan-v6ops-teredo-update-07

From: Suresh Krishnan <[email-masked]>
Date: Tue, 1 Jun 2010 19:38:06 -0400

Hi David,
   Thanks a lot for your comments. Please see responses inline.

On 10-05-28 07:30 PM, [email-masked] wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-krishnan-v6ops-teredo-update-07
> Reviewer: David L. Black
> Review Date: 28 May 2010
> IESG Telechat date: 3 June 2010
> 
> Summary:
> This draft is basically ready for publication, but has nits that should be fixed before publication.
> 
> This is a reasonably well written short draft that injects randomness into Teredo IPv6 address generation and deprecates the Teredo cone bit.
> 
> 
> The -07 version of this draft has not addressed the comments from the Gen-ART review of the -06 version, beyond correcting two of the four nits that idnits found.
> 
> I found a few nits:
> 
> (1) The first nit is right at the start of the draft (!).  This draft is clearly intended to update RFC 4380, but "Updates: 4380" is missing from the draft header on p.1.  Please add that.

OK. Will do.

> 
> (2) Section 3.2 on p.6 uses the acronyms RA and RS - they need to be expanded on first use.

OK. Will do.

> 
> (3) The first paragraph in the Security Considerations section (5) states the goal of comparable address prediction resistance (security) wrt a host directly attached to an untrusted Internet link, but nothing in the Security Considerations section indicates how close the technique in this draft comes to achieving that goal.  I suggest adding a short discussion of how 13 random bits compares with the level of randomness that can be expected from native IPv6 address assignment mechanisms.

I am not sure what to say here. We expand the difficulty of address 
prediction by 2^12 as compared to the base RFC4380. If we compare it to 
base SLAAC there are too many variables (the different factors that are 
known to an attacker like External IPv4 address, external port etc.) to 
make a useful comparison. If we provide a comparison based on a chosen 
set of variables, would that work?

> 
> (4) idnits 2.12.04 found two more nits that should be easy to address:

Will fix these nits. I was running an earlier version (1.34) of xml2rfc 
and I have now upgraded to 1.35.

Thanks
Suresh

---

From: <[email-masked]>
Date: Wed, 2 Jun 2010 04:29:20 -0400

Hi Suresh,

> > (3) The first paragraph in the Security Considerations section (5)
states the goal of comparable
> address prediction resistance (security) wrt a host directly attached
to an untrusted Internet link,
> but nothing in the Security Considerations section indicates how close
the technique in this draft
> comes to achieving that goal.  I suggest adding a short discussion of
how 13 random bits compares with
> the level of randomness that can be expected from native IPv6 address
assignment mechanisms.
> set of variables, would that work?

I think so - some advice from a former professor applies: "Make any
assumptions that you think are reasonable, but state your assumptions."
An exhaustive security analysis of IPv6 address generation is not
needed, so discussion of one or two common cases to indicate the degree
of progress towards the goal should suffice.

Thanks,
--David

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Tuesday, June 01, 2010 7:38 PM
> To: Black, David
> Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-krishnan-v6ops-teredo-update-07
> 
> Hi David,
> > This is a reasonably well written short draft that injects
randomness into Teredo IPv6 address
> generation and deprecates the Teredo cone bit.
> >
> >
> > The -07 version of this draft has not addressed the comments from
the Gen-ART review of the -06
> version, beyond correcting two of the four nits that idnits found.
> >
> > I found a few nits:
> >
> > (1) The first nit is right at the start of the draft (!).  This
draft is clearly intended to update
> RFC 4380, but "Updates: 4380" is missing from the draft header on p.1.
Please add that.
> > (3) The first paragraph in the Security Considerations section (5)
states the goal of comparable
> address prediction resistance (security) wrt a host directly attached
to an untrusted Internet link,
> but nothing in the Security Considerations section indicates how close
the technique in this draft
> comes to achieving that goal.  I suggest adding a short discussion of
how 13 random bits compares with
> the level of randomness that can be expected from native IPv6 address
assignment mechanisms.

---

From: <[email-masked]>
Date: Thu, 3 Jun 2010 10:51:51 -0400

The -09 version of this draft satisfactorily addresses all of the items from the Gen-ART review of the -07 version.

Thanks,
--David

> From: Black, David
> Sent: Friday, May 28, 2010 7:30 PM
> To: [email-masked]'; [email-masked]'; [email-masked]'; 'gen-
> [email-masked]'
> Cc: Black, David; 'Jari Arkko'
> Subject: Gen-ART review of draft-krishnan-v6ops-teredo-update-07
> 
> This is a reasonably well written short draft that injects randomness into Teredo IPv6 address
> The -07 version of this draft has not addressed the comments from the Gen-ART review of the -06
> (1) The first nit is right at the start of the draft (!).  This draft is clearly intended to update
> RFC 4380, but "Updates: 4380" is missing from the draft header on p.1.  Please add that.
> 
> (3) The first paragraph in the Security Considerations section (5) states the goal of comparable
> address prediction resistance (security) wrt a host directly attached to an untrusted Internet link,
> but nothing in the Security Considerations section indicates how close the technique in this draft
> comes to achieving that goal.  I suggest adding a short discussion of how 13 random bits compares with
> the level of randomness that can be expected from native IPv6 address assignment mechanisms.
> 
>   == You're using the IETF Trust Provisions' Section 6.b License Notice from
>      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>      http://trustee.ietf.org/license-info/)
> 
> --> Just copy the boilerplate.
> 
>   == No 'Intended status' indicated for this document; assuming Proposed
>      Standard
> 
> --> Add the Intended status line.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 3 Jun 2010 14:03:24 -0400

> The -09 version of this draft satisfactorily addresses all of the items from the Gen-ART review of the -07 version.

Thanks David

Cheers
Suresh