Barry Leiba | 22 May 06:48 2015
Picon

Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-v6ops-cidr-prefix-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Only editorial comments here, for your consideration.  The one about
"barring" is the most important one.

-- Section 1 --
In the second paragraph, I suggest removing the parentheses from
"(mis)".

In the fourth paragraph, I had to read the first sentence several times
in order to parse it.  The word order confused me, making me think "link
routing", rather than "to link".  You can easily fix that by changing "to
not link" to "not to link".

In the fifth paragraph, "barring" is ambiguous: I don't know whether you
(Continue reading)

Tim Chown | 20 May 10:14 2015
Picon

Re: Extension Headers / Impact on Security Devices

> On 19 May 2015, at 19:55, Joe Touch <touch <at> isi.edu> wrote:
> 
> On 5/18/2015 4:43 AM, sthaug <at> nethelp.no wrote:
>>>> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling,
Internet-scale use cases of extension headers have been brought up.
>>> 
>>> this is clearly wrong. FH, AH, ESP are all widely deployed.
>>> any form of tunnelling is essentially either using the IP header as an extension header. including GRE.
>> 
>> AH is in RFC 2402 (1998).
>> ESP is in RFC 2406 (1998).
>> FH is in RFC 2460 (1998).
>> 
>> Do we have any examples of Internet-scale use cases where the extension
>> header has been defined *after* RFC 2460?
> 
> The following are defined after 2460:
> 
> 135 	Mobility Header 			[RFC6275]
> 139 	Host Identity Protocol 			[RFC7401]
> 140 	Shim6 Protocol 				[RFC5533]
> 253 	Use for experimentation and testing 	[RFC3692][RFC4727]
> 254 	Use for experimentation and testing 	[RFC3692][RFC4727]
> 
> FWIW.

Which, as I think you imply, haven’t exactly been widely implemented or successfully used.

The other question is what existing work is being done that relies on the correct (desired) operation of
EHs? The two that would spring out would be segment routing and sfc, at least one of which is using the
(Continue reading)

Enno Rey | 15 May 13:37 2015
Picon

Extension Headers / Impact on Security Devices

All,

yesterday's IPv6 WG session at the RIPE meeting saw another debate on extension headers.
Pls allow to submit our contribution to v6ops as well. Let me know if you think that the 6man mailing list
would be the more appropriate place.

Here's some material/sources we'd like to bring up:

- this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in
their at the time of testing latest versions, by various combinations of extension headers and fragmentation:
https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf.

- here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs:
http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/.
http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/.

We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and
extension headers. For the moment I can only state that it's not just Cisco who are "affected". More
results will be available in some months.

As for the topic itself I'd like to summarize our position as follows:
- it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use
cases of extension headers have been brought up.
- we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone
expressed at the mic.
- from a security perspective they turn out to be a nightmare for (a number of) current security
architectures and controls. it is hence understandable (and we actually advise to do so) that they are
blocked at the _border_ of networks that have not yet managed to identify a compelling use case.
- looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options,
fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear
(Continue reading)

Jens Ott - Opteamax GmbH | 14 May 10:02 2015
Picon

Idea about updating RFC3849


Hi Mailinglist-Members,

I am pretty new on this list, so I first wave a "Hello" into the
round... and immediately continue to ask the question, which led me to
subscribing to this list. Apologies if I chose the wrong list, please
advise me, where to put my question in this case.

I work as consultant and already accompanied several IPv6 roll-outs
from the first idea "we want V6" until production. While
enterprise-setups are mostly /32 or less IPs, I see more and more
rollouts which need much bigger space.

At least in RIPE-Region, each LIR can receive a /29 without any
justification. And here is where my problem starts. While writing
documentation and addressing-plans before requesting the actual prefix
at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in
RFC3849. But what to do for bigger nets (lower bitmasks)?

Before starting to push the ball on the field by writing a proposal,
I'd be happy to hear if there is support in the community for updating
this rfc and officially define a bigger prefix for documentation.

As said, if I chose the wrong mailinglist or simply started bringing
my idea into the community in a wrong way, any advise and comment is
appreciated. I have no experience with the processes at ietf yet.

Best regards and thanks
--

-- 
Jens Ott
(Continue reading)

Benoit Claise | 12 May 21:45 2015
Picon

Benoit Claise's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-v6ops-cidr-prefix-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I never realized this was not documented. So thanks for this document.

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

Philip Matthews | 11 May 17:38 2015
Picon

EIGRP and the Design Choices draft

Folks:

Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a
request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.

To do this, we are looking for information on dual-stack networks that run EIGRP.

Specifically we want to get feedback on production dual-stack networks that run EIGRP. We are interested
in any of the following combinations:

* EIGRP for both IPv4 and IPv6
* EIGRP for IPv4 and OSPF/ISIS for IPv6
* OSPF/ISIS for IPv4 and EIGRP for IPv6

If you know of any such networks, then please email either Victor or myself. (If you are concerned about
doing this, then you could email one of the chairs instead).

Our goal is to get answers to the following questions:
1) Is this combination known to work well -- in other words, have multiple production networks used it
without problems?
2) Why was this particular dual-stack combination chosen? 
3) Any comments or pieces of advice that you would like to pass on?

Philip

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

(Continue reading)

Lorenzo Colitti | 11 May 03:59 2015
Picon

Re: I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt

On Tue, May 5, 2015 at 2:27 AM, 神明達哉 <jinmei <at> wide.ad.jp> wrote:
> Observing the posting, let me invite commentary on it.

It seems that the main points of my previous comments
- http://www.ietf.org/mail-archive/web/v6ops/current/msg20179.html
- http://www.ietf.org/mail-archive/web/v6ops/current/msg20200.html
still apply.

So my conclusion is the same:
 
What he said. https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt shows that there are no changes in this document except that the text from appendix B moved to section 3 and some minor editorial changes. I don't see why such minor changes should materially change the WG's position on this document.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 10 May 13:47 2015
Picon

new draft: draft-ietf-v6ops-siit-eam

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-eam. Please take a
look at it and comment.

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

Tim Chown | 7 May 15:41 2015
Picon

Re: Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

> On 7 May 2015, at 12:53, Ted Lemon <Ted.Lemon <at> nominum.com> wrote:
> 
> On May 7, 2015, at 7:26 AM, Mikael Abrahamsson <swmike <at> swm.pp.se> wrote:
>> 
>> So basically, I want the entire document changed so that "filtering" is replaced by "being dropped" or
similar wording that doesn't convey intent on behalf of the people running the device.
> 
> +1!

That’s a very good suggestion.

Tim

_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 7 May 10:20 2015
Picon

Re: Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Hi,

On 7 May 2015, at 08:45, Fred Baker (fred) <fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:


On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <markzzzsmith-/E1597aS9LT0CCvOHzKKcA@public.gmane.org> wrote:

Hi,

I don't have a strong opinion on whether it should be reincorporated or not, as I haven't kept up with that discussion.

However, if it does get included, I think the following statement needs more clarification:

"Many IPv6 router implementations suffer from a negative performance
   impact when IPv6 Extension Headers are employed."

Is this really the case? It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many routers are vulnerable to the EH based DoSes and other issues mentioned by default.

If it is the case, I think we need a list of those routers that by default violate RFC 2460 by inspecting past the HbH header when they are not the destination of the packet.

What I have been trying to get Fernando to do is identify under what conditions that might be true, rather than paint all equipment from all vendors under all conditions with slime. If the router has a filter (ACL) that forces it to parse the headers to find a TCP header, and the parsing is dumped to a slower path, that would be an example, and would be a valid example to bring out. But I don’t accept sliming all equipment from all vendors under all circumstances. It’s not the case.

The original point of the draft, which has perhaps been lost somewhat as discussion has drifted, was to handwave to an observable problem, to implicitly note there was an impact on applications/protocols using EHs, and to encourage more measurement/investigation of the problem.

I think the discussion we’re on now would be better put into a follow-up text, so we can ship the original problem statement. I suspect the follow-up will be more heavily debated, witness the (lack of) progression of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02, but my preference would be to stop tinkering, to ship, and focus on a new document.

Tim


I'd expect routers by default to have just processed/forwarded IPv6 packets based on the fixed IPv6 header fields, ignoring EHs and allowing fast path forwarding, and to only start looking at EHs if configured to via ACLs etc.

I think the above statement is effectively implying that fast path forwarding of IPv6 isn't a default in many IPv6 router implementations, and I'd be quite surprised if that is true, which is why I think more clarification would be useful.

Regards,
Mark.


Folks,

Question to the wg:

Folks keep bringing up the reasons for which operators filter IPv6
packets with EHs (the reasons have been discussed on this mailing-list a
few times already). Something along these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>
but we removed that section in later revisions (prior to the wg call for
adoption of this document).

A number of folks have argued that we should reincorporate that section.
Me, I think it would be useful, but can live without reincorporating
that section...

It would be nice to hear from the wg about this. Thoughts?

Thanks!

Best regards,
--
Fernando Gont
e-mail: fernando-+DCVu5wVcRK4Tu3zPC53fQ@public.gmane.org || fgont-hxuqIv1aByuEK/hMebVsMw@public.gmane.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Fernando Gont | 6 May 23:13 2015
Picon

Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Folks,

Question to the wg:

Folks keep bringing up the reasons for which operators filter IPv6
packets with EHs (the reasons have been discussed on this mailing-list a
few times already). Something along these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>
but we removed that section in later revisions (prior to the wg call for
adoption of this document).

A number of folks have argued that we should reincorporate that section.
Me, I think it would be useful, but can live without reincorporating
that section...

It would be nice to hear from the wg about this. Thoughts?

Thanks!

Best regards,
--

-- 
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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


Gmane