headers
Fernando Gont | 1 Sep 2010 03:01
Picon
Favicon

Re: ping-pong phenomenon with p2p links & /127 prefixes

Hi, Gert,

>> I think you miss my point: they might finally comply with the specs one
>> day (if you ask or not, others might) and you will have forgotten about
>> this little subtle problem and upgrade your routers and voila your
>> network is broken.
> 
> Cisco understands subnet-anycast, and disables this for /127s.

Only for /127s, and automagically?

What about Junipers?

Thanks!

Kind regards,
--

-- 
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 | 1 comment |
headers
Olivier Vautrin | 1 Sep 2010 03:25
Favicon

RE: ping-pong phenomenon with p2p links & /127 prefixes

Juniper also disables the subnet anycast for /127s. We are very aware of this issue and how our customers are
using /127s (hence the /127 draft). 

Regards,
Olivier

> -----Original Message-----
> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of
> Fernando Gont
> Sent: Tuesday, August 31, 2010 6:01 PM
> To: Gert Doering
> Cc: v6ops <at> ops.ietf.org; ipv6 <at> ietf.org
> Subject: Re: ping-pong phenomenon with p2p links & /127 prefixes
> 
> Hi, Gert,
> 
> >> I think you miss my point: they might finally comply with the specs
> one
> >> day (if you ask or not, others might) and you will have forgotten
> about
> >> this little subtle problem and upgrade your routers and voila your
> >> network is broken.
> >
> > Cisco understands subnet-anycast, and disables this for /127s.
> 
> Only for /127s, and automagically?
> 
> What about Junipers?
> 
> Thanks!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Laganier, Julien | 2 Sep 2010 20:31

RE: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

Hi Suresh,

Suresh Krishnan wrote:
> 
> Hi Ralph,
>    <Snipped a whole lot of old quoting>
> 
> On 10-08-26 08:18 PM, Ralph Droms wrote:
> > Suresh...
> >
> > But the multicast RAs don't advertise prefixes, right, so the
> > subscriber nodes won't be able to complete SLAAC?
> 
> Correct.
> 
> > I think the point is to use standard node stacks: Windows 7, OS X,
> > Linux.  Do any of them send periodic RSs?
> 
> No. All of them send RSs (3) on interface initialization. If no routers
> are found, there is no periodic retransmission mechanism like for DHCPv6
> Solicits. This is true of SLAAC in general (with or without RS marking).
> 
> > But this option isn't all that is needed for the deployment
> > architecture,
> 
> Correct. But the rest is standard RFC4861/RFC4862 behavior.
> 
> > and it appears that there is a significant problem with that
> > deployment architecture.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK | 7 Sep 2010 15:38
Favicon

RE: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

Suresh,

One of the main challenge in implementing the model proposed by the draft 
is that edge router has no reliable indication if a host (once it has sent an RS)  
is present on the network or not.

Please see detailed comments below..

--
Shree

1.  Prefix Lifetime Binding/Expiry..

	Unlike DHCP there is no mechanism with SLAAC for a host (client) to renew its address/prefix binding.
	Relying on host to send a router solicitation (as a keep alive) toward edge router is not a viable option.
	
	RFC 4861 (section 6.3.7 )
	
	Router solicitation "may" be sent after following events

		- The interface is initialized at system startup time.
		- The interface is reinitialized after a temporary interface
		   failure or after being temporarily disabled by system
		   management.
		- The system changes from being a router to being a host, by
		   having its IP forwarding capability turned off by system
		   management.
		- The host attaches to a link for the first time.
		- The host re-attaches to a link after being detached for some time.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Shane Amante | 7 Sep 2010 21:58

Question on draft-gont-6man-flowlabel-security-00

Hi Fernando,

I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00

Unless I misunderstand something, you're proposing that a flow-label be constructed using the IPv6
Source & Destination values as input-keys to a hash function as follows:
   Flow Label = counter + F(Source Address, Destination Address, Secret Key)
If you do the above, then intermediate routers that are performing LAG and/or ECMP load-balancing will not
be able to use the flow-label as an input-key for calculating a load-balancing hash.  Instead,
intermediate routers will have to fetch a 5-tuple of {Source IP, Destination IP, Protocol, Source Port,
Destination Port} from the IPv6 header to calculate a load-balancing hash (and, at the same time,
completely ignore the flow-label as an input-key for its flow-based load-balancing hash, since it's redundant).

Why couldn't (or, shouldn't) the hash function instead use the following:
   Flow Label = counter + F(Source Port, Destination Port, [Protocol], Secret Key)

If you did this, then intermediate routers & switches that were performing LAG and/or ECMP load-balancing
could easily use the following /fixed-offset/ header fields as input-keys to the load-balancing hash:
   Load Balancing Hash = F(Source IPv6 Address, Destination IPv6 Address, "draft-gont" Flow Label)
IMHO, this would allow draft-gont-6man-flowlabel-security to nicely/peacefully co-exist with widely
deployed/used flow-based load-balancing schemes for LAG and ECMP.

Thanks,

-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
(Continue reading)

Permalink | Reply | 12 comments |
headers
Steven Blake | 7 Sep 2010 22:17

Re: Question on draft-gont-6man-flowlabel-security-00

On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante <shane <at> castlepoint.net>
wrote:

> Hi Fernando,
> 
> I have a question on:
> http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
> 
> Unless I misunderstand something, you're proposing that a flow-label be
> constructed using the IPv6 Source & Destination values as input-keys to
a
> hash function as follows:
>    Flow Label = counter + F(Source Address, Destination Address, Secret
>    Key)
> If you do the above, then intermediate routers that are performing LAG
> and/or ECMP load-balancing will not be able to use the flow-label as an
> input-key for calculating a load-balancing hash.  Instead, intermediate
> routers will have to fetch a 5-tuple of {Source IP, Destination IP,
> Protocol, Source Port, Destination Port} from the IPv6 header to
calculate
> a load-balancing hash (and, at the same time, completely ignore the
> flow-label as an input-key for its flow-based load-balancing hash, since
> it's redundant).

Shane,

I don't think your conclusion follows.  One thing you want for LAG/ECMP is
for each flow from a given <src_addr, dst_addr> to have a unique FL value. 
Fernando's algorithm achieves this by incrementing counter for each new
flow from that address pair.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Brian E Carpenter | 8 Sep 2010 03:18
Picon

Flow label (im)mutability

Hi,

The authors of draft-carpenter-6man-flow-update (now also
including Shane Amante) are working on a new version. One
fundamental issue that has come up is about the (lack of)
security properties of the flow label. The most brutal
expression of this is:

The flow label field is always unprotected (no IP header
checksum, not included in transport checksums, not included in
IPsec checksum). It cannot be verified and can be used as a
covert channel, so it will never pass a security analysis. Thus
some firewalls *will* decide to clear it, whatever the IETF
wants. This is inevitable, for exactly the same reason that the
diffserv code point is rewriteable at domain boundaries.

If this is correct, it is futile to assert that the flow label
MUST be delivered unchanged to the destination, because we
cannot rely on this in the real world.

Are we ready to accept this analysis?

--

-- 
Regards
   Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
(Continue reading)

Permalink | Reply | 37 comments |
headers
Joel M. Halpern | 8 Sep 2010 03:32

Re: Flow label (im)mutability

While there may be a few firewalls that will do whatever they think they 
need to in order to shut down covert channels, I do not see that as a 
significant factor.  I imagine most devices will not do so, since it 
does represent a meaningful threat to the site being protected.
(There are other covert channels available, that I have never heard of 
conventional commercial firewalls attempting to close.  Heck, I could 
have a pattern of connections to two remote sites for a covert channel. 
  I don't buy this as a driver.)

Yours,
joel

On 9/7/2010 9:18 PM, Brian E Carpenter wrote:
> Hi,
>
> The authors of draft-carpenter-6man-flow-update (now also
> including Shane Amante) are working on a new version. One
> fundamental issue that has come up is about the (lack of)
> security properties of the flow label. The most brutal
> expression of this is:
>
> The flow label field is always unprotected (no IP header
> checksum, not included in transport checksums, not included in
> IPsec checksum). It cannot be verified and can be used as a
> covert channel, so it will never pass a security analysis. Thus
> some firewalls *will* decide to clear it, whatever the IETF
> wants. This is inevitable, for exactly the same reason that the
> diffserv code point is rewriteable at domain boundaries.
>
> If this is correct, it is futile to assert that the flow label
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel M. Halpern | 8 Sep 2010 03:50

Re: Flow label (im)mutability

That was supposed to read "since it does NOT represent a meaningful threat."
Joel

On 9/7/2010 9:32 PM, Joel M. Halpern wrote:
> While there may be a few firewalls that will do whatever they think they
> need to in order to shut down covert channels, I do not see that as a
> significant factor. I imagine most devices will not do so, since it does
> represent a meaningful threat to the site being protected.
> (There are other covert channels available, that I have never heard of
> conventional commercial firewalls attempting to close. Heck, I could
> have a pattern of connections to two remote sites for a covert channel.
> I don't buy this as a driver.)
>
> Yours,
> joel
>
> On 9/7/2010 9:18 PM, Brian E Carpenter wrote:
>> Hi,
>>
>> The authors of draft-carpenter-6man-flow-update (now also
>> including Shane Amante) are working on a new version. One
>> fundamental issue that has come up is about the (lack of)
>> security properties of the flow label. The most brutal
>> expression of this is:
>>
>> The flow label field is always unprotected (no IP header
>> checksum, not included in transport checksums, not included in
>> IPsec checksum). It cannot be verified and can be used as a
>> covert channel, so it will never pass a security analysis. Thus
>> some firewalls *will* decide to clear it, whatever the IETF
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Morrow | 8 Sep 2010 04:44
Picon

Re: Flow label (im)mutability

On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter
<brian.e.carpenter <at> gmail.com> wrote:
> Hi,
>
> The authors of draft-carpenter-6man-flow-update (now also
> including Shane Amante) are working on a new version. One
> fundamental issue that has come up is about the (lack of)
> security properties of the flow label. The most brutal
> expression of this is:
>
> The flow label field is always unprotected (no IP header
> checksum, not included in transport checksums, not included in
> IPsec checksum). It cannot be verified and can be used as a
> covert channel, so it will never pass a security analysis. Thus
> some firewalls *will* decide to clear it, whatever the IETF
> wants. This is inevitable, for exactly the same reason that the
> diffserv code point is rewriteable at domain boundaries.
>
> If this is correct, it is futile to assert that the flow label
> MUST be delivered unchanged to the destination, because we
> cannot rely on this in the real world.
>
> Are we ready to accept this analysis?

what's the threat if it changes in flight? multiple times even?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 11 comments |

Gmane