Subject: [OPSEC] IPv6 LL-only as WG document - feedback requested

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 6 Aug 2012 09:03:06 +0000

(distributed to OPSEC WG and in cc v6ops)

Dear all,

During the OPSEC WG meeting last Wednesday there was consensus to adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working group document with Informational status.

Please read the draft, and if there is no violent objection on the list, the document will be requested to be submitted as WG document in 7 days.

Ciao,
G/, KK & Warren

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 6 Aug 2012 09:36:18 +0000

Answer as individual contributor.

Fred B. and myself did a draft to exactly address the traceability of interfaces without 
increasing the attack vector on interfaces: Passive IPv6 addresses

No new class of addresses at all... no new IANA allocation... just behaviour of the address:

1) it is configured as a normal address
2) just an extra keyword attached to the address identifying its behavior
3) It can only be used as a 'source' address
4) if it is used as destination address, then when reaching the router it will be directed to the Null0 interface

This will help visibility of the trace-route in cases of LL-only...

G/

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 06 August 2012 11:25
To: Gunter Van de Velde (gvandeve)
Cc: [email-masked]; v6ops v6ops WG ([email-masked]); [email-masked]; [email-masked]' ([email-masked])
Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested

Hi,

>    o  Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo
>       request ... can be addressed to loopback addresses of routers with
>       a global scope address.  Router management can also be done over
>       out-of-band channels.
> 
>    o  ICMP error message can also be sourced from the global scope
>       loopback address.

These statements seem too weak. Using GUAs for ICMP in particular needs to have a normative MUST somewhere (preferably in a BCP). In the context of this Informational draft, the language needs to state a requirement ("must" not "can") even if you don't use RFC 2119 terminology.

This matters because packets with a LL source address MUST NOT be forwarded, so a router that is misconfigured to send ICMP replies with a LL source address breaks both ping and traceroute.

I think the rule is that any packet that is *not* sent to a LL address must have a GUA as the source address. That takes care of ICMP, and everything else as well.

Furthermore, that GUA needs to be associated with a prefix that belongs to the organisation operating the router in question. Otherwise the traceroute results can be very confusing. We discussed that on v6ops back in March.

Regards
   Brian Carpenter

On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote:
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 6 Aug 2012 10:18:31 +0000

I am confused. Please correct my understanding if possible.

1) You are ok with the Behringer-LL draft being an informational draft? (not BCP)
2) Passive addresses is something that creates potential issues in your view?

For (2) I would say... It is just as a normal address... no need at all to discard them on any other box then the receiving box as those boxes just see the address as being a normal IPv6 address. Nothing special about it. It is just a normal address. The behaviour of passive addresses is to do with the way the recipient device deals with this address.

G/

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 06 August 2012 11:40
To: Gunter Van de Velde (gvandeve)
Cc: [email-masked]; v6ops v6ops WG ([email-masked]); [email-masked]; [email-masked]' ([email-masked])
Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested

Hi Gunter,

I have no problem with the passive address idea, but the immediate issue is that routers must not source ICMP packets that other routers must discard - hence no LL source addresses.

    Brian

On 06/08/2012 10:36, Gunter Van de Velde (gvandeve) wrote:
> Fred B. and myself did a draft to exactly address the traceability of 
> interfaces without increasing the attack vector on interfaces: Passive 
> IPv6 addresses
> 
> 4) if it is used as destination address, then when reaching the router 
> it will be directed to the Null0 interface
> 
> Cc: [email-masked]; v6ops v6ops WG ([email-masked]); 
> [email-masked]; [email-masked]' 
> ([email-masked])

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 6 Aug 2012 10:57:15 +0000

I agree... packets with LL source-address should not leave the link indeed.

I expect the Behringer editor team to make that more specific in the draft text.

G/

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 06 August 2012 12:53
To: Gunter Van de Velde (gvandeve)
Cc: [email-masked]; v6ops v6ops WG ([email-masked]); [email-masked]; [email-masked]' ([email-masked])
Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested

> 1) You are ok with the Behringer-LL draft being an informational 

Yes. All I'm saying is that it should insist on a valid source address, which means that a LL source address is not allowed for packets that leave the local link.

Section 2.5.6 of RFC 4291 makes this clear but people seem to ignore it:
"Link-Local addresses are for use on a single link."

Obviously, therefore, packets whose destination is not LL must not have a LL source address.

> 2) Passive addresses is something that creates potential issues in your view?

I said I have no problem with that. It doesn't affect the above point.

   Brian
>> 4) if it is used as destination address, then when reaching the 
>> router it will be directed to the Null0 interface
>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --
>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2012 10:24:47 +0100

Hi,

>    o  ICMP error message can also be sourced from the global scope

These statements seem too weak. Using GUAs for ICMP in particular
needs to have a normative MUST somewhere (preferably in a BCP). In the
context of this Informational draft, the language needs to state a requirement
("must" not "can") even if you don't use RFC 2119 terminology.

This matters because packets with a LL source address MUST NOT be forwarded,
so a router that is misconfigured to send ICMP replies with a LL source
address breaks both ping and traceroute.

I think the rule is that any packet that is *not* sent to a LL address must
have a GUA as the source address. That takes care of ICMP, and everything else
as well.

Furthermore, that GUA needs to be associated with a prefix that belongs to
the organisation operating the router in question. Otherwise the traceroute
results can be very confusing. We discussed that on v6ops back in March.

Regards
   Brian Carpenter

On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote:
> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2012 10:40:08 +0100

Hi Gunter,

I have no problem with the passive address idea, but the immediate issue
is that routers must not source ICMP packets that other routers must
discard - hence no LL source addresses.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2012 11:52:53 +0100

> 1) You are ok with the Behringer-LL draft being an informational draft? (not BCP)

Yes. All I'm saying is that it should insist on a valid source address,
which means that a LL source address is not allowed for packets that leave
the local link.

Obviously, therefore, packets whose destination is not LL must not
have a LL source address.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 6 Aug 2012 11:26:58 +0000

> From: Gunter Van de Velde (gvandeve)
> Sent: 06 August 2012 11:57
> To: Brian E Carpenter
> Cc: [email-masked]; v6ops v6ops WG ([email-masked]); opsec-
> [email-masked]; [email-masked]' (draft-behringer-
> [email-masked])
> Subject: RE: [v6ops] IPv6 LL-only as WG document - feedback requested
> 

This was sort of implied (and mentioned during presentations), but needs to be made clearer, agreed. We'll include this in the next revision. 

Thanks for the feedback Brian! 

Michael

> Cc: [email-masked]; v6ops v6ops WG ([email-masked]); opsec-
> [email-masked]; [email-masked]' (draft-behringer-
> [email-masked])
> Yes. All I'm saying is that it should insist on a valid source address, which
> means that a LL source address is not allowed for packets that leave the
> local link.
> 
> > For (2) I would say... It is just as a normal address... no need at all to
> discard them on any other box then the receiving box as those boxes just
> see the address as being a normal IPv6 address. Nothing special about it. It
> is just a normal address. The behaviour of passive addresses is to do with
> the way the recipient device deals with this address.
> >
> > G/
> >
> >
> >
> >
> is that routers must not source ICMP packets that other routers must discard
> - hence no LL source addresses.
> >
> >     Brian
> >
> context of this Informational draft, the language needs to state a
> requirement ("must" not "can") even if you don't use RFC 2119 terminology.
> >>
> >> This matters because packets with a LL source address MUST NOT be
> forwarded, so a router that is misconfigured to send ICMP replies with a LL
> source address breaks both ping and traceroute.
> >>
> have a GUA as the source address. That takes care of ICMP, and everything
> else as well.
> >>
> >> Furthermore, that GUA needs to be associated with a prefix that belongs
> to the organisation operating the router in question. Otherwise the
> traceroute results can be very confusing. We discussed that on v6ops back in
> March.
> >>
> >> Regards
> >>    Brian Carpenter
> >>
> >>
> >>
> >>
> >>> During the OPSEC WG meeting last Wednesday there was consensus to
> adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as
> working group document with Informational status.
> >>>
> >>> Please read the draft, and if there is no violent objection on the list, the
> document will be requested to be submitted as WG document in 7 days.
> >>>
> >>> Ciao,
> >>> G/, KK & Warren
> >>>
> >>>
> >>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 14 Aug 2012 21:08:56 +0000

Michael, Brian,

Should "The Suggested Approach" http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1 also include some prescriptiveness or specific recommendation regarding the use of RFC 5837, instead of including that solution to interface identification as a "Caveats and Possible Workarounds" only?

Thanks,

-- Carlos.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2012 08:49:46 +0100

Carlos,

> Should "The Suggested Approach" http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1 also include some prescriptiveness or specific recommendation regarding the use of RFC 5837, inste…

I have no strong opinion on this. Just indicating the existence of 5837
seems OK, though.

Looking at the current text, it says that the loopback GUA MUST be used for all
ICMPv6 messages, which is good, but it also says
"ICMP error message can also be sourced from the global scope loopback address."
That seems unnecessary in view of the MUST, but in any case, s/can/will/.

Actually my main comment on the draft is on this text in the Introduction:

"We propose to configure neither globally routable IPv6 addresses nor
 unique local addresses on infrastructure links of routers, wherever
 possible.  We recommend to use exclusively link-local addresses on
 such links."

I suggest a more neutral approach, since some operators clearly prefer
to use GUAs:

 It is possible to configure neither globally routable IPv6 addresses nor
 unique local addresses on infrastructure links of routers. This document
 describes how to use exclusively link-local addresses on such links.

(and s/proposes/describes how/ in the Abstract)

Thanks
    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 15 Aug 2012 02:41:54 -0700 (PDT)

Hi,

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Carlos Pignataro (cpignata) <[email-masked]>
> Cc: "[email-masked]' ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "v6ops v6ops WG ([email-masked])" <[email-masked]>
> Sent: Wednesday, 15 August 2012 5:49 PM
>>  Should "The Suggested Approach" 
> http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1 also include 
> some prescriptiveness or specific recommendation regarding the use of RFC 5837, 
> instead of including that solution to interface identification as a 
> "Caveats and Possible Workarounds" only?
> 

Perhaps it would be better to be even more general, and just say ICMPv6 messages must come from addresses with a scope greater than link local? Restricting to GUAs suggests the idea in this draft can only be used when GUAs are available, yet I'd think it could also be useful in a private, non-Internet connected network too.

<snip>

Regards,
Mark.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 15 Aug 2012 15:39:42 +0000

> From: Mark ZZZ Smith [mailto:[email-masked]]
[...]
> > From: Brian E Carpenter <[email-masked]>
[...]
> > http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1
> > also include some prescriptiveness or specific recommendation
> > regarding the use of RFC 5837, instead of including that solution to
> > interface identification as a "Caveats and Possible Workarounds" only?
> >
> > I have no strong opinion on this. Just indicating the existence of
> > 5837 seems OK, though.

Two comments: 
- the wording "suggested approach" is a left-over from the times when we were targeting BCP. Now as informational we'll remove the "suggested". 
- the intention of the doc is to give guidance to a network operator on whether link local is a good idea in his environment or not. Since the target is the network operator, I don’t think we should recommend the use - the operator can't do anything about it. So my suggestion would be to leave it where it is. 

Unless we want to widen the scope? (Not my preferred approach though - it's nice to have a clear scope)

> > ICMPv6 messages, which is good, but it also says "ICMP error message
> > can also be sourced from the global scope loopback address."
> 
> Perhaps it would be better to be even more general, and just say ICMPv6
> messages must come from addresses with a scope greater than link local?
> Restricting to GUAs suggests the idea in this draft can only be used when
> GUAs are available, yet I'd think it could also be useful in a private, non-
> Internet connected network too.

Good point. I'll change that. 

Thanks for the feedback! 
Michael

[...]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 16 Aug 2012 12:23:01 +0000

Brian

Thanks for your suggestion about wording. I think we agree on the content and your format is better :-)

-éric

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: mercredi 15 août 2012 09:50
> To: Carlos Pignataro (cpignata)
> Cc: [email-masked]' (draft-behringer-lla-
> [email-masked]); [email-masked]; [email-masked]; v6ops v6ops WG
> ([email-masked])
> Subject: Re: [OPSEC] [v6ops] IPv6 LL-only as WG document - feedback
> requested
> 
> Carlos,
> 
> > Should "The Suggested Approach" http://tools.ietf.org/html/draft-
> behringer-lla-only-01#section-2.1 also include some prescriptiveness or
> specific recommendation regarding the use of RFC 5837, instead of including
> that solution to interface identification as a "Caveats and Possible
> Workarounds" only?
> 
> ICMPv6 messages, which is good, but it also says "ICMP error message can
> also be sourced from the global scope loopback address."
> possible.  We recommend to use exclusively link-local addresses on  such
> links."
> 
> I suggest a more neutral approach, since some operators clearly prefer to
> use GUAs:
> 
> >> needs to have a normative MUST somewhere (preferably in a BCP). In
> >> the context of this Informational draft, the language needs to state
> >> a requirement ("must" not "can") even if you don't use RFC 2119
> terminology.
> >>
> >> forwarded, so a router that is misconfigured to send ICMP replies
> >> with a LL source address breaks both ping and traceroute.
> >>
> >> I think the rule is that any packet that is *not* sent to a LL
> >> address must have a GUA as the source address. That takes care of
> >> ICMP, and everything else as well.
> >>
> >> Furthermore, that GUA needs to be associated with a prefix that
> >> belongs to the organisation operating the router in question.
> >> Otherwise the traceroute results can be very confusing. We discussed that
> on v6ops back in March.
> >>
> >> Regards
> >>   Brian Carpenter
> >>
> >>
> >>
> >>
> >>> During the OPSEC WG meeting last Wednesday there was consensus to adopt
> the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working
> group document with Informational status.
> >>>
> >>> Please read the draft, and if there is no violent objection on the list,
> the document will be requested to be submitted as WG document in 7 days.
> >>>
> >>> Ciao,
> >>> G/, KK & Warren
> >>>
> >>>
> >>>
> >>> ----
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec