Subject: 6MAN - active documents

From: Ole Troan <[email-masked]>
Date: Mon, 19 Aug 2013 11:25:01 +0200

In working group last call:
  draft-ietf-6man-oversized-header-chain-04    (ending August 27th)
  draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)

*** We are awaiting document reviewer volunteers for these two. Please contact the chairs.
    (No prizes, but we might offer a beer for the first two! ;-))

Awaiting new revision:
  draft-ietf-6man-ext-transmit-02 (WGLC ended August 1st)
  draft-ietf-6man-ug-02 (WGLC ended August 1st)

Documents in the pipeline:
  draft-ietf-6man-resilient-rs-01 (Ready for WGLC)
  draft-gont-6man-ipv6-smurf-amplifier-03 (Ready for Call for adoption)

For other documents we try to keep the document status at
https://datatracker.ietf.org/wg/6man/ up to date.

Best regards,
Ole & Bob

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 20 Aug 2013 10:32:32 +0200 (CEST)

>  draft-ietf-6man-oversized-header-chain-04    (ending August 27th)

I have read this document and found no problem with it, and I support its 
progression.

>  draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)

--------------------------------------------------------------------
NIT:

F():
           A pseudorandom function (PRF) that is not computable from the
           outside (without knowledge of the secret key), which should
           produce an output of at least 64 bits.The PRF could be
           implemented as a cryptographic hash of the concatenation of
           each of the function parameters.

Missing space in the middle line.

-------------------------------------------------------------------

secret_key:
           A secret key that is not known by the attacker.  The secret
           key MUST be initialized at operating system installation time
           to a pseudo-random number (see [RFC4086] for randomness
           requirements for security).  An implementation MAY provide the
           means for the the system administrator to change or display
           the secret key.

I think the text here should be that i MUST be initialized when the 
functionality is enabled (or equivalent). I haven't re-installed my 
operating system for 8 years, I have just upgraded it. Also, this 
functionality might be a later add-on to an existing version of the 
operating system, and the functionality might be an add-on to the 
connection manager, completely independent of the operating system.

-------------------------------------------------------------------

There are numerous references to DAD. Isn't DAD attacks handled in other 
documents that can be referenced, does this document really need to 
outline this behaviour, perhaps even in conflict with other documents? I 
don't remember where I read about this though, perhaps someone else knows? 
It was discussed in SAVI anyway.

I think it would be good to reference SAVI-WG documents on first-hop 
security instead of writing new text on the subject. People seem to like 
SEND, but I see send as hard to deploy in most scenarios because one 
entity doesn't control both router and device. I prefer the network 
protecting using filtering instead of trying to cryptographically assure 
that the RAs seen is from the router.

http://datatracker.ietf.org/wg/savi/ RFC 6620 would be one document to 
reference in this case.

Network_ID mentions SSID. What if I have an ethernet Interface and I move 
my computer around, should it identify a new set of /64 network address 
and/or gateway MAC address as a new network as well? I think some text on 
this would be good guidance for implementors.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Aug 2013 23:59:26 -0300

Hi, Mikael,

Thanks so much for your feedback! -- Please find my comments in-line...

>>  draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)

Will fix this in the next rev.

> functionality is enabled (or equivalent). 

I see you point. I guess something like "...initialized when this method
is installed (e.g. at operating system installation time)" would do?

> don't remember where I read about this though, perhaps someone else
> knows? It was discussed in SAVI anyway.

This document discusses how to recover from DAD failures -- *this* is
not discussed elsewhere.

> security instead of writing new text on the subject. 

Where, specifically?

> People seem to like
> entity doesn't control both router and device. 

+1 -- and there's the PKI issue, etc.

> Network_ID mentions SSID. What if I have an ethernet Interface and I
> move my computer around, should it identify a new set of /64 network
> address and/or gateway MAC address as a new network as well? I think
> some text on this would be good guidance for implementors.

That's left unspecified, since it might be tricky: there's might be more
than one local router, for redundancy purposes -- but since it's the
same network, you'd want your addresses to be stable.

That's why in the SSID example we use the SSID, and not the router's MAC
address or the like.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Aug 2013 05:16:41 +0200 (CEST)

> This document discusses how to recover from DAD failures -- *this* is

I've seen this discussion in SAVI a few years back. I can't find any 
documents now though so I don't know if it actually ended up anywhere.

>> security instead of writing new text on the subject.

Under 7 where ra-guard is mentioned. Oh, btw, the paragraph on 
RA-guard is missing a trailing ".".

> That's why in the SSID example we use the SSID, and not the router's MAC

If it's tricky, doesn't that specifically warrant more text on the 
subject?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Aug 2013 00:51:55 -0300

On 08/21/2013 12:16 AM, Mikael Abrahamsson wrote:
> Under 7 where ra-guard is mentioned. Oh, btw, the paragraph on RA-guard
> is missing a trailing ".".

Does SAVI prevnt forged RAs? -- Because that's why RA-Guard is being
referenced.

> If it's tricky, doesn't that specifically warrant more text on the subject?

The Network_ID parameter is optional. If you can come up with a
Network_ID for your network, you can use it. However, in the case of
Ethernet I don't think there's an obvious candidate. So I'd persoanlly
leave the text as is.

Cheers,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Aug 2013 06:17:17 +0200 (CEST)

> Does SAVI prevnt forged RAs? -- Because that's why RA-Guard is being 

Well, yes, it's within the charter anyway.

http://datatracker.ietf.org/wg/savi/charter/

SAVI-WG aims to solve all kinds of first hop security problems. 
Unfortunately there has been too little atention on SAVI lately.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 21 Aug 2013 00:36:05 -0400

Hi Fernando/Mike,

> some text on this would be good guidance for implementors.

RFC6059 is targeted at this problem (identifying attachment to a new
network). It does require changes to host data structures but there are
concepts there you can refer to/reuse.

Thanks
Suresh