Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)

[Fernando Gont]

Folks,

We have been discussing the potential problems associated with SLAAC 
renumbering events for a while now -- one of the most common cases being 
ISPs rotating home prefixes, and your devices ending up with 
stale/invalid addresses.


We have done quite a bit of work already:

  * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978
  * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096

But there's still some work to do to address this issue: The last 
remaining it is to improve SLAAC such that hosts can more gracefully 
deal with this renumbering events.


In that light, IETF's 6man has been working on this document: 
https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt


And we have proposed a simple algorithm for SLAAC (an extension, if you 
wish) that can easily help, as follows:


If you (host) receive an RA that contains options, but not all
of the previously-received options/information, simply send a
unicast RS to the local-router, to verify/refresh that such missing
information is still valid. If the information is stale, get rid of
it.

I presented this algorithm at the last IETF meeting 
(https://youtu.be/eKEizC8xhhM?t=1308).


(You may find the slides here: 
https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00)


Finally, I've sent draft text for the specification of the algorithm 
here: 
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/


We would be super thankful if you could take a look at the draft text 
(i.e., 
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) 
and provide feedback/comments.


If you can post/comment on the 6man wg mailing list 
(https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous.
But we'll appreciate your feedback off-line, on this list, etc. (that'd 
still be great ;-) )


Thanks in advance!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

Operational Implications of IPv6 Extension Headers (Fwd: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt)

[Fernando Gont]

Hi, folks,

After almost 7+ years of working on this topic, our internet-draft 
entitled Operational Implications of IPv6 Packets with Extension 
Headers¨ 
(https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08), 
has been approved for publication as an IETF RFC.


I believe it iś of value for folks working in security and/or network 
operations.


Kudos to my co-authors for enduring the process, and to Nick Hilliard 
who did the last push to get this one approved.


Thanks!

Cheers,
Fernando




 Forwarded Message 
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt
Date: Fri, 11 Jun 2021 09:28:16 -0700
From: internet-dra...@ietf.org
Reply-To: v6...@ietf.org
To: i-d-annou...@ietf.org
CC: v6...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the IPv6 Operations WG of the IETF.

Title   : Operational Implications of IPv6 Packets with 
Extension Headers

Authors : Fernando Gont
  Nick Hilliard
  Gert Doering
  Warren Kumari
  Geoff Huston
  Will (Shucheng) Liu
Filename: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt
Pages   : 20
Date: 2021-06-11

Abstract:
   This document summarizes the operational implications of IPv6
   extension headers specified in the IPv6 protocol specification
   (RFC8200), and attempts to analyze reasons why packets with IPv6
   extension headers are often dropped in the public Internet.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: IPv6 addressing: Gaps? (draft-gont-v6ops-ipv6-addressing-considerations)

[Fernando Gont]

Folks,

FYI. The intent is to discuss this on the IETF v6ops wg list 
(https://www.ietf.org/mailman/listinfo/v6ops).


But comments will be appreciated, regardless of the specific channel 
(whether on this list, off-list, etc.)


Thanks!

Regards,
Fernando




 Forwarded Message 
Subject: IPv6 addressing: Gaps? 
(draft-gont-v6ops-ipv6-addressing-considerations)

Date: Fri, 12 Feb 2021 18:50:48 -0300
From: Fernando Gont 
To: IPv6 Operations 

Folks,

In the aforementioned document 
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations), 
we have tried to do at least three things:


1) Look at what we have and try to discuss things from an architectural
   perspective

2) Analyze the implications of #1 (whether operations, security,
   privacy, etc.)

3) Find missing gaps that currently prevent us from fully leveraging
   IPv6 addressing.


Part of what we've found as doing #3 above is that:

  * There are shortcomings associated with the current APIs that prevent
better usage of IPv6 addresses

  * Multi-router/multi-prefix routing seems to be broken.
RFC8028 would be a fundamental starting point in the right
direction... but I believe there's more to do in this area.


In that light, we'd like to hear further comments on our document. And, 
in particular, we're interested to hear if :


  * there are any operational implications of IPv6 addressing that we
have missed, or,

  * there's anything related to IPv6 addressing that you consider to
be currently broken or problematic, that is missing in our I-D.


Thoughts on the current contents of the I-D are, of course, also very 
welcome!


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)

[Fernando Gont]

Folks,

We have posted a rev of our IETF I-D "Operational Implications of IPv6 
Packets with Extension Headers".


The I-D is available at: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt


Your feedback will be appreciated.

Thanks!

Cheers,
Fernando




 Forwarded Message 
Subject: New Version Notification for 
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt

Date: Sat, 25 Jul 2020 22:28:50 -0700
From: internet-dra...@ietf.org
To: Fernando Gont , Gert Doering 
, Geoff Huston , Warren Kumari 
, Nick Hilliard 



A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:   draft-gont-v6ops-ipv6-ehs-packet-drops
Revision:   04
Title:  Operational Implications of IPv6 Packets with Extension Headers
Document date:  2020-07-25
Group:  Individual Submission
Pages:  15
URL: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
Htmlized: 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04


Abstract:
   This document summarizes the security and operational implications of
   IPv6 extension headers, and attempts to analyze reasons why packets
   with IPv6 extension headers may be dropped in the public Internet.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 2/4/20 03:19, Gert Doering wrote:

Hi,

On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote:

On 1/4/20 14:16, Gert Doering wrote:
[...]

Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
because it doesn't work.


Would you mind elaborating on this one?


Which of the two parts? :-)

As far as I understand, the official IETF recommendation for "how to
run a home with multiple subnets" is "homenet / HNCP" now, which distributes
individual /64s via HNCP, not whole prefixes via DHCPv6-PD.


I haven't been following homenet, to be honest. Is it widely implemented?




The reason why I state "DHCPv6 doesn't work" is "in practice".  There is
a practical lack of interest from vendors to make it work properly (as in,
you can properly tie the delegated prefix(es) to ACLs, for example).

On the "why is this a bad idea to start with" side, the chunkiness of
subnet distribution makes it really unsuitable for anything but the most
simple 1-level hierarchy.


So, ISP-to-customer, delegates a /56.  Next-level router asks for a prefix,
and gets... what?  Third-level router asks for a prefix, and gets what?


I guess a % of what was originally leased?

In any case, I'm not sure one would do much more than 2 or three 
hierarchies of  DHCPv6-PD.


And when it comes to the home, if the CPE could do PD on the LAN side, 
most current needs would be covered.


Clearly, without a requirements of how many levels you want to support, 
it's impossible to tell how you might want to partition your address space.


And the desire to delegate prefixes is also a bit at odds with the 
strict definition of /64 subnets which end up using a huge address space 
with a very low host density.





Corporate ISP-to-customer delegates a /48, so theoretically, there are
"enough /56s in there to do lots of PD delegation to next-level routers" -
but in practice, a /48 is supposed to be sufficient for a good-sized
office building with *lots* of internal structure, and as soon as you
have lots of internal network segments, you have no liberty to just give
out random /56s here and there anymore.


But, in that case, I'm not sure you'd want *dynamic* leases.




Now, abandon the idea of "multi-level" DHCPv6-PD, and just assume "all
you'll ever see is mobile clients asking for a single /64" (which, as
I heard, is thinking too small, because you can have stacks of stacks,
but stick to the /64 for the moment).  Normally, you'd assign a /64 per
network segment - office LAN floor 1, 2, 3, guest LAN, etc. - and have
(effectively) an infinite number of addresses for more machines than
you can ever connect. 


Just curious: what would be the use case of /64 per host (besides trying 
to limit number of entries in the NC, etc.)?


Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 1/4/20 14:16, Gert Doering wrote:

Hi,


[...]


Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
because it doesn't work.


Would you mind elaborating on this one?

--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 1/4/20 09:12, sth...@nethelp.no wrote:

There are several reasons that people shout about DHCPv6:

...

- politics: probably the most contentious area. One well-known example
- is how ipv6 on cellular impacts carrier vs handset control
- politics. 3GPP specifies that the ppp context for tethering must
- support SLAAC and therefore it provides a /64 for LAN
- connectivity. This means that the handset applications have as much
- address space as they need.  The argument goes that if DHCPv6 were a
- viable option for this, then the mobile operators would effectively
- wrestle control of the applications running on the handset (and
- ultimately control of the handset capabilities itself away from the
- handset software vendors) by handing control of the number of
- available IPv6 addresses to the cellular operator.  This is, at least,
- the reason cited by the Android authors for the point-blank refusal to
- implement DHCPv6 in android (bug ID 32621).


We are already 90% of the way here: Make IA_PD work for hosts, not
just for routers. That way Android handsets can have as many addresses
as they want.


You mean e.g. support IA_PD at CPEs on the LAN side?

Thanks!

Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 31/3/20 16:03, Gert Doering wrote:

Hi,

On Tue, Mar 31, 2020 at 03:10:50PM -0300, Fernando Gont wrote:

So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
should cope with Android.

Probably they don't.


I'm working with one enterprise right now, and one of the options on
the table is "have a separate wifi segment for android with SLAAC,
and use the NAC software in place to bump android devices to that
subnet".

Which is a major PITA...

(What they *want* is "IPAM shows what IPv6 address is in use on which
device in the network", which DHCPv6 would do nicely, including
static assignments via DHCP reservations - while everything else
relies on "IPv6/MAC ND logging on the router" or other disintegrated
fumbling...)


IMO, the work of folks doing standardization should be to provide the 
tools such that folks running networks can pick whatever they feel fits 
best.


IPv6 automatic configuration is kind of a mess (an artifact of history 
and religious battle).  That's what folks like myself respond when asked 
what's the rationale for what we have.


Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 31/3/20 12:59, Gert Doering wrote:

Hi,

On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote:

When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't
see the need to allocate a dynamic address if the autogenerated are used.


"control" in the sense of "the management station can see which client
is reachable under which IPv6 address"...  and possibly "and put in proper
forward and reverse DNS entries".

So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
should cope with Android.


Probably they don't.


FWIW, it's quite interesting to see the same folks ditching DHCPv6 to 
then complain if SLAAC-based hosts use more addresses than they would like.


Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

On 31/3/20 07:09, sth...@nethelp.no wrote:

When I read DHCPv6 vs SLAAC it often boils down to "control" but I
don't see the need to allocate a dynamic address if the autogenerated
are used. For client's you dont really have any inbound connections
unless it's a support case.

What's your view on this?


We only use DHCPv6 to assign IPv6 DNS addresses to devices.

Otherwise, we rely on SLAAC.

DHCPv6 took itself out of the running when it failed to provide the
default gateway to its clients.


Note that there have been multiple requests for DHCPv6 to do this but
every attempt has been shot down.


Yes. That has been very unfortunate.


--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Fernando Gont]

Hi, Brian,

On 31/3/20 00:29, Brian E Carpenter wrote:
It seems that the router must be setting both the A bit (use SLAAC) and the M bit (use DHCPv6). 


FWIW, my  Sagemcom router provided by my ISP does the same (set both A 
in PIOs, and M (and O :-) ) in the RA). UBuntu reacts as descirbed by 
the OP.




So the host is obeying both. There's no real harm in it, in most circumstances.


Not sure I would clasify it as "harm", but:
my ubuntu box does rfc7217+rfc4941. But since the M bit is set, it 
configures a DHCPv6-leased address... with a predictable IID. ( 
apparently the CPE has a poool that starts at ::1000, and leases 
addresses incrementally).


Certainly, that's not nice.

Besides, if folks are concerned about the number of addresses in use (as 
some did in recent 6man discussions), one would say this is a 
low-hanging fruit: an address that is configured, and will *never* be used.





Fixing the ambiguity about what hosts should do about this has often been 
discussed in the IETF but there's never really been evidence that it's worth 
doing.


FWIW, me, even if it was just for the sake "clarity", that would be 
worth doing.


Thanks!

Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Fernando Gont]

On 26/10/19 11:06, Bjørn Mork wrote:
> Fernando Gont  writes:
> 
>> They can't do stable addresses, and they are facing this problem.
> 
> This is a constructed problem.  The solution is to remove the
> construction.
> 
> I realize that the "can't do stable addresses" might be enforced by
> non-technical entities, but this would most likely not happen if it was
> a violation of a standards track RFC.
> 
> I'm sure you can fix that :-)

I'm sure the EFF would post a nice article about it.

-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Fernando Gont]

On 25/10/19 20:02, Brian E Carpenter wrote:
[]
> Progress will only come as more and more people stop putting IPv6 in the "too 
> hard" basket. I really do understand that for people running actual services 
> this is not a trivial thing, but it's a real chicken/egg situation, 
> unfortunately. But the signs are good at last.

We don't seem to be helping ourselves a lot.

FWIW, the slaac-renum I-D resulted from my conversation with the biggest
ISP in one country from the middle east, which was facing this problem.
They can't do stable addresses, and they are facing this problem.

Not sure how many more 100's of messages are needed before we get to do
something about it...


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: ULA [was: ipv6-ops Digest, Vol 159, Issue 1]

[Fernando Gont]

On 23/10/19 14:53, Brian E Carpenter wrote:
> On 24-Oct-19 03:57, David Forrest wrote:
>> My ULA is a /48 while Charter Spectrum only gives me a /64.  Then I lose my 
>> network info.
> 
> Huh? You will simply use a /64 within the ULA /48. However, you should only 
> generate the ULA prefix once and store it in stable storage; that should be a 
> feature of your CE. Then you never change the ULA prefix.

"MAY be a feature..." ;-) many (most?) will not even know about ULAs.  :-(

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: ipv6-ops Digest, Vol 159, Issue 1

[Fernando Gont]

Hello, Michael,

On 23/10/19 09:26, Michael Sturtz wrote:
> I have found more problems with the DHCPv6-PD.  The issue is on many home 
> networks where people are using server type hardware such as Windows(TM) 
> networks where DNS is used to locate and secure the network the renumbering 
> event creates major problems as the on premises DHCPv6 server has no way to 
> understand that a renumber event has occurred.  People are very used to the 
> IPv4 RFC 1918 static addressing where nothing on their local internal network 
> will change without notice.  The fact that ISPs can randomly change the 
> internal delegated address without notice is a major problem.  That will 
> confuse people and cause problems especially where a customer has equipment 
> such as Windows or Linux servers or other equipment that requires static 
> addressing or DHCPv6.   I understand that for certain operational reasons 
> ISPs need to renumber addresses however I suggest we discourage the practice. 
>  We also could modify the RFC to require a message to be sent by CPE to all 
> downstream network devices that a network renumber event is being scheduled.  
> This can be sent as a multicast message that encodes the date that the 
> renumbering will occur.  I realize that we need to understand the security 
> implications of this.  This is just one idea that could smooth the 
> renumbering events when then have to happen for some operational reason.  

As noted in the draft, the renumbered home network is one of many
possible scenarios where the renumbering event occurs. While we can
certainly recommend stable prefixes, I do think that the network should
be robust in the presence of such events.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: SLAAC renum: Problem Statement & Operational workarounds

[Fernando Gont]

Folks,

Your input would be very welcome. Preferably on the v6ops wg
mailing-list (https://www.ietf.org/mailman/listinfo/v6ops), but also on
this list or multicast to us (authors).

Thanks!


 Forwarded Message 
Subject: SLAAC renum: Problem Statement & Operational workarounds
Date: Wed, 23 Oct 2019 03:51:32 -0500
From: Fernando Gont 
To: IPv6 Operations 

Folks,

Earlier this year there was a lot of discussion about slaac renumbering
problems. Our original I-D covered everything from the problem statement
to proposed protocol updates and operational workarounds.

Based on the comments received while discussing this topic on this list
and other forums, and in order to keep the discussion better focused on
specific aspects of the problem, we have posted a v6ops-targetted
document that focuses on:

* The problem statement
* Discussion of operational workarounds, and associated constraints

The document is available at:
https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum

We'd like to hear from the wg whether we have missed anything, whether
the document is useful to the community, etc.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

SLAAC renumbering problems (Fwd: [v6ops] SLAAC renum/problems I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt))

[Fernando Gont]

FYI:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt


 Forwarded Message 
Subject: Re: [v6ops] SLAAC renum/problems I-D (Fwd: New Version
Notification for draft-gont-v6ops-slaac-renum-00.txt)
Date: Sat, 6 Jul 2019 12:10:34 -0700
From: Fred Baker 
To: IPv6 Operations 
CC: Fernando Gont , Jan Zorz ,
Richard Patterson 

As usual, Ron and I are looking for supportive public commentary if
people want it on the IETF 105 agenda, and if people would like to see
it adopted as a working group draft.

> On Jul 6, 2019, at 9:03 AM, Fernando Gont  wrote:
> 
> The document is available at:
> https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt
> 
> Comments are welcome.
> 
> And whenever the chairs deem appropriate, we'd like to know if v6ops
> would like to work/adopt this document.


The fact that there is a highway to hell and a stairway to heaven is an
interesting comment on projected traffic volume...

___
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

IPv6 Security for IPv4 Engineers

[Fernando Gont]

Folks,

It is often argued that IPv4 practices should be forgotten when
deploying IPv6, as after all IPv6 is a different protocol! But we think
years of IPv4 operational experience should be leveraged as much as
possible.

So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to
IPv6 security that is specifically aimed at IPv4 engineers and operators.

The document is available at:

https://www.internetsociety.org/resources/deploy360/ipv6/security/ipv4-engineers

Comments are welcome. If you think we have missed anything, please drop
me an email, since the document can eventually be revised.

P.S.: We also published "IPv6 Security Frequently Asked Questions (FAQ)"
at: https://www.internetsociety.org/deploy360/ipv6/security/faq/

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont]

Folks,

We have posted a new I-D discussing a problem that can arise in typical
deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and
advertises a prefix on the LAN side. We also propose a solution to the
aforementioned problem.

Our draft is available at:
https://tools.ietf.org/html/draft-gont-6man-slaac-renum


The Abstract is:
   A very common IPv6 deployment scenario is that in which a CPE employs
   DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
   prefix from within the leased prefix is advertised on a local network
   via SLAAC.  In scenarios where e.g. the CPE crashes and reboots,
   nodes on the local network continue using outdated prefixes which
   result in connectivity problems.  This document analyzes this problem
   scenario, and proposes workarounds.

Any comments will be welcome.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: UPnP/IPv6 support in home routers?

[Fernando Gont]

On Mon, Dec 11, 2017 at 6:18 PM, Pete Mundy  wrote:

>
> I'm not so worried about secure IoT devices. The insecure ones will get
> hacked, and the secure ones will do their job.
>
> I just want direct uninhibited and unmodified end to end connectivity
> across the IPv6 internet.
>


That train has left, already. -- Include RFC7872 there.

Fernando

Re: UPnP/IPv6 support in home routers?

[Fernando Gont]

Operationally, you can deploy a firewall, but have no say in the poor
software development practices of your IoT vendor.
Compartmentalization -- yes, within the compartment, the IoT devices can
kill each other. :-)  If the compartment granularity is not fine enough,
improve it.

P.S.: Yes, I'd like secure IoT devices. I would also like to erradicate
poverty and other things...

Fernando

On Mon, Dec 11, 2017 at 6:09 PM, Pete Mundy <p...@fiberphone.co.nz> wrote:

>
> But the FW doesn't (can't) protect the IoT device from other malicious IoT
> devices sharing the local network behind the firewall.
>
> Isn't it better to forego the boarder firewall completely and make
> implementing that service the responsibility of each host for itself?
>
> Pete
>
>
> > On 12/12/2017, at 10:00 AM, Fernando Gont <ferna...@gont.com.ar> wrote:
> >
> > The crap doesn't get fixed because that's the software development we
> are used to. Windows 10 was Windows '95 in the '90s. So give the IoT stuff
> 15-20 years to get to a sensible quality/state/security and/or enough
> widespread trouble/exploitation.
> >
> > Pragmatically speaking, people will connect that crap to the 'net... and
> the "less connected" such devices are, the better.
> > So, please, don't remove FWs. :-)
> >
> > Cheers,
> > Fernando
>
>


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: UPnP/IPv6 support in home routers?

[Fernando Gont]

Kristian,

I see no reason for which they should disappear. Actually, quite the
opposite; we keep connecting more and more crap to the net (the so called
IoT), which clearly cannot defend itself.

The "principle of least privilege" applies to connectivity, too.

Thanks!
Fernando






On Mon, Dec 11, 2017 at 12:28 PM, Kristian McColm <
kristian.mcc...@rci.rogers.com> wrote:

> Corporate and/or specific network requirements notwithstanding, in my
> opinion this is just another example of why in IPv6, firewalls in general
> could/should be retired. If the end user device is required to be
> responsible for it’s own security, it can open the necessary ports via
> whatever firewall API it provides to applications running on it.
>
>
> --
> *From:* ipv6-ops-bounces+kristian.mccolm=rci.rogers@lists.cluenet.de
> <ipv6-ops-bounces+kristian.mccolm=rci.rogers@lists.cluenet.de> on
> behalf of Doug McIntyre <mer...@geeks.org>
> *Sent:* Monday, December 11, 2017 10:22:39 AM
> *To:* ipv6-ops@lists.cluenet.de
> *Subject:* Re: UPnP/IPv6 support in home routers?
>
> On Mon, Dec 11, 2017 at 04:03:27PM +0100, Gert Doering wrote:
> > On Mon, Dec 11, 2017 at 11:54:15AM +, Tom Hill wrote:
> > > "Dear Gateway, I am definitely not a compromised host, please open all
> > > ports toward me."
> >
> > But that's the whole idea of UPnP or IGD.  Whether you open one port or
> > all of them, on request of a possibly-compromised host, is of no
> relevance.
>
>
> I think the thinking is that since most IPv4 "home" protocols (which
> is really only where UPnP exists, since Enterprise class firewalls
> almost never want to have anything to do with it), is that most of the
> "home" protocols (eg. games, streaming, etc) have mostly converged to
> a model not expecting end-to-end connectivity, and hidden behind a NAT
> thing, that anything now transitioning to IPv6 will follow suit when
> they add that support to whatever needs to punch holes in things,
> instead checking in constantly with the "central server" instead of
> assuming end-to-end connectivity.
>
> That said, I think the IPv6 firewalls need better home connectivity
> support as well. I once put in a ticket to Fortinet to ask if there
> could be made an ACL object that tracked the prefix mask delivered via
> DHCP6_PD, such that we could write policies such as
>   allow remote_ipv6_address ${PREFIX1}::1f5d:50 22
>
> But that couldn't be impressed on the first tiers of support
> what-so-ever.  That totally confused them to no end. Unlike my IPv4
> address which almost never changes at Comcast, the IPv6 prefixes I get
> change on every connection.
>
>
>
>
>
> --
> This communication is confidential. We only send and receive email on the
> basis of the terms set out at www.rogers.com/web/content/emailnotice
>
>
>
> Ce message est confidentiel. Notre transmission et réception de courriels
> se fait strictement suivant les modalités énoncées dans l’avis publié à 
> www.rogers.com/aviscourriel
>
> --
>



-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: UPnP/IPv6 support in home routers?

[Fernando Gont]

On 12/11/2017 08:54 AM, Tom Hill wrote:
> On 11/12/17 05:21, Fernando Gont wrote:
>> one would want to be able to whitelist all ports
>> for a given IP address
> 
> What? No!
> 
> "Dear Gateway, I am definitely not a compromised host, please open all
> ports toward me."
> 
> I don't disregard the idea that one would want to manually configure
> this behaviour, but not automatically from the host itself.

No, certainly not automatically. But would like to be able to.

e.g., want to be able to put a node in a "DMZ", allowing even e.g.
things tunneled on top of IPv6.

If UPnP needs t be aware about transport ports, then anything not TCP or
UDP (you might also say SCTP and such, but I think they are not
supported, anyway) would be ruled out.


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

UPnP/IPv6 support in home routers?

[Fernando Gont]

Folks,

Anyone can comment on the UPnP support for IPv6 in home routers?

Those that I have checked have UPnP support for IPv4, but not for IPv6
-- even when the home router does support IPv6.

Looking at UPnP itself, it seems to allow opening holes at the IGD, but
on a fully-specified (local ip, local port, remote ip, remote port),
which kind of sucks -- one would want to be able to whitelist all ports
for a given IP address, or at least (local ip, local port)

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: Rev'ed IETF I-Ds on Security/Privacy of IPv6 addresses

[Fernando Gont]

On 03/15/2017 05:27 AM, Bjørn Mork wrote:
> Fernando Gont <fg...@si6networks.com> writes:
> 
>> * "IPv6 Address Usage Recommendations" <https://goo.gl/UJYdyY>
>> * "Recommendation on Temporary IPv6 Interface Identifiers"
>> <https://goo.gl/541H8V>
> 
> Following arbitrary URLs from an email is considered unwise.  There is
> nothing in those URLs telling me that they are redirected to a site I
> consider safe.

In a sense, I sympathize with your view. These are the expanded URLs:

* "IPv6 Address Usage Recommendations"
<https://trac.tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-02>

* "Recommendation on Temporary IPv6 Interface Identifiers"
<https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-01>

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Rev'ed IETF I-Ds on Security/Privacy of IPv6 addresses

[Fernando Gont]

Folks,

FYI:

* "IPv6 Address Usage Recommendations" <https://goo.gl/UJYdyY>
* "Recommendation on Temporary IPv6 Interface Identifiers"
<https://goo.gl/541H8V>

Comments welcome!

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: macos Sierra with CGA address?

[Fernando Gont]

On 12/14/2016 05:07 PM, Bjoern A. Zeeb wrote:
> On 14 Dec 2016, at 11:45, Holger Zuleger wrote:
> 
>>> support. I don’t think any other common OS implements SeND, does it?
>> Not that I'm aware of, so I was on the way to bury the idea of secure
>> neighbor discovery.
>>
>> It seems that some implementation for Linux exist, and also an Windows
>> Application (see page 23 on
>> http://www.rmv6tf.org/wp-content/uploads/2012/11/IPv6_SeND_PPT1.pdf)
> 
> FreeBSD has been shipping with the SeND implementation bits in the
> kernel for years (since 2010?) now.  Ana Kukec did that.  And there’s a
> port for user space bits.
> 
> The WinSeND work read a lot like Ana’s paper back then but I have no
> idea about the code.
> 
> I am happy that half a decade later support for SeND does spread across
> the OSes.

Hopefully all this SeND machinery is not being pushed in as a
heavyweight RFC7217. You don't need all the certs-related stuff for
getting a non-predictable stable-per-network IID.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: macos Sierra with CGA address?

[Fernando Gont]

On 12/14/2016 08:40 AM, Jeroen Massar wrote:
> On 2016-12-14 12:25, Holger Zuleger wrote:
>> Hi Jeroen,
>>
>>>> I found two or three posts in the internet, all mentioning (or hoping)
>>>> that this is related to a change to RFC7217 as default IID mechanism.
>>>>
>>>> But one guy sad, that the source code (of 10.11) shows, that this is a
>>>> cryptographic generated interface identifier for SeND (RFC3971).
>>>>
>>>> I tend to believe that the latter is true.
>>>
>>> Seeing how Apple implemented things like "Happy Eyeballs" it likely is
>>> neither. And in the case of "Happy Eyeballs" there is no way to turn it
>>> off either. Filing radar bugs clearly does not help as they never get
>>> addressed or marked as 'dupe' at which point you do not know the status
>>> of the 'original' problem and well, nothing happens...
>>
>>
>>>> Has anyone more information about this? Especially how to configure it?
>>>
>>> The only trick I found out was:
>>>
>>> https://twitter.com/tweetsix/status/77861562571649
>>> 8<---
>>> Also who has typed: "sudo sysctl -w net.inet6.ip6.maxifprefixes=1" (or
>>> stored the setting in /etc/sysctl.conf) recently? ;)
>>> ->8
>> To be honest, that's definitively is not the way I like to go.
>>
>>> As then you only get the DHCPd address (requires DHCPv6 server) on
>>> your interface and not all the other magic ones that change all the time
>>> and are extremely useless if you want to ADDRESS a host...
>>> (yes, I love VNC'ing, SSH'ing and doing SSH-backups of my boxes...)
>> Oh no, DHCPv6 is not needed here.
> 
> Until Sierra, I didn't have any DHCPv6 either... but now I do because I
> really love my static and known addresses. People know I have a Mac
> anyway, thus what info am I losing there?
> 
>> The problem is *not* that this IID is changing. It is a stable one. And
>> yes, I vote not against temporary addresses.
> 
> Actually, it is not a stable address as some have found out (read:
> anecdotal), they also change at re-install and there are a couple of
> other possibilities from what I recall.

One might argue that a reinstall results in a conceptualy different
system. The fact that the underlying hardware is tha same is anecdotical.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: macos Sierra with CGA address?

[Fernando Gont]

On 12/14/2016 08:31 AM, Tim Chown wrote:
> Hi,
> 
>> On 14 Dec 2016, at 11:08, Jeroen Massar <jer...@massar.ch> wrote:
>>
>> On 2016-12-14 11:55, Holger Zuleger wrote:
>>> Hi,
>>>
>>> I just realized that the permanent interface identifier of my MAC has
>>> changed after upgrading to OS 10.12 (I guess).
>>>
>>> The output of ifconfig shows a new "secured" flag at the permanent address.
>>> $ ifconfig en0 | grep inet6 | \
>>>>  sed "s/2[^:]*:[^:]*:[^:]*:[^:]*:/:/"
>>> inet6 fe80::c54:6333:ac12:c67b%en0 prefixlen 64 secured scopeid 0x4
>>> inet6 :20e3:84f6:6794:5ace prefixlen 64 autoconf secured
>>> inet6 :8822:a8a3:b6ec:a79b prefixlen 64 autoconf temporary
>>>
>>> I found two or three posts in the internet, all mentioning (or hoping)
>>> that this is related to a change to RFC7217 as default IID mechanism.
>>>
>>> But one guy sad, that the source code (of 10.11) shows, that this is a
>>> cryptographic generated interface identifier for SeND (RFC3971).
>>>
>>> I tend to believe that the latter is true.
>>
>> Seeing how Apple implemented things like "Happy Eyeballs" it likely is
>> neither. And in the case of "Happy Eyeballs" there is no way to turn it
>> off either. Filing radar bugs clearly does not help as they never get
>> addressed or marked as 'dupe' at which point you do not know the status
>> of the 'original' problem and well, nothing happens...
> 
> Interesting - I’d also assumed the new form of address was RFC 7217 support. 
> I don’t think any other common OS implements SeND, does it?

Can anyone verify that:

1) As you disconnect and subsequently reconnect to the same network, the
address is formed with the same IID?

2) When multiple prefixes ad advertised on the same network, each
resulting address (for each different prefix) employs a different IID?

3) If multiple interfaces (NICs) are connected to the same subnet, each
obtains a different address, plus "1)" and "2)" above are true?

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: macos Sierra with CGA address?

[Fernando Gont]

On 12/14/2016 08:25 AM, Holger Zuleger wrote:
>>> Has anyone more information about this? Especially how to configure it?
>>
>> The only trick I found out was:
>>
>> https://twitter.com/tweetsix/status/77861562571649
>> 8<---
>> Also who has typed: "sudo sysctl -w net.inet6.ip6.maxifprefixes=1" (or
>> stored the setting in /etc/sysctl.conf) recently? ;)
>> ->8
> To be honest, that's definitively is not the way I like to go.
> 
>> As then you only get the DHCPd address (requires DHCPv6 server) on
>> your interface and not all the other magic ones that change all the time
>> and are extremely useless if you want to ADDRESS a host...
>> (yes, I love VNC'ing, SSH'ing and doing SSH-backups of my boxes...)
> Oh no, DHCPv6 is not needed here.
> 
> The problem is *not* that this IID is changing. It is a stable one. And
> yes, I vote not against temporary addresses.
> 
>> There are claimed 'good' properties of a changing address but mostly
>> they are useless: "it works against tracking" which is useless if your
>> /48 is static and there are only ~10 hosts in that prefix that call
>> outbound. Also, something with HTTP Cookies for 99% of the other things.
>> And I am really not lugging my 27" iMac around to get it in another
>> network
>>
>> Hence, a switch to turn if off would be amazing.
>> The above trick kinda does that though and it mostly seem to work.
> My info is, to set
>   sysctl -w net.inet6.send.opstate=0
> to go back to mac address based eui64, but didn't checked it.

Please don't resort to eui64. That's a bad idea. See RFC7721 and RFC707

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: macos Sierra with CGA address?

[Fernando Gont]

On 12/14/2016 08:08 AM, Jeroen Massar wrote:
> On 2016-12-14 11:55, Holger Zuleger wrote:
>> Hi,
[]
> 
> As then you only get the DHCPd address (requires DHCPv6 server) on
> your interface and not all the other magic ones that change all the time
> and are extremely useless if you want to ADDRESS a host...
> (yes, I love VNC'ing, SSH'ing and doing SSH-backups of my boxes...)
> 
> 
> There are claimed 'good' properties of a changing address but mostly
> they are useless: "it works against tracking" which is useless if your
> /48 is static and there are only ~10 hosts in that prefix that call
> outbound. Also, something with HTTP Cookies for 99% of the other things.
> And I am really not lugging my 27" iMac around to get it in another
> network

If it actualy is RFC7217, then they d not change within the same network
-- for instance, RFC7217 was/is known in 6man circles as "stable-privacy
addresses").

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World

[Fernando Gont]

FYI


 Forwarded Message 
Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets
with IPv6 Extension Headers in the Real World
Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: v6...@ietf.org, rfc-edi...@rfc-editor.org

A new Request for Comments is now available in online RFC libraries.


RFC 7872

Title:  Observations on the Dropping of
Packets with IPv6 Extension Headers in
the Real World
Author: F. Gont, J. Linkova,
T. Chown, W. Liu
Status: Informational
Stream: IETF
Date:   June 2016
Mailbox:fg...@si6networks.com,
fu...@google.com,
tim.ch...@jisc.ac.uk,
liushuch...@huawei.com
Pages:  15
Characters: 30924
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt

URL:https://www.rfc-editor.org/info/rfc7872

DOI:http://dx.doi.org/10.17487/RFC7872

This document presents real-world data regarding the extent to which
packets with IPv6 Extension Headers (EHs) are dropped in the Internet
(as originally measured in August 2014 and later in June 2015, with
similar results) and where in the network such dropping occurs.  The
aforementioned results serve as a problem statement that is expected
to trigger operational advice on the filtering of IPv6 packets
carrying IPv6 EHs so that the situation improves over time.  This
document also explains how the results were obtained, such that the
corresponding measurements can be reproduced by other members of the
community and repeated over time to observe changes in the handling
of packets with IPv6 EHs.

This document is a product of the IPv6 Operations Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

IETF I-D: "Operational Implications of IPv6 Packets with Extension Headers"

[Fernando Gont]

Folks,

We have revised our IETF I-D "Operational Implications of IPv6 Packets
with Extension Headers".

The I-D is available at:
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01>

Your feedback will be appreciated.

If possible, please send your comments to:
<draft-gont-v6ops-ipv6-ehs-packet-dr...@tools.ietf.org> and CC
<v6...@ietf.org>.

P.S.: You can find a number of pointers to articles and other related
work on this topic here:
<http://blog.si6networks.com/2015/12/the-controversial-ipv6-extension-headers.html>

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: [v6ops] Why operators filter IPv6 packets with extension headers?

[Fernando Gont]

 have argued against that (fwiw, I'm just the
messenger :-) )


> May I STRONGLY suggest to remove all security issues (other docs are
> describing this) and focus only on the operational issues (esp in V6OPS) ?
> And skip any discussion on the rationale why packets with EH are dropped?

Let's hear from other folks what they think. I think that without at
least some "roadmap"/brief discussion, folks might need to dig deep into
many documents in order to grasp "what this is ll about".

FWIW, 8just me thinking out loud), I guess that one of the possible
outcomes could be to have (some reduced version of) Section 3 be a
subsection of Section 4?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Why operators filter IPv6 packets with extension headers?

[Fernando Gont]

Folks,

The topic of operators dropping IPv6 packets containing extension
headers has been raised quite a few times on a number of mailing-lists
and forums.

A month ago or so we published a document trying to summarize the
reasons for which operators filter IPv6 packets containing extension
headers. The document is available at:
<https://tools.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt>

We're currently working on a revision of this document, and would like
to hear feedback from the ops community regarding our document. e.g.,

* Did we get anything wrong?
* Is there anything missing?

Or, if you like the document and agree with its content, that's also
interesting feedback to have.

P.S.: If possible, please CC <v6...@ietf.org> and
<draft-gont-v6ops-ipv6-ehs-packet-dr...@tools.ietf.org> when sending
feedback.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: IPv6 hackers #2 (Prague 2015) tomorrow! (July 21, 4 PM @ CZ.NIC)

[Fernando Gont]

FYI -- could be of Interest for folks currently in Prague for the IETF
meeting...


 Forwarded Message 
Subject: IPv6 hackers #2 (Prague 2015) tomorrow! (July 21, 4 PM @ CZ.NIC)
Date: Mon, 20 Jul 2015 18:24:04 -0300
From: Fernando Gont ferna...@gont.com.ar
To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com

Folks,

Tomorrow (July 21, 2015 @ 4 PM) we will be having the second IPv6
Hackers meeting (IPv6 Hackers #2, Prague 2015), at CZ.NIC.

All the relevant information is available at:
http://www.ipv6hackers.org. Attendance is free and open.

We can still accommodate one or two additional presentations. If you
have something to share (something involving IPv6 testing or hacking),
please contact me (off-list, asap) at ferna...@gont.com.ar.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

IPv6 Extension Headers in the Real World

[Fernando Gont]

Folks,

Earlier in September we published a revision of our I-D IPv6 Extension
Headers in the Real World
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world).

At this point in time, we're interested in knowing whether our I-D is of
value for the IPv6 ops community, such that we can decide whether to
continue working/improving it. Additionally, if there's anything you
think we've missed in the document, we'd like to hear from you.

Overall, our I-D is meant to provide a reality-check with respect to the
issues surrounding IPv6 Extension Headers and their use on the public
Internet. More specifically, its goals are:

1) Provide data regarding support of IPv6 EHs in the real world.

This is interesting data to refer people to (e.g., folks
developing protocols) regarding the extent to which IPv6 EHs
are usable on the public Internet (at least with web, mail, and
name servers).


2) Summarize the issues associated with IPv6 EHs (performance, security,
etc.)

This is of use for folks concerned with the issues surrounding
IPv6 EHs, and covers practical issues.


3) Summarizes the implications of the aforementioned filtering.

For example, if you're designing a protocol that is meant to
work on the public Internet, you may want to provide some fall-back
mechanism that does not employ IPv6 EHs.

Yet another of the implications is the security issue that has
been discussed on-list: if e.g. IPv6 fragments are dropped and you
can be tricked into generating them, you may be subject to a DoS
attack.


4) Flag possible further work

   Here we try to flag areas where the further work may be needed,
   such as adding fall-back mechanisms to some existing protocols,
   or avoiding the use of IPv6 EHs where possible.


Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: IPv6 packets with HBH

[Fernando Gont]

Hi, Yannis,

On 07/04/2014 12:05 PM, Yannis Nikolopoulos wrote:
 
 how do people handle packets with HBH present? Since their use is a
 potential attack vector, do people rate-limit them? I can't seem to find
 some sort of best practice on the issue

This is the current state of affairs on the public IPv6 Internet:
http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Tracing IPv6 packet drops resulting from Extension Headers (e.g. to Google)

[Fernando Gont]

Folks,

I've been playing quite a bit with code and testing.

One tool that I've produced is blackhole6, which essentially works as
follows:

1) It runs traceroute6 with no EHs (path6, actually), and records the
path to the destination (PATH)
2) It runs traceroute6 with EHs (path6, actually), and find the last
responding node (M)
3) Looks-up M in PATH. The dropping node is M+1.

Additionally, it finds relevant AS info for each of the systems above.

If you want to try it, just:
$ git clone https://github.com/fgont/ipv6toolkit.git
$ cd ipv6toolkit
# make install clean

And then run the tool as:

# blackhole6 IPV6_ADDRESS


If you run the tool against an  corresponding to www.google.com, you
get:

fgont@satellite:~/code/ipv6toolkit/tools$ sudo blackhole6
2800:3f0:4002:801::1011

SI6 Networks IPv6 Toolkit v2.0
blackhole6: A tool to find IPv6 blackholes

Destination IPv6 address: 2800:3f0:4002:801::1011 (AS15169 - GOOGLE -
Google Inc.,US)
Last resp. node (no EHs): 2800:3f0:4002:801::1011 (AS15169 - GOOGLE -
Google Inc.,US) (12 hop(s))
Last resp. node (DO 8): 2001:1291:0:4b::b (AS16735 -COMPANHIA DE
TELECOMUNICACOES DO BRASIL CENTRAL,BR) (7 hop(s))
Dropping node: 2001:1291:0:63::2 (AS16735 - COMPANHIA DE
TELECOMUNICACOES DO BRASIL CENTRAL,BR)


I guess the question is why the dropping node seems to be M+2 rather
than M+1 (based on public information, I was expecting Google to be the
folks dropping the EH-enabled IPv6 packets rather
than the Brazilian company above)?.

If you do a normal traceroute (path6 tool of the toolkit), the route is:

fgont@satellite:~/code/ipv6toolkit/tools$ sudo path6 -d
2800:3f0:4002:801::1011
  1 (2001:1291:2e6:1::1)   0.4 ms   0.2 ms   0.3 ms
  2 (2001:1291:200:42e::1)  278.4 ms  236.3 ms  239.0 ms
  3 (2001:1291:2::b)  239.3 ms  240.5 ms  239.3 ms
  4 (2001:1291:2::a)  239.6 ms  240.5 ms  243.1 ms
  5 (2001:1291:0:2::b)  239.5 ms  240.8 ms  239.5 ms
  6 (2001:1291:0:d7::a)  246.6 ms  240.1 ms  240.9 ms
  7 (2001:1291:0:4b::b)  244.3 ms  240.1 ms  240.3 ms
  8 (2001:1291:0:63::2)  255.5 ms  254.0 ms  255.1 ms
  9 (2001:4860::1:0:4f24)  257.8 ms  257.6 ms  261.4 ms
 10 (2001:4860::1:0:e)  281.6 ms  280.5 ms  283.2 ms
 11 (2001:4860:0:1::d8)  282.9 ms  285.3 ms  285.9 ms
 12 (2800:3f0:4002:801::1011)  284.2 ms  282.5 ms  285.7 ms


And with a DOH of 8 bytes, it is:

fgont@satellite:~/code/ipv6toolkit/tools$ sudo path6 -d
2800:3f0:4002:801::1011 -u 8
  1 (2001:1291:2e6:1::1)   1.0 ms   0.4 ms   0.4 ms
  2 (2001:1291:200:42e::1)  319.0 ms  245.6 ms  248.8 ms
  3 (2001:1291:2::b)  249.0 ms  237.1 ms  239.9 ms
  4 (2001:1291:2::a)  320.7 ms  320.1 ms  316.7 ms
  5 (2001:1291:0:2::b)  243.9 ms  243.4 ms  243.6 ms
  6 (2001:1291:0:d7::a)  240.0 ms  246.3 ms  247.7 ms
  7 (2001:1291:0:4b::b)  249.8 ms  241.6 ms  238.8 ms
  8 ()   *  *  *
  9 ()   *  *  *
 10 ()   *  *  *
 11 ()   *  *  *


Clearly, M+1 (2001:1291:0:63::2) is still the Brazilian carrier, while
M+2 (2001:4860::1:0:4f24) is Google, the folks I was expecting to be
dropping the packets.

Obviously, I don't care about this specific case... but probably is one
on which we might have more insights than others.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Requirements for IPv6 firewalls (new IETF-ID)

[Fernando Gont]

Folks,

We have published a new I-D on Requirements for IPv6 Firewalls

The I-D is available at:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00

The goals of this first (and drafty) version of the document are as follows:

1) Agree on a rationale to write this spec.

For example, one possible rationale is aim at providing parity of
features with IPv4. Another one could be that should should aim a
little higher. For example, in the light of
draft-farrell-perpass-attack we may aim at requiring some confidentiality
features that might not be that common in IPv4 firewalls.


2) Expose different aspects of firewalls that we may want to standardize.

High-level feedback along the lines of this other aspect is missing,
and should be added or we probably should not address this or that
other aspect are very valuable.


3) Discussion of concrete requirements.

Here the feedback would be in the form of This or that requirement is
missing, this or that requirement doesn't make sense and should be
eliminated, etc. And for each of those that we keep in, arguments in
favor of mandatory, recommended, or optional (i.e., what the level
of each requirement should be).


It would be great if you could post any feedback on the opsec wg
mailing-list (Instructions here:
https://www.ietf.org/mailman/listinfo/opsec). But in any case feel free to
discuss this document on this list (ipv6-ops) while CC'ing
draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org.

P.S.: Regardless of what we end up doing with this I-D, etc., I think
the brainstorming would be fruitful. :-)

Thanks!

Best regards,
Fernando




 Original Message 
From: internet-dra...@ietf.org
To: Will Liu liushuch...@huawei.com, Shucheng LIU (Will)
liushuch...@huawei.com, Fernando Gont fg...@si6networks.com,
Fernando Gont fg...@si6networks.com, Marco Ermini
marco.erm...@resmed.com, Marco Ermini marco.erm...@resmed.com
Subject: New Version Notification for
draft-gont-opsec-ipv6-firewall-reqs-00.txt
Date: Fri, 14 Feb 2014 16:00:33 -0800


A new version of I-D, draft-gont-opsec-ipv6-firewall-reqs-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:   draft-gont-opsec-ipv6-firewall-reqs
Revision:   00
Title:  Requirements for IPv6 Firewalls
Document date:  2014-02-15
Group:  Individual Submission
Pages:  12
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00


Abstract:
   While there are a large number of documents discussing IP and IPv6
   packet filtering, requirements for IPv6 firewalls have never been
   specified in the RFC series.  When it comes to IPv6, the more limited
   experience with the protocols, and reduced variety of products has
   made it rather difficult to specify what are reasonable features to
   be expected from an IPv6 firewall.  This has typically been a problem
   for network operators, who typically have to produce a Request for
   Proposal (from scratch) that describes such features.  This document
   specifies a set of requirements for IPv6 firewalls, marked as
   mandatory, recommended, or optional.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 10:59 AM, Aurélien wrote:
 
 I personnally verified that this type of attack works with at least one
 major firewall vendor, provided you know/guess reasonably well the
 network behind it. (I'm not implying that this is a widespread attack type).
 
 I also found this paper: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf
 
 I'm looking for other information sources, do you know other papers
 dealing with this problem ? Why do you think this is FUD ?

The attack does work. But the reason it works is because the
implementations are sloppy in this respect: they don't enforce limits on
the size of the data structures they manage.

The IPv4 subnet size enforces an artificial limit on things such as the
ARP cache. A /64 removes such artificial limit. However, you shouldn't
be relying on such limit. You should a real one in the implementation
itself.

And it's not just the NC. There are implementations that do not limit
the number of addresses they configure, that do not limit the number of
entries in the routing table, etc.

If you want to play, please take a look at the ipv6toolkit:
http://www.si6networks.com/tools/ipv6toolkit. On the same page, you'll
also find a PDF that discusses ND attacks, and that tells you how to
reproduce the attack with the toolkit.

Besides, each manual page of the toolkit (ra6(1), na6(1), etc.) has an
EXAMPLES section that provides popular ways to run each tool.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Neighbor Cache Exhaustion, was Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 11:16 AM, Enno Rey wrote:
 Hi Guillaume,
 
 willing to share your lab setup / results? We did some testing
 ourselves in a Cisco-only setting and couldn't cause any problems.
 [for details see here:
 http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/]

  After that I asked for other practical experience on the
 ipv6-hackers mailing list, but got no responses besides some I heard
 this is a problem in $SOME_SETTING and references to Jeff Wheeler's
 paper (which works on the - wrong - assumption that an incomplete
 entry can stay in the cache for a long time, which is not true for
 stacks implementing ND in conformance with RFC 4861). So your
 statement is actually the first first-hand proof of NCE being a
 real-world problem I ever hear of. thanks in advance for any
 additional detail.

Are we talking about Ciscos, specifically?

I recall reproducing this sort of thing on BSDs, Linux, and Windows.

Note: In some cases, the problem is that even when the entries in the
INCOMPLETE state are timeout, if the rate is lower than the rate at
which you produce them, it's still a problem.

Too bad -- we do have plenty of experience with this.. e.g., managing
the IP reassembly queue.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 12:26 PM, Alexandru Petrescu wrote:

 And it's not just the NC. There are implementations that do not limit
 the number of addresses they configure, that do not limit the number of
 entries in the routing table, etc.
 
 There are some different needs with this limitation.
 
 It's good to rate-limit a protocol exchange (to avoid dDoS), it's good
 to limit the size of the buffers (to avoid buffer overflows), but it may
 be arguable whether to limit the dynamic sizes of the instantiated data
 structures, especially when facing requirements of scalability - they'd
 rather be virtually infinite, like in virtual memory.

This means that the underlying hard limit will hit you in the back.

You should enforce limits that at the very least keeps the system usable.

At the end of the day, at the very least you want to be able to ssh to it.



 This is not a problem of implementation, it is a problem of unspoken
 assumption that the subnet prefix is always 64.

Do you know what they say assumptions? -- It's the mother of all f* ups.

It's as straightforward as this: whenever you're coding something,
enforce limits. And set it to a sane default. And allow the admin to
override it when necessary.


 It is unspoken because
 it is little required (almost none) by RFCs.  Similarly as when the
 router of the link is always the .1.

That's about sloppy programming.

Train yourself to do the right thing. I do. When I code, I always
enforce limits. If anything, just pick one, and then tune it.



 Speaking of scalability - is there any link layer (e.g. Ethernet) that
 supports 2^64 nodes in the same link?  Any deployed such link? I doubt so.

Scan Google's IPv6 address space, and you'll find one. (scan6 of
http://www.si6networks.com/tools/ipv6toolkit is your friend :-) )

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

SI6 Networks' IPv6 Toolkit v1.5.2 released!

[Fernando Gont]

 for 64-bit encoding of IPv4 addresses
 Option --tgt-ipv4 was augmented to support both encodings (32 bit
 and 64 bit) of embedded IPv4 addresses.

   * tcp6: Fixed response to Neighbor Solicitations
 tcp6 was not responding to incoming Neighbor Solicitations. Hence,
 when packets were sent from spoofed addresses, tcp6 would never
 receive the response packets, because the NSs sent by the local
 router or target node would never be responded.

   * tcp6: Added support for TCP Window-based attacks
 tcp6 can now close the window after sending an app-layer command,
 and also modulate the TCP window to circumvent trivial
 mitigations for these attacks (--window-mode and
 --win-modulate options).

   * tcp6: Support for multiple connection-establishment types
 tcp6 can now cause e.g. TCP simultaneous opens (see the
 --open-mode option).

   * tcp6: Support for multiple connection-termination types
 tcp6 can now perform multiple connection-termination types (see the
 --close-mode option).

   * tcp6: Support for sending application layer requests
 tcp6 can now send application-layer requests with the --data
 option.

   * Many improvements to the manual pages.
 Fixed the troff encoding of many manual pages. Added
 ipv6toolkit(7), that describes a general description of the
 toolkit.

   * All: Fixed bug in link-layer destination address selection
 Tools now try to find a local router or perform Neighbor Discovery
 only when necessary (i.e., underlying link-layer is *not* loopback
 or tunnel, destination address is *not* link-local, and a
 link-layer destination address has *not* been specified).

   * All: Fixed bug in option handling
 Incorrect data type was used for the return value of
 getopt_long(), thus leading to problems in some architectures.

   * All: Fixed a number of issues with pcap_next_ex()
 The timeout parameter of pcap_next_ex() is now based on the
 platform (the previous constant value had different semantics in
 different platforms).
 Additionally, handle the case where pcap_next_ex() returns no
 packets.

   * All: General improvements and clean-up
 The development process now includes building the toolkit with the
 clang compiler (in addition to gcc), which has lead to the
 identification of a number of issues.

   * All: Improved support for building the toolkit.
 The toolkit now contains one makefile for pmake, and another for
 GNU make.
 Added support for the DESTDIR variable. Appropriate paths are
 selected based on the value of a number of variables.
 Configuration file is dynamically generated, with the right path
 to the oui.txt file.

= CHANGELOG =


- -- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





- -- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJS68k7AAoJEJbuqe/Qdv/xV5sH/AgK9shzZsWwnIZ4SEDurjGw
V7BodKadf5YjUGSmaMckD4j2LweXQp5BlBYSII2in70XTMC5AZr6QeWFqkPjbWZN
SpTAxDpZ+St0tPr3TMoBXK8udfKNjqZD8Puobs7DkrxJRYJhuZyJRVDTKgeS5E07
OeOglNiFBJHWPAvppw0Hj5z+oyavhiU5tzOTMRjkJzSh4n2v50g5xwJYi6QePy/Q
0anfNSlAcIpiGY+Fmwu0iYqqpw0O6PjVJwFiOaiAojgo7Mfq4p5b/PXjP4kWCp+d
E1oYcUoO1U/XN6ATfunlCLhWwGTBERmASZ/TSQm+7GHlytpwKs189FLE3s9YF4s=
=7NSQ
-END PGP SIGNATURE-

SI6 Networks' IPv6 Toolkit v1.5.2 released!

[Fernando Gont]

 for 64-bit encoding of IPv4 addresses
 Option --tgt-ipv4 was augmented to support both encodings (32 bit
 and 64 bit) of embedded IPv4 addresses.

   * tcp6: Fixed response to Neighbor Solicitations
 tcp6 was not responding to incoming Neighbor Solicitations. Hence,
 when packets were sent from spoofed addresses, tcp6 would never
 receive the response packets, because the NSs sent by the local
 router or target node would never be responded.

   * tcp6: Added support for TCP Window-based attacks
 tcp6 can now close the window after sending an app-layer command,
 and also modulate the TCP window to circumvent trivial
 mitigations for these attacks (--window-mode and
 --win-modulate options).

   * tcp6: Support for multiple connection-establishment types
 tcp6 can now cause e.g. TCP simultaneous opens (see the
 --open-mode option).

   * tcp6: Support for multiple connection-termination types
 tcp6 can now perform multiple connection-termination types (see the
 --close-mode option).

   * tcp6: Support for sending application layer requests
 tcp6 can now send application-layer requests with the --data
 option.

   * Many improvements to the manual pages.
 Fixed the troff encoding of many manual pages. Added
 ipv6toolkit(7), that describes a general description of the
 toolkit.

   * All: Fixed bug in link-layer destination address selection
 Tools now try to find a local router or perform Neighbor Discovery
 only when necessary (i.e., underlying link-layer is *not* loopback
 or tunnel, destination address is *not* link-local, and a
 link-layer destination address has *not* been specified).

   * All: Fixed bug in option handling
 Incorrect data type was used for the return value of
 getopt_long(), thus leading to problems in some architectures.

   * All: Fixed a number of issues with pcap_next_ex()
 The timeout parameter of pcap_next_ex() is now based on the
 platform (the previous constant value had different semantics in
 different platforms).
 Additionally, handle the case where pcap_next_ex() returns no
 packets.

   * All: General improvements and clean-up
 The development process now includes building the toolkit with the
 clang compiler (in addition to gcc), which has lead to the
 identification of a number of issues.

   * All: Improved support for building the toolkit.
 The toolkit now contains one makefile for pmake, and another for
 GNU make.
 Added support for the DESTDIR variable. Appropriate paths are
 selected based on the value of a number of variables.
 Configuration file is dynamically generated, with the right path
 to the oui.txt file.

= CHANGELOG =


- -- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





- -- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJS68k6AAoJEJbuqe/Qdv/xWWkIANS/GouhoQxvAgrB8Ryireon
8jsYkboNqA0bZtqt6oQASgllBUxtWC7OGmpgZk/s4n8SIDLA8JtlvlPxnIJ5QJlT
dSunWgiQCgdLkgcJDhgBlSBtNnIH0DC/sCc+nRneCbxtM6PMGxCzD+makSe/3MBI
pTzmNOg5oUy86zlYbpqTcoUOuFblAtx1rvmtIc3sTs9CELMJ8F2K400j1XxnmqwK
gifmhPtbM8BNZat4/b3Jzn5rj4if8bUNiBZnKvQFZLuCi/LFdm171uM/HGeBBFNl
/cmcm9mq+M4CKecRZXp5QIjMQIq3iUR0mOxSO1qm75TLcm886PQORddtcDvOjwQ=
=epiF
-END PGP SIGNATURE-

Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 01:12 PM, Alexandru Petrescu wrote:
 
 This is not a problem of implementation, it is a problem of unspoken
 assumption that the subnet prefix is always 64.
 Do you know what they say assumptions? -- It's the mother of all f*
 ups.

 It's as straightforward as this: whenever you're coding something,
 enforce limits. And set it to a sane default. And allow the admin to
 override it when necessary.
 
 I tend to agree, but I think you talk about a different kind of limit. 
 This kind of limit to avoid memory overflow, thrashing, is not the same
 as to protect against security attacks.

What's the difference between the two? -- intention?



 The protocol limit set at 64 (subnet size) is not something to prevent
 attacks.  It is something that allows new attacks.

What actually allows attacks are bad programming habits.

The /64 has exposed bad programming habits.. that's it.



 An implementation that will restrict the size of an instantiation of a
 data structure (say,limit its size to a max hosting 2^32 nodes) will be
 a clear limit to something else: subnets that want to be of that
 particular 2^32 size.

You cannot be something that you cannot handle. I can pretend to be
Superman... but if after jumping over the window somehow I don't start
flying, the thing ain't working and won't be funny when I hit the floor.

Same thing here: Don't pretend to be able t handle a /32 when you can't.
In practice, you won't be able to handle 2**32 in the NC.

Take the /64 as Addresses could be spread all over this /64 rather
than you must be able to handle 2**64 addresses on your network.



 Also, think that people who develop IP stacks don't necessarily think
 Ethernet, they think many other link layers.  Once that stack gets into
 an OS as widespread as linux, there is little control about which link
 layer the IP stack will run on.  Actually there they want no limit at all.
 
 It is not as simple as saying it is programmer's fault.

Not enforcing limits is a programmer's fault. Most security exploits
rely on that.



 It is unspoken because
 it is little required (almost none) by RFCs.  Similarly as when the
 router of the link is always the .1.
 That's about sloppy programming.

 Train yourself to do the right thing. I do. When I code, I always
 enforce limits. If anything, just pick one, and then tune it.
 
 I am trained thank you.

What I meant was: one should train oneself such that you don't really
need to think about it. Enforcing limits is one of those. First thing
your brain must be trained to is that before you allocate a data
structure, you check how big the thing is, and how big it's supposed to be.

And it's not just limits. e.g., how many *security* tools need superuser
privileges, but will never give up such superuser privileges once they
are not needed anymore?

Know thyself (http://en.wikipedia.org/wiki/Know_thyself). I know my
code is not going to be as good as it should. So I better limit the
damage that it can cause: enforce limits, and release unnecessary
privileges. And fail on the safe side. You could see it as
compartmentalization, too.


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 01:02 PM, Alexandru Petrescu wrote:
 Speaking of scalability - is there any link layer (e.g. Ethernet) that
 supports 2^64 nodes in the same link?  Any deployed such link? I
 doubt so.
 Scan Google's IPv6 address space, and you'll find one. (scan6 of
 http://www.si6networks.com/tools/ipv6toolkit is your friend :-) )
 
 Do you think they have somewhere one single link on which 2^64 nodes
 connect simultaneously?  (2^64 is a relatively large number, larger than
 the current Internet).
 
 Or is it some fake reply?

Apparently, it's not fake (although I didn't scan the *whole* space). I
bet there's some trick there, though. -- I don't expect them to be
running 2**64 servers...

With a little bit more of research, it shouldn't be hard to check
whether the responses are legitimate or not (TCP timestamps, IP IDs,
etc. are usually your friends here).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: Question about IPAM tools for v6

[Fernando Gont]

Alex,

On 01/31/2014 01:47 PM, Alexandru Petrescu wrote:
 It's as straightforward as this: whenever you're coding something,
 enforce limits. And set it to a sane default. And allow the admin to
 override it when necessary.

 I tend to agree, but I think you talk about a different kind of limit.
 This kind of limit to avoid memory overflow, thrashing, is not the same
 as to protect against security attacks.

 What's the difference between the two? -- intention?
 
 Mostly intention, yes, but there are some differences.
 
 For example, if we talk limits of data structures then we talk mostly
 implementations on the end nodes, the Hosts.

Enforce, say, 16K, 32K, or 64K. And document it.


 For ND, if one puts a limit on the ND cache size on the end Host, one
 would need a different kind of limit for same ND cache size but on the
 Router.  The numbers would not be the same.

64K probably accommodates both, and brings a minimum level of sanity.



 The protocol limit set at 64 (subnet size) is not something to prevent
 attacks.  It is something that allows new attacks.

 What actually allows attacks are bad programming habits.
 
 We're too tempted to put that on the back of the programmer.

It's the programmer's fault to not think about limits. And it's our
fault (IETF) that do not make the programmer's life easy -- he should't
have to figure out what a sane limit would be.


 But a
 kernel programmer (where the ND sits) is hard to suppose to be using bad
 habits.

THe infamous blue screen of death would suggest otherwise (and this is
just *one* example)...



 If one looks at the IP stack in the kernel one notices that
 people are very conservative and very strict about what code gets there.

.. in many cases, after... what? 10? 20? 30 years?


  These are not the kinds of people to blame for stupid errors such as
 forgetting to set some limits.

Who else?

And no, I don't just blame the programmer. FWIW, it's a shame that some
see the actual implementation of an idea as less important stuff. A good
spec goes hand in hand with good code.


 You cannot be something that you cannot handle. I can pretend to be
 Superman... but if after jumping over the window somehow I don't start
 flying, the thing ain't working and won't be funny when I hit the
 floor.

 Same thing here: Don't pretend to be able t handle a /32 when you can't.
 In practice, you won't be able to handle 2**32 in the NC.
 
 I'd say depends on the computer?  The memory size could, I believe.

References, please :-)



 Take the /64 as Addresses could be spread all over this /64 rather
 than you must be able to handle 2**64 addresses on your network.
 
 It is tempting.  I would like to take it so.
 
 But what about the holes?  Will the holes be subject to new attacks?
 Will the holes represent address waste?

Unused address space. In the same way that the Earth's surface is not
currently accommodating as many many as it could. But that doesn't meant
that it should, or that you'd like it to.



 If we come up with a method to significantly distribute these holes such
 that us the inventors understand it, will not another attacker
 understand it too, and attack it?

Play both sides. And attack yourself. scan6
(http://www.si6networks.com/tools/ipv6toolkit) exploit current
addressing techniques. draft-ietf-6man-stable-privacy-addresses is meant
to defeat it.

Maybe one problem is the usual disconnect between the two: Folks
building stuff as if nothing wrong is ever going to happen. And folks
breaking stuff without ever thinking about how things could be made
better.  -- But not much of a surprise: pointing out weaknesses usually
hurt egos, and fixing stuff doesn't get as much credit as fixing it in
the security world.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: Question about IPAM tools for v6

[Fernando Gont]

On 01/31/2014 02:30 PM, Alexandru Petrescu wrote:
 I tend to agree, but I think you talk about a different kind of limit.
 This kind of limit to avoid memory overflow, thrashing, is not the
 same
 as to protect against security attacks.

 What's the difference between the two? -- intention?

 Mostly intention, yes, but there are some differences.

 For example, if we talk limits of data structures then we talk mostly
 implementations on the end nodes, the Hosts.

 Enforce, say, 16K, 32K, or 64K. And document it.
 
 Well, it would be strange to enforce a 16K limit on a sensor which only
 has 4k memory size.

That's why it should be configurable. -- Set a better one at system startup.


 Enforcing that limit already means write new code
 to enforce limits (if's and so are the most cycle-consuming).

That's the minimum pain you should pay for not doing it in the first place.

And yes, writing sloppy code always requires less effort.



 On another hand, the router which connects to that sensor may very well
 need a higher limit.
 
 And there's only one stack.
 
 I think this is the reason why it would be hard to come up with such a
 limit.

Make a good default that handles the general case, and make it
configurable so that non-general cases can be addressed.



 For ND, if one puts a limit on the ND cache size on the end Host, one
 would need a different kind of limit for same ND cache size but on the
 Router.  The numbers would not be the same.

 64K probably accommodates both, and brings a minimum level of sanity.
 
 Depends on whether it's Host or Router... sensor or server, etc.

Do you run a host or router that needs more than 64K entries?



 But a
 kernel programmer (where the ND sits) is hard to suppose to be using bad
 habits.

 THe infamous blue screen of death would suggest otherwise (and this is
 just *one* example)...
 
 The fault of blue-screen-of-death is put on the _other_ programmers
 (namely the non-agreed device programmers). :-) the hell is the others.

I don't buy that. Win 95 (?) infamously crashed in front of the very
Bill Gates upon connection of a scanner.

And W95 was infamous for one-packet of death crashes (the nukes from
the '90s)



 You cannot be something that you cannot handle. I can pretend to be
 Superman... but if after jumping over the window somehow I don't start
 flying, the thing ain't working and won't be funny when I hit the
 floor.

 Same thing here: Don't pretend to be able t handle a /32 when you
 can't.
 In practice, you won't be able to handle 2**32 in the NC.

 I'd say depends on the computer?  The memory size could, I believe.

 References, please :-)
 
 Well I think about simple computer with RAM and virtual memory and
 terabyte disks.  That would fit well a 2^64-entry NC no?

Consider yourself lucky if your implementation can gracefully handle,
say, 1M entries.



 Take the /64 as Addresses could be spread all over this /64 rather
 than you must be able to handle 2**64 addresses on your network.

 It is tempting.  I would like to take it so.

 But what about the holes?  Will the holes be subject to new attacks?
 Will the holes represent address waste?

 Unused address space. In the same way that the Earth's surface is not
 currently accommodating as many many as it could. But that doesn't meant
 that it should, or that you'd like it to.
 
 Hmm, intriguing... I could talk about the Earth and its ressources, the
 risks, the how long we must stay here together, the rate of population
 growth, and so on.
 
 But this 'unused address space' is something one can't simply just live
 with.
 
 Without much advertising, there are some predictions talking 80 billion
 devices arriving soon.  Something like the QR codes on objects, etc.
 These'd be connected directly or through intermediaries.  If one
 compares these figures one realizes that such holes may not be welcome.
 They'd be barriers to deployment.

mm.. what's the problem here?

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Question on DHCPv6 address assignment

[Fernando Gont]

Folks,

I'm wondering about the following two aspects of different DHCPv6
implementations out there:

1) What's the pattern with which addresses are generated/assigned? Are
they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?

2) What about their stability? Is there any intent/mechanism for them to
be as stable as possible? Or is it usual for hosts to get a new
address for each lease?

P.S.: I understand this is likely to vary from one implementation to
another... so please describe which implementation/version you're
referring to.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: ipv6hackers Meeting in Berlin

[Fernando Gont]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI

-  Original Message 
Date: Sat, 13 Jul 2013 20:30:54 +0200
From: Fernando Gont fg...@si6networks.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623
Thunderbird/17.0.7
MIME-Version: 1.0
To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com
Subject: ipv6hackers Meeting in Berlin

Folks,

We finally put everything in place to announce the very first IPv6
Hackers meeting.

All the relevant info is available at::
http://www.ipv6hackers.org/meetings/berlin-2013


-  cut here 
IPv6 Hackers Meeting - Berlin 2013

** What **

- From a couple of years now, we have had a mailing-list devoted to IPv6
hacking (i.e., testing, tools, low-level stuff, etc.), home of the
ipv6hackers group. The mailing-list (charter, subscription options,
etc.) is available at:
http://lists.si6networks.com/listinfo/ipv6hackers/.

We're planning to have our first in-person meeting, which will feature a
number of presentations (which MUST be accompanied
with code and/or measurements/testing).


** When **

July 30 (Tuesday), 2013. From 16:00 to 19:00.


** Where **

Salzufer 14, 10587  Berlin, Germany. EANTC AG (European Advanced
Networking Test Center) Headquarters.

If you'll be arriving from the IETF 87 venue (Intercontinental Berlin),
it's about a 30-minute walk.

Maps available here: http://www.ipv6hackers.org/meetings/berlin-2013


** How to participate **

The meeting is open for participation, at no cost.

If you have any interesting stuff to present, please send the following
information to i...@ipv6hackers.org *before* July 23, 2013:

 * Proposed presentation title
 * Abstract
 * Speaker name

Note: All presentations must be practical in nature. They must feature
tools, testing, and/or measurements.
-  cut here 


- -- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJR4duzAAoJEJbuqe/Qdv/xBIIIANhTW659F1QJ6N2O4OloaOnD
1hDxvMCYuiHxXNdJEokFye/cvkIp+gtEgmmuhmiVr96F4lufLPxSj99bUNNAHAO2
EcWoNI0f7YrjFqBsghtdEN+ygMSs/rs1+CnW1eoCB6CatH+th/KdBcF/JPj4mt3r
iB4ZXP7A0ZYQGry+GvDQEt8tcspmKVSaGROYTGbMUFORLSuVpIuwp7YltQBMFf0c
Pm3W3OgVo/gFLEehmSqkwUHsZBZPXxuVHoWApq0Z9BYEUzn7qmsgw009/Q6QdgYn
mT0o0CF3JhH+uVpfnwIXj1alEl/qJi38x3cnwDfMNoNv+U86yN69VnVelWl6F+E=
=lC9y
-END PGP SIGNATURE-

ipv6hackers meeting in Berlin (July 28th, 2013)

[Fernando Gont]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Folks,

- From a couple of years now, we have had a mailing-list devoted to IPv6
hacking (i.e., testing, tools, low-level stuff, etc.). The
mailing-list (charter, subscription options, etc.) is available at:
http://lists.si6networks.com/listinfo/ipv6hackers/.

We're planning to have our first in-person meeting on July 28th, 2013,
in Berlin (most likely in the afternoon, between lunch and the IETF
welcome reception). The venue would be either the IETF venue
(InterContinental Berlin), or some nearby hotel/room (to be confirmed
soon).

We're planning to have some presentations (which MUST be accompanied
with code :-) ), and might also have an IPv6 mini-hackathon (i.e.,
work on code, test implementations, try stuff).

In order to plan for the meeting, we'd need to have some indication of
how many people would attend, whether they would have stuff to
present, etc. So I've set up a very short on-line survey to help us
plan for the meeting.

If you're interested, please take 5 minutes to complete the survey at:
https://www.surveymonkey.com/s/FFL386K

Thanks!

Best regards,
- -- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





- -- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRuagfAAoJEJbuqe/Qdv/xfSQH/j3z4caZlMcd36EKVEPwHfIy
Fw2lQBRch8IXc+V6bqFOn0wf/zru93pKOef3SJZK8fKTnJe90kAymw464XCltYEp
TThEUiuZo9wNDzCTTE9yuxpCguYenpr9oCHzvux9fdPm1l0hhe7yuse3yuahnf6H
i56lwsSmr2T2U3+2xEAvOcpzkxoidH193Su4c8FSf8aT74kz4z5XjsaRNbqZEQpd
jIVvom9ucCy3u4coPAHaPe9nePx6+JaZZ5wW08i2bH3EAHxL6iMM9/biNzYVlKYu
BxgFUCYVVK1CTV9PqdPFFe4cp2TLz/0D/LL/jXCpbISVRs4FWdQipP4zqyOn0kY=
=iok7
-END PGP SIGNATURE-

Re: Windows 2008R2 MTU reverts to default

[Fernando Gont]

On 06/10/2013 10:59 PM, Dick Visser wrote:

 A thought, so only qualifies as might, I don't know Windows to speak
 definitively, but ... IPv6 NDP Route Advertisement with the MTU option?

 Windows then updating the manually-configured value based upon learnt
 values on the wire?
 
 Yup, this was the case. I watched it continuously, and when an RA came
 in, it overwrote the manually configured MTU.
 Next question: how do I prevent that from happening?

Is there any reason for which the router is including an MTU option?

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1