Subject: REMINDER: 6man w.g. last call for <draft-ietf-6man-maxra-01>

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Jan 2017 08:39:34 -0800

FYI

> Begin forwarded message:
> 
> From: Bob Hinden <[email-masked]>
> Subject: 6man w.g. last call for <draft-ietf-6man-maxra-01>
> Date: December 21, 2016 at 7:15:23 AM PST
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>, Ole Trøan <[email-masked]>
> 
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
>     Title           : Support for adjustable maximum router lifetimes per-link
>     Authors         : S. Krishnan
>                       J. Korhonen
>                       S. Chakrabarti
>                       E. Nordmark
>                       A. Yourtchenko
>     Filename        : draft-ietf-6man-maxra-01
>     Pages           : 6
>     Date            : July 8, 2016
> 
>     https://tools.ietf.org/html/draft-ietf-6man-maxra-01
> 
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
> end on 11 January 2017.
> 
> We also need two people to volunteer to do a detailed reviews, and a
> volunteer to be the document Shepard.
> 
> Thanks,
> Bob & Ole
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Jan 2017 15:02:00 +0900

I find section 3 (which provides guidance on how packet loss impacts
reliability, and how much redundancy to use) very useful.

Section 4 (which is the actual standards update) needs to be worded in more
detail. For example, it should ensure that 0 values continue to be valid
and have the same meaning as before the update. (At least to me, a literal
reading of the current text suggests that 0 is no longer a valid value
for AdvDefaultLifetime.) Perhaps a better approach would be to simply say
that the 1800 and 9000 values specified in section 6.2.1 or RFC4861 are
hereby replaced by 65535

Given that the text allows MaxRtrAdvInterval to be up to 65535, should
the MaxRtrAdvInterval be bounded to 65534 (not 65535) to ensure that the RA
arrives before the timer expires?

On Thu, Jan 5, 2017 at 1:39 AM, Bob Hinden <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 Jan 2017 11:54:12 +0000

Hi,

Just a brief comment on the Security Considerations.

This draft could mention RFC6105; currently it only says that rogue RAs can “easily” be prevented through use of SeND, but in practice RA Guard approaches are the common mitigation.  I’m also not sure the “attack window” changes; there is either a rogue RA or there isn’t, regardless of the true RA interval.

Tim 

> On 4 Jan 2017, at 16:39, Bob Hinden <[email-masked]> wrote:
> 
> FYI
> 
>> Begin forwarded message:
>>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 6 Jan 2017 04:01:23 +0000

Hi Lorenzo,

On 01/05/2017 01:02 AM, Lorenzo Colitti wrote:
> detail. For example, it should ensure that 0 values continue to be valid and
> have the same meaning as before the update. (At least to me, a literal
> for AdvDefaultLifetime.)

Yes. I do now see that reading as possible as well. Suggest the following change

OLD:

MaxRtrAdvInterval MUST be no greater than 65535.  AdvDefaultLifetime MUST be 
between MaxRtrAdvInterval and 65535.

NEW:

MaxRtrAdvInterval MUST be no greater than 65535.  AdvDefaultLifetime MUST 
either be zero (the router is not to be used as a default router) or be a 
value between MaxRtrAdvInterval and 65535.

Does that work?

"
Perhaps a better approach would be to simply say
> that the 1800 and 9000 values specified in section 6.2.1 or RFC4861 are

See above. Either change works for me.

> arrives before the timer expires?

Hmm. Not sure about this. According to Section 6.2.4. of RFC4861 the 
multicast RA is sent on a "timer that is set to a uniformly distributed 
random value between MinRtrAdvInterval and MaxRtrAdvInterval".  That should 
take care of it automatically*, right?

Thanks
Suresh

*: Not sure about other implementations but I interpreted this range as 
excluding the MinRtrAdvInterval and MaxRtrAdvInterval (but this might be 
worth checking).

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 6 Jan 2017 04:11:01 +0000

Hi Tim,

> This draft could mention RFC6105; currently it only says that rogue RAs can “easily” be prevented through use of SeND, but in practice RA Guard approaches are the common mitigation.  I’m also not s…

Adding a reference to RA guard sounds like a good idea. Will do. The attack 
window is larger because the damage from the rogue RA can persist longer 
before getting overridden by a legitimate RA. I don't have strong feelings 
about keeping the "attack window" wording though.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jan 2017 01:23:26 -0300

> about keeping the "attack window" wording though.

My interpretation of "attack window" is along the lines of "amount of
time the attacker has to do his thing". In this respect the attack
window does not change. What changes is the persistence of the effects
of the attack (for *some* RA-based attacks).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492