An update to a meeting session request has just been submitted by Eric Vyncke,
a Chair of the opsec working group.
-
Working Group Name: Operational Security Capabilities for IP Network
Infrastructure
Area Name: Operations and Management
There are several issues in this section, not just the NAT:
> 2.1.2. Use of ULAs
>
>ULAs are intended for scenarios where IP addresses will not have
>global scope so they should not appear in the global BGP routing
>table.
We need to align that with the clarification in draft-bchv-
Looking at archives was quicker than expected. Unless the subject got changed,
the only comments I see from last July are [adding folks who replied in email
snippet for clarification]:
—
On 8 July 2016 at 18:36, Erik Kline mailto:e...@google.com>>
wrote:
>>> Section 2.1.2 is far too permissiv
On 04/18/2017 02:31 PM, otr...@employees.org wrote:
>>>
>>> Yes, you are missing something. RFC4443 specifies what behaviour
>>> should be if a router receives a packet on a point to point link that
>>> would end up being forwarded back out the same link. The specified
>>> behaviour is drop and sen
I am unclear as to what the comment and/or request for change of language is.
I will look at list archives from last year to determine what the discussion
may have been but it would be useful to have some more context. I am aware of
folks using ULAs (not something I personally favor). In past
>> The ping pong attack is mitigated in RFC4443.
>
> I must be missing something.. what does RFC4443 have to do with
> this? A ping pong attack does not require the attack packets to
> be ICMPv6 echo requests...
https://tools.ietf.org/html/rfc4443#section-3.1 One spe
On 04/18/2017 02:15 PM, otr...@employees.org wrote:
> Fernando,
>
> The ping pong attack is mitigated in RFC4443.
I must be missing something.. what does RFC4443 have to do with
this? A ping pong attack does not require the attack packets to
be ICMPv6 echo requests...
>>>
Fernando,
The ping pong attack is mitigated in RFC4443.
>>>
>>> I must be missing something.. what does RFC4443 have to do with this? A
>>> ping pong attack does not require the attack packets to be ICMPv6 echo
>>> requests...
>>
>> https://tools.ietf.org/html/rfc4443#section-3.1
>> One sp
Hi, Ole,
On 04/18/2017 12:44 PM, otr...@employees.org wrote:
>>> The ping pong attack is mitigated in RFC4443.
>>
>> I must be missing something.. what does RFC4443 have to do with this? A
>> ping pong attack does not require the attack packets to be ICMPv6 echo
>> requests...
>
> https://tools.i
fwd'ing, since there was a typo in the original email...
Forwarded Message
Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6
Date: Tue, 18 Apr 2017 12:10:37 +0100
From: Fernando Gont
To: otr...@employees.org, op...@ietf.ortg
CC: Gunter Van De Velde , v6...@ietf.org
Oper
>
> On 18 Apr 2017, at 13:10, Fernando Gont wrote:
>
> On 04/18/2017 09:18 AM, otr...@employees.org wrote:
>> A few initial comments. Draft is not quite ready.
>>
>> Section 2.1.3:
>> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links.
>
> Agreed on this.
>
>
>> The ping pong atta
Hi:
In 2.6.1.5. Stateful DHCPv6 Lease:
In short, the DHCPv6 lease file is less interesting than in the IPv4
era. DHCPv6 servers that keeps the relayed data-link layer address
in addition to the DUID in the lease file do not suffer from this
limitation.
You should add an informative
A few initial comments. Draft is not quite ready.
Section 2.1.3:
6164 does not _recommend_ /127 it _permits_ /127 on p2p links.
The ping pong attack is mitigated in RFC4443.
I am not convinced there is justification that this document should recommend
/127 for "security reasons".
Section 2.1.
Relaying message to WGLC discussion alias
G/
From: v6ops on behalf of Erik Kline
Date: Tuesday, 18 April 2017 at 09:30
To: Gunter Van De Velde
Cc: "v6...@ietf.org" , 6man <6...@ietf.org>
Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6
2.1.2. Use of ULAs
Still? Really?
A new meeting session request has just been submitted by Eric Vyncke, a Chair
of the opsec working group.
-
Working Group Name: Operational Security Capabilities for IP Network
Infrastructure
Area Name: Operations and Management Area
Ses
Thanks Ron for the review, your 2 points about the new RFC 2460bis are right to
the point :-)
-éric
From: OPSEC on behalf of Ron Bonica
Date: Monday 17 April 2017 at 22:02
To: Gunter Van De Velde , "opsec@ietf.org"
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6
Hi Gunter,
I support pu
16 matches
Mail list logo