headers
Ralph Droms | 1 Jun 2011 02:39
Picon

Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]


On May 31, 2011, at 6:41 PM, Mark Smith <ipng <at> 69706e6720323030352d30312d31340a.nosense.org> wrote:

> On Tue, 31 May 2011 09:24:19 -0700
> james woodyatt <jhw <at> apple.com> wrote:
> 
>> On May 30, 2011, at 7:38 PM, Fred Baker wrote:
>>> 
>>> [...] IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to
configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of
RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could
imagine the thing probing with a DHCPv6 request. [...]
>> 
>> For what it's worth, the behavior of Apple's iOS 4.3 and later is straightforward.  If there is no RA, then
there is no IPv6.  iOS 4.3 doesn't support manual IPv6 configuration, so automatic configuration is the
only way to plumb it.  The DHCPv6 client only starts if the router indicates availability with O=1. 
Remember when I was complaining that we needed RFC 6106 for the O=0 case?  Given that we have that, I don't see
any benefit to starting the DHCPv6 client unless a router explicitly tells us to expect service.  No
router?  No need for dynamic host configuration.
>> 
> 
> Actually, that raises an interesting question. If SLAAC and DHCPv6 were
> enabled by default, ignoring the M and O bits, what type of DHCPv6 is
> enabled - stateless or stateful? 
> 
> I'm sure people are expecting stateful, so the DHCPv6 client would
> initially issue a Solicit and including IA_NA and IA_TA options. My
> understanding is that if a DHCPv6 server won't ever provide any
> addresses (as it is a "stateless" server), it is to ignore those Solicit
> messages. Since the end-node may have also acquired addresses via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 1 Jun 2011 07:13
Picon

Preliminary report on flow label hash algorithms

In summary: the algorithm suggested in the Appendix to
draft-ietf-6man-flow-3697bis-04 doesn't perform very well
on real packets, and I have an improved version to suggest.

This doesn't affect the normative text in the draft, so I
believe it can be fixed.

The full story, with fonts, tables and pictures:

http://www.cs.auckland.ac.nz/~brian/flowhash.html

--

-- 
Regards
   Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 8 comments |
headers
Fernando Gont | 1 Jun 2011 20:52
Picon
Favicon

Re: Preliminary report on flow label hash algorithms

On 06/01/2011 02:13 AM, Brian E Carpenter wrote:
> In summary: the algorithm suggested in the Appendix to
> draft-ietf-6man-flow-3697bis-04 doesn't perform very well
> on real packets, and I have an improved version to suggest.

Sorry if I'm missing something: Any reasons for which you chose a
different algorithm from the one described in
draft-gont-6man-flowlabel-security?

The algorithm in the aforementioned I-D has already been well tested for
randomizing TCP port numbers, timestamps, and sequence numbers. -- and I
don't think there's a real need to reinvent the wheel.

Thanks,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
Thomas Narten | 1 Jun 2011 22:42
Picon
Favicon

Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]

Brian E Carpenter <brian.e.carpenter <at> gmail.com> writes:

> Ray,

> Without going into details: how about turning this into
> draft-hunter-v6ops-something and having the debate over in v6ops?

> I think that would be useful, personally.

Actually, let me suggest something else.

Before spending a whole lot of time on this topic, is there anyone
else who thinks there is a problem here that needs solving? The last
thing we (as a group) need to do is spend time on a non-problem.

Personally, I don't see the issue here. I think the problem as stated
is a non-problem. And to be honest, this is the first time I have
heard anyone suggest what you describe is a real problem. So I wonder
whether anyone else thinks there is a problem here that needs fixing.

To the point:

> > Ray Hunter wrote:
> >> It's definitely going to become an operational FAQ, unless it is very
> >> clear whether/how a network operator can force equivalent use of
> >> DHCPv4 static address assignment for both source and destination
> >> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of
> >> GUA on an interface via a flag, or via RFC3484 bis), and how to
> >> achieve this effect for all nodes on a link, without resorting to
> >> local configuration. So I may as well be the first to ask.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralph Droms | 1 Jun 2011 23:10
Picon

Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]


On Jun 1, 2011, at 4:42 PM 6/1/11, Thomas Narten wrote:

> Brian E Carpenter <brian.e.carpenter <at> gmail.com> writes:
> 
>> Ray,
> 
>> Without going into details: how about turning this into
>> draft-hunter-v6ops-something and having the debate over in v6ops?
> 
>> I think that would be useful, personally.
> 
> Actually, let me suggest something else.
> 
> Before spending a whole lot of time on this topic, is there anyone
> else who thinks there is a problem here that needs solving? The last
> thing we (as a group) need to do is spend time on a non-problem.
> 
> Personally, I don't see the issue here. I think the problem as stated
> is a non-problem. And to be honest, this is the first time I have
> heard anyone suggest what you describe is a real problem. So I wonder
> whether anyone else thinks there is a problem here that needs fixing.

I don't think there is a problem worth fixing.

> 
> To the point:
> 
>>> Ray Hunter wrote:
>>>> It's definitely going to become an operational FAQ, unless it is very
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 2 Jun 2011 00:09
Picon

Re: Preliminary report on flow label hash algorithms

Fernando,

My to-do list included running your algorithm against the
same datasets. However, I just looked at your draft again and
it seems to be underspecified - you do not define what functions
F and G are. And I think it's stateful, because of the statement
"if(three-tuple is unique)".

All we are discussing is a non-normative suggested algorithm,
so this is not critical for the draft to go forward IMHO.

    Brian

On 2011-06-02 06:52, Fernando Gont wrote:
> On 06/01/2011 02:13 AM, Brian E Carpenter wrote:
>> In summary: the algorithm suggested in the Appendix to
>> draft-ietf-6man-flow-3697bis-04 doesn't perform very well
>> on real packets, and I have an improved version to suggest.
> 
> Sorry if I'm missing something: Any reasons for which you chose a
> different algorithm from the one described in
> draft-gont-6man-flowlabel-security?
> 
> The algorithm in the aforementioned I-D has already been well tested for
> randomizing TCP port numbers, timestamps, and sequence numbers. -- and I
> don't think there's a real need to reinvent the wheel.
> 
> Thanks,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fernando Gont | 2 Jun 2011 01:19
Picon
Favicon

Re: Preliminary report on flow label hash algorithms

Hi, Brian,

On 06/01/2011 07:09 PM, Brian E Carpenter wrote:
> My to-do list included running your algorithm against the
> same datasets. However, I just looked at your draft again and
> it seems to be underspecified - you do not define what functions
> F and G are.

To some extent, this was intentional. -- Although I do agree I should
have noted (non-normatively) that MD5 would be a good choice for F().

As for G(), one could use MD5(), or even something simpler.

> And I think it's stateful, because of the statement
> "if(three-tuple is unique)".

Not sure what you mean. The specs themselves argue that a flowid
shouldn't be reused if it's already in use. So one could envision that
the flowid used for a communication instance is stored in the
corresponding TCB, and that's how it is checked.

Anyway, the same algorithm could be used without performing that check,
and simply having faith in the algorithm on the fact that collisions
will not occur. :-)

> All we are discussing is a non-normative suggested algorithm,
> so this is not critical for the draft to go forward IMHO.

It looks like such an algorithm would belong to a separate document --
particularly if the suggestion is going to be "non-normative". i.e., a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 2 Jun 2011 02:01
Picon

Re: Preliminary report on flow label hash algorithms

On 2011-06-02 11:19, Fernando Gont wrote:
> Hi, Brian,
> 
> On 06/01/2011 07:09 PM, Brian E Carpenter wrote:
>> My to-do list included running your algorithm against the
>> same datasets. However, I just looked at your draft again and
>> it seems to be underspecified - you do not define what functions
>> F and G are.
> 
> To some extent, this was intentional. -- Although I do agree I should
> have noted (non-normatively) that MD5 would be a good choice for F().
> 
> As for G(), one could use MD5(), or even something simpler.

OK.

>> And I think it's stateful, because of the statement
>> "if(three-tuple is unique)".
> 
> Not sure what you mean. The specs themselves argue that a flowid
> shouldn't be reused if it's already in use. 

That was RFC3697. RFC3697bis is more relaxed about this point, because
it isn't an essential property for load balancing. If uniqueness
is a hard requirement, you're definitely forced into a stateful
model, but that is out of scope for 3697bis.

> So one could envision that
> the flowid used for a communication instance is stored in the
> corresponding TCB, and that's how it is checked.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karl Auer | 2 Jun 2011 02:36
Picon

Re: Ra-Guard evasion (new Internet-Drafts)

On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote:
> * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at:
> http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

Section 1, second para: "of identifying" should be "to identify"

Section 1, third para: "had so far been" should be "have so far been"

Section 1, third para: "deemed as appropiate" should be "deemed
appropriate"

Section 1, fourth para: The techniques could *probably* be exploited.
And maybe mention DHCPv6 here as well...?

Section 2.1, first sentence is missing words or something. No legitimate
what?

Section 2.1 first para: should be "simply ignoring". Suggest leaving
"simple", "simply" etc out of such sentences. It might not be simple at
all.

Section 2.1 second para: should be "implement" not "implements"

Page 6: This might be a silly thought, but why would the implementation
need to do fragment reassembly? All it needs to do is locate RAs,
whether they are in fragments or not. It has all the info it needs in
the fragment with the RA. That is, it passes earlier packets, but if a
fragment arrives with an RA in it, it checks the RA. The destination
might end up with a partial packet, but it will never get the damaging
fragment, and will eventually discard the partial.
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Leslie | 5 Jun 2011 05:10
Favicon

Re: ITU-T SG17 IPv6 security work items liaison

Stephen Farrell <stephen.farrell <at> cs.tcd.ie> wrote:
> 
> We received a liaison [1] from ITU-T saying they're
> planning to start a couple of work items on the
> security of IPv6. As far as we know, they envisage
> developing a "technical guideline on deploying IPv6"
> and "Security Management Guideline for implementation
> of IPv6 environment in telecommunications
> organizations." Bear in mind that they're just starting
> so they know about as much as we would just before a
> BoF or something like that.
> 
> I think we'd like to respond to them that that's great,
> and we'll be interested in their results, but can they
> *please* come back to us before saying something should
> be changed so's we can talk about it.

   I don't think that's quite right. We should welcome their studying
security issues; but I think we need to _strongly_ encourage them to
start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since
it has _significant_ changes from RFC 4294 (and an ITU-T study based
on RFC4294 will be of rather limited value).

   Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol
or the Node Requirements. The language there should talk of documenting
security "concerns" or "issues" or whatever term seems neutral enough;
and list as the next step exchanging ideas of what "changes" might help.

   Clearly, ITU-T is entirely justified in publishing recommendations
of what level of security-related-trust to place in IPv6 packet
(Continue reading)

Permalink | Reply | 5 comments |

Gmane