>This document formally deprecates the IPv6 site-local unicast prefix
>defined in [RFC3513], i.e. 111011 binary or FEC0::/10. The
>special behavior of this prefix MUST no longer be supported in new
>implementations.
Does this imply "but SHOULD otherwise be treated like a globa
> I would like to hear from the working group on how we should proceed. I
> think the choices are:
>
> A) Deprecate Site-Local addresses independently from having an alternative
> solution available. This would mean that the working group should treat
> the deprecation, and requirements and s
YES -- Deprecate site-local unicast addressing
Does not provide any tangible security benefit.
Provides false sense of security.
Increases application complexity.
Reduces application reliability.
Requires too many compensating hacks to other protocols.
---
> I don't believe that servers, for example, need to implement mobile
> node functionality. If a node is fixed and will not move, what use
> is mobile node functionality?
indeed. and, as another example, my laptop is portable, but is almost
always stationary when connected to a network, and as a
> 3. They cannot be externally routed (Some would
>consider this to be a minus as well).
> I believe 1 and 2 can be solved (fairly) easily by other means. The big
> problem is number 3. The ambiguity is essential to preventing them from
> ever being routed.
so, i'm not conviced that we hav
> Back to my original post: do you have the IOS image that can create http
> tunnels on a Cisco 12000?
Why should I believe that a sufficiently determined adversary couldn't
somehow obtain a bootleg copy of IOS source?
- Bill
---
> Good idea. Trouble is, the tunneling protocol is blocked by the
> firewall. What's your next move?
what *does* the firewall allow through? if the answer is "nothing",
we've reduced this to the "no external connectivity case" and you can
save a bunch of money by simply removing the firewall and
> > create a tunnel.
>
> => I guess you would give the same answer
> for link-locals and many other cases.
link-locals are there for autoconfiguration, not security.
> So, if you have a tunnel, secure it.
answer is non-responsive. we were discussing unauthorized
router modifications.
site
> ... How do you reconfigure a router to forward
> site-local traffic to the outside?
create a tunnel.
- Bill
IETF IPng Working Group Mailing List
IPng Home Page: http
>It is certainly reasonable for the manufacturer of light switches
>to only support SL/LL rather than potentially multiple global
>prefixes.
So, my existing duct-tape-and-string home automation setup lets me
turn on my porch light from work if I'm coming home late. Why would I
upgrade it to an IP
> If we can't enforce a "MUST" or "MUST NOT" then it shouldn't be in
> the spec in the first place.
Does not follow. The IETF has no enforcement authority.
- Bill
IETF IPng Workin
> For v4, I agree with Bill *if* the multiple addresses belong to
> different subnets.
>
> For v6, this is blurry. Would you call multihomed a host that has both a
> link-local and a regular unicast address on the same interface? I don't
> think so.
>From the point of view of what applications n
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).
For what it's worth, I've occasionally heard the term used in an
application-lay
> However, should any new connections (SCTP associations) FROM this host to
> a peer list the deprecated address as part of the association? Given the
> existing text and this discussion, it seems that it should not, as other
> preferred address(es) are available. Of course unless as qualified b
Given that there is no documented method to do stateless HAO
verification, I believe it's extremely premature to make HAO a MUST.
- Bill
IETF IPng Working Group Mailing List
IPng H
> have you read the latest MIPv6 spec?
I have, in fact read the spec.
> there is an explicit code in the Binding Ack which says "Route
> Optimization unnecessary due to low traffic". the CN just has to
> refuse the binding with this code.
So, existing nodes will reportedly refuse the binding w
> the point is this verification can be done in many ways.
but a correspondent node may only run services which won't benefit
from route optimization (i.e,. "hit and run" short exchanges typical
of a DNS server).
Let's assume the measured binding cache hit rate is 0% for a
particular server --
i'm in violent agreement. HAO processing should not be a MUST.
HAO is not useful without verification and largely pointless unless
you're doing route optimization and can support a binding cache which
is large enough to be meaningful.
Given that there's already a way for a node to indicate "n
> Yes, a router with multiple connected sites is certainly the case
> where the biggest savings from eliminating or restricting site locals
> would be found.
Hosts have routing tables, too.
A host connected to multiple sites needs nearly all of the mechanisms
that a multi-site router needs.
> What problem are you trying to solve?
securing neighbor discovery exchanges.
> IPsec works for ND?
Using AH/ESP to protect ND works fine once the SA's exist.
However, there's a chicken & egg problem if you want to use IKE, and
manually configuring N*(N-1) SA's across N machines on the link
> So is it the case then that there would be no change in IPsec policy
> required for doing AAA-based or roaming consortia-based key
> management?
"policy" could mean a lot of things.
the overall architecture does not require change. the idea that there
can be more than one way to manage keys
> faithd does NAT while changing the address family at the same time, doesn't
> it?
No doubt one of the KAME folks will correct me but my impression was
that it was more of a TCP-layer proxy rather than a layer-3 NAT.
Regardless of how it works, it's one of many ways for a
site-local-addresses
This comment is only on the heuristic:
One possible heuristic for distinguishing these cases is to assume
that an application that invokes a passive open (as its first
network usage) is a server, while an application that first invokes
an active open be assumed to be a client.
My fir
It's also worth pointing out that NAT is not the only way a
site-local-only system could get external connectivity.
A transport-layer gateway/relay like a socks implementation for v6 or
the KAME "faithd" would be another way..
- Bill
--
> - With an RFC 1918 host behind a firewall, compromising the firewall is
> enough to grant that host outside access. Single point of failure.
>
> - With a site-local only host behind a firewall, this become a double
> hack thing: you need to reconfigure the firewall _and_ reconfigure the
> host
I think i was a little too subtle in my original post.
Denying external connectivity on a host-by-host basis is harder than
it looks, because if any system with external connectivity at any
layer is compromised, it can be used as a springboard to attack
"internal" systems which the firewall alleg
> The outbound-only firewall is a false idea of security as well since
> 2nd generation peer-to-peer software such as Morpheus can easily
> bypass firewalls and allow ingress connections to RFC1918 hosts.
>
> On the other hand, considering that a typical IPv6 will _not_ feature
> IPv6 NAT, an IPv6
> as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp
> server as well.
You don't need submillisecond-accurate NTP time, though -- accurate to
the nearest hour will likely be sufficient in many cases.
- Bill
--
> Well the traceroute implementation we use around here limits how fast it
> sends out probes, to no more than one a second. From your comment I take
> it not everyone does this?
Most of traceroute implementations I've seen are "self clocking",
sending out the next probe when they get back a resp
> > It seems that it would be appropriate for an implementation to
> > "reclassify" packets at the time of encapsulation into ESP -- the
> > packet is, after all, going through a logical trust boundary as it's
> > being encrypted..
>
>If I understand Brian's concern correctly, that may
>
> Oh. I now see what I missed. Why doesn't including
> the SPI into the flow key work? You wouldn't be
> able to police based on port numbers (ie try to be
> a firewall), but some would say that's a feature
> not a bug.
Well, except that there's no such thing as a "well known SPI"..
When done co
>Huh? I thought that one of the requirements for ESP was to
>copy the DSCP to the outer header. If I recall correctly,
>this bothers some people from a traffic analysis standpoint,
>but that seems to be part and parcel with QoS so that doesn't
>hold much water IMO.
It seems th
> I would like to suggest another choice:
>
> e) a set of bits we hold in reserve for the future
>
> I don't think that we have enough experience to pick between a), b), or c)
> now, and think that something might come up in the future where 28 bits in
> the IPv6 header might be very usef
> If I am reclassifying traffic at an administrative boundary then by
> definition I don't care about or trust the "QoS information" in the
> packet as anything more than a hint which I am free to ignore (depending
> on the TCS I have with the upstream network). When crossing security
> boundari
> | Can we qualify them with a "frequency indicator," e.g. once
> | in a life-time, once a year, once a month, once a day?
>
> Given that #5 needs to be N times a day (twice as stated), if we can
> handle that one, then we should be able to handle all the others up to
> at least once a day fr
> 5) There is no route for this IPv4 packet [which is actually an ICMPv6
>error] as determined by the IPv4 routing table. An ICMPv4 error is
>generated.
>
> 6) The ICMPv4 error is converted to an ICMPv6 error so that it can
>be sent to the original IPv6 sender [router itself].
>
> No
An alternate way to avoid cache poisoning which avoids the need to
invent a new "b**l*w*ck" concept:
- never enter glue into any part of the cache's namespace
- attach glue records to the NS records they came with; when a cache
resolves an NS record into a set of locations, fall back to the NS
>> A authoritative server that only has entries and
>> is asked for an A6 record MUST NOT synthesize A6 records
>> from the ones. There is no restriction on populating both
>> types, but it is strongly recommended against, and in such a case,
>> bo
> A authoritative server that only has entries and
> is asked for an A6 record MUST NOT synthesize A6 records
> from the ones. There is no restriction on populating both
> types, but it is strongly recommended against, and in such a case,
> both RRsets MUST be identic
I'm not sure what problem you're trying to solve, but:
- The assumption in the draft seems to be that SA's are heavy-weight
objects. this is not the case and it is certainly my intent to ensure
that they are as lightweight as possible within Sun's ipsec
implementation..
- I agree with what St
The problem is aggravated by "anti-poison" protections that
essentially prevent serving cached records from domains for which
the local server is not authoritative.
With DNSSEC and signed entries, it doesn't matter who gives you the
data, it's who signs it..
I haven't looked at it th
rfc1122 (host requirements) says:
An ICMP error message MUST NOT be sent as the result of
receiving:
...
*a datagram destined to an IP broadcast or IP multicast
address, or
*a datagram sent as a link-layer broadcast, or
> > which in turn would prevent all communications. Also, as per RFC
> > 2401 we do not in general have the possibility to specify policies
> > for individual ICMP message types.
>
> This passed the IESG in RFC 2894 (so it must be true):
>
>
>Note that for the SPD to distinguish Router Renu
> To me it would make sense to have associated data that is the index of
> the security association used (is that the right term? I'm not really
> up to date on IPSEC terminology).
The actual spi value is not likely to be very useful to the
application (when key management is in use, it's a rando
I haven't seen a convincing case why even inter-ISP classifiers need
to know the inner port numbers or inner ip addresses for encrypted
traffic.
If I were implementing the hypothetical extension header, I'd have to
provide policy knobs which determine whether it gets added to outbound
traffic; wh
>What semantics do you think you can impose on something like that?
>
> => just associate a QoS to a SPI and send the information (ie. how to
> classify packets (addresses, ..., SPI) and the QoS) to the classifier
> (which is by definition on-path).
That could be brute-forced into working
>The SPI doesn't have the semantics.
>
> => I disagree, the SPI has the semantics we'd like to give to it.
When reasonable key management protocols are in use, IPSEC SPI's are
pseudo-random, chosen by the receiver, and securely communicated to
the sender via the key management protocol.
T
The other alternative is to listen on more sockets, one for each
interface, but that is messier to setup, in particular if you have
several addresses on each interface. (Perhaps attaching a link-id in
the scope-id field when binding the sockets, as discussed in some
other thread, ma
Looks like other people are running into trouble with the "accept ipv4
traffic through ipv6 sockets" feature:
http://www.isc.org/products/BIND/bind9.html, in the bind-9.0.0rc1
release notes:
On some systems, IPv6 and IPv4 sockets interact in unexpected
ways. For details, see doc/misc
> Not at all. Either you send the ICMP error back down the same SA as
> the offending packet...
Uhh, SA's are unidirectional. Perhaps you mean "send the ICMP packet
using the same SA a normal, non-errored response would use.."
- Bill
> Keeping the bottom 24 bits fixed at an initial random value, or
> changing them less frequently than the upper 40, would cut down the
> number of multicast groups joined.
.. but make it easier to correlate multiple connections from the same
host. Unless there are a *lot* of nodes on a link, mo
> If you really need to receive both addresses for some reason, the care-of
> address is the one that should be obtainable only via IPV6_RECVDSTOPTS.
> Logically, the IP layer in the correspondent host should swap the received
> home address and care-of address before passing the packet to an uppe
52 matches
Mail list logo
