Last Updated: February 19, 2005
Current specification:
draft-ietf-ngtrans-isatap-24.txt
Previous versions:
When submitting an issue, please fill in the following template:
Description of issue: (short single line description of issue)
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Lengthy description of problem
Requested change:
Proposal
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
Deferred - The decision reached depends on the outcome of another issue.
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
Issues can also be given the Reject status, or the version of the document when the accepted fix has appeared.
Issue 1: Are SEND references in Section 8 needed?
Submitter:
Juha Wiljakka; Tim Gleeson
Submitter email address: juha.wiljakka@nokia.com;
tgleeson@cisco.com
Date first submitted: March 10, 2004.
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority:
1
Section: 8
Rationale/Explanation of issue:
Similar comments received from both submitters asking whether SEND references in Section 8 are needed?
[FT suggestion]:
Change phrase from "are used" to "are either used or
omitted". Sentence in question now reads:
"Securing mechanisms for neighbor discovery (e.g., [SEND])
are either
used or omitted according to the trust model
appropriate for the given
deployment scenario [SENDPS]."
[Resolution from 3/16 ISATAP authors' discussion]:
Consensus to remove [SEND] statement from Section 8; open new issue
tracker item to add [SENDPS] statement to Security
Considerations.
Resolution: Accepted
Issue 2: Add text describing use/non-use of LLAO's?
Submitter:
Fred Templin; Tim Gleeson
Submitter email address: fred.templin@nokia.com;
tgleeson@nokia.com
Date first submitted: March 10, 2004
Reference:
Document:
isatap-pre21.txt
Comment type:
Technical
Priority: 1
Section: 6.3
Rationale/Explanation of issue:
Open issue on whether/not to say more about LLAOs; discussed between submitters.
[Status after 3/16 ISATAP authors' discussion]:
Consensus to remove LLAO specification (i.e., section 6.3) from isatap-21 with
one objection.
Fred
Templin concern that removing specification would unnecessarily limit future
ways forward.
Dave Thaler to draft note seeking clarification on v6ops publication
strategies.
[3/17 Update]:
Dave Thaler's proposed note for v6ops sent to co-authors.
Fred Templin e-mail clearing concerns
from 3/16 sent to co-authors.
[3/17 Status]:
Fred Templin proposed resolution: remove section 6.3 from isatap-21
and not forward Dave's note to the v6ops list. Pending agreement
from co-authors.
[3/18 Status]:
Proposed resolution approved by co-authors. Issue closed.
Resolution: Accepted
Issue 3: [SENDPS] statement needed for Security
Considerations
Submitter: ISATAP co-authors
Submitter email address: fred.templin@nokia.com,
tgleeson@cisco.com, mohitt@microsoft.com,
dthaler@microsoft.com
Date first submitted: March
16, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section: 10
Rationale/Explanation of issue:
Agreed during 3/16 ISATAP authors' discussion that clarifying note regarding
IPv6 ND trust models and threats required for ISATAP security consideration.
[Proposed text as of 3/16]:
"The threats associated with IPv6 ND are described in [SENDPS].
Since an ISATAP link spans an entire IPv4 site, mitigating
threats by restricting access to a link necessarily entails
restricting access to the site."
[3/17 Status]:
Pending agreement/change suggestions from co-authors.
[3/18 Status]:
Fred Templin proposes changing first sentence to:
"Since an ISATAP link spans an entire IPv4 site, mitigating
IPv6 ND threats for ISATAP necessarily entails restricting
access to the site."
[3/19 Status]:
Tim Gleeson sends alternate proposal for first sentence (approved by Fred
Templin):
"Since an ISATAP link spans an entire IPv4 site,
restricting access to the link (to mitigate threats)
is achieved by restricting access to the site."
[3/23 Status]:
Mohit Talwar approves proposed text.
[3/29 Status]:
Dave Thaler proposes: "can be" instead of: "is acheived".
Proposed
paragraph now reads:
"The threats associated with IPv6 ND are described in [SENDPS].
Since an ISATAP link spans an entire IPv4 site, restricting access
to the link (to mitigate threats) can be achieved by restricting access
to the site."
Resolution: Accepted
Issue 4: Temporary/CGA address statement needed for Security
Considerations
Submitter: Dave Thaler
Submitter email address: dthaler@microsoft.com
Date first submitted: March
16, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section: 10
Rationale/Explanation of issue:
[Proposed text after 3/16 ISATAP authors' discussion]:
"The use of temporary addresses [RFCxxx] and CGAs [xxx]
on ISATAP interfaces is outside the scope of this
specification."
[3/17 Status]:
Pending agreement/change suggestions from co-authors.
[3/23 Status]:
Mohit Talwar approves proposed text.
[3/24 Update]:
Also with new proposed text, second validity check for decapsulation
to be removed as per 3/16 authors' confcall agreement. Validity check
to be removed is:
"the IPv6 source address is the address of a neighbor on the
ISATAP interface, or:"
[3/29 Update]:
Both proposed resolutions accepted during ISATAP authors' confcall.
Resolution: Accepted
Issue 5: Text on timer settings based on FQDN resolution
needs work
Submitter: Tim Gleeson, Fred Templin
Submitter email address: tgleeson@cisco.com,
fred.templin@nokia.com
Date first submitted: March
16, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section: 8.3.2
Rationale/Explanation of issue:
Section 8.3.2, second paragraph, second sentence - text on timer settings based on TTLs from FQDN resolution needs work.
[Proposed text as of 3/16 after e-mail iterations between Tim Gleeson; Fred Templin]:
"When a FQDN is used, and when it is resolved via a service
that includes a Time-to-Live (TTL) with the IPv4 addresses
returned (e.g., DNS 'A' resource records [STD13]), the timer
is set to the minimum of PrlRefreshInterval and the minimum
TTL returned."
[3/17 Update]:
Mohit Talwar suggests changing: "a FQDN" to "an FQDN".
Dave Thaler suggests making TTL-based timer setting a SHOULD.
Fred Templin acknowledges suggested changes; proposes:
"When an FQDN is used, and when it is resolved via a service
that includes TTLs with the IPv4 addresses returned (e.g.,
DNS 'A' resource records [STD13]), the timer SHOULD be set
to the minimum of PrlRefreshInterval and the minimum TTL
returned."
[3/17 Status]:
Pending agreement/change suggestions from co-authors.
[3/18 Status]:
Proposed resolution agreed by co-authors. Issue closed.
Resolution: Accepted
Issue 6: DHCP server/relay deployment on ISATAP routers
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
22, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
[3/22 Initial Submission]:
Older versions of the spec (e.g. isatap-16.txt) included specific guidelines for
deployment of the DHCPv6 server/relay function co-resident with ISATAP
routers, but this is no longer present in -21. Text from the -16 document was:
"When the site uses DHCPv6 [RFC3315] as the stateful address
autoconfiguration
mechanism, the server/relay function MUST be deployed equally
on each router
is a member of the PRL."
Proposed resolution is to add text such as the above back to isatap-21.txt.
Also to add reference to [RFC3633] to pick up prefix delegation. (Q: do
we also need to say something about receiving DHCPv6 multicast addresses
in section 6.3? These are not covered under a "node's required multicast
addresses.")
[3/24 Update]:
Follow-up discussion between Tim Gleeson; Fred Templin. Tim not sure anything
should be said about DHCPv6; notes that DHCPv6 messages are sent to the
"All_DHCP*" multicast address and not unicast. Fred Templin agreed
with
Tim's point; suggested that no new text about multicast mappings be added
but proposed the following sentence be added to "Site Administration
Considerations":
"The DHCPv6 [RFC3315] server/relay function MUST be deployed
on each node that configures an ISATAP router interface
advertised in the site's PRL."
[3/25 Update]:
Tim Gleeson suggests saying nothing about DHCPv6 in "Site Administration
Considerations"; Fred Templin undecided, but leaning toward Tim's
suggestion.
[3/29 Update]:
Agreement from all co-authors to avoid mention of DHCPv6 in ISATAP spec.
Resolution: Reject
Issue7: Various text changes
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
24, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S/1/2
Section:
Rationale/Explanation of issue:
[3/24 Initial Submission]:
Several text change suggestions (with different severity levels) from Fred
Templin:
MUST change:
************
1) Under "Normative References", the reference for RFC 3513 is
incorrect
and needs to be changed to appear as follows:
+ [RFC3513] Hinden, R. and S.
Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2003.
2) Under "7.2 Decapsulation",
we don't currently say what to do when there
is no matching ISATAP interface to receive the packet. Propose changing:
- If an ISATAP interface that
configures a matching locator is found,
- the decapsulator MUST verify that the paccket's IPv4 source address is
- correct for the encapsulated IPv6 source address. The IPv4 source
- address is correct if:
to:
+ If an ISATAP interface that
configures a matching locator is not
+ found, the packet is silently dropped. Otherwise, the decapsulator
+ MUST verify that the packet's IPv4 source address is correct for the
+ encapsulated IPv6 source address. The IPv4 source address is correct if:
SHOULD Change:
**************
3) Under "Terminology", the definition for "ISATAP
interface" seems vague. Suggest changing:
- ISATAP interface:
- an ISATAP node's point-to-multipoint IPv66 interface used for
- automatic tunneling; also provides a conttrol/forward plane
- nexus for its associated addresses.
to:
+ ISATAP interface:
+ an ISATAP node's point-to-multipoint IPv6 interface used for
+ automatic tunneling of IPv6 packets in IPv4.
4) Under "1.
Introduction", first sentence of last paragraph, we no longer have any text
that describes the conceptual model; suggest dropping the phrase
"conceptual model and".
5) Under: "8.2 Router and
Prefix Discovery - Router Specification", incorrect use of
"Advertisements" (plural) in first sentence; should be
"Advertisement" (singular).
6) Under: "8.1 Conceptual Model
of A Host", first sentence of Potential Router List is weak
and gives unnecessary forward reference to text that appears just a few
sentences later.
Suggest: s/the mechanisms specified in section 8.3/router and prefix discovery
MAY change:
***********
7) Suboptimal wording in section 8.3.4, paragraph beginning: "When periodic
events".
Propose following changes:
a) Change:
- When periodic events are
scheduled, the node SHOULD set TIMER(i) such
- that the next Router Solicitation event wwill refresh remaining
To:
+ When periodic Router Solicitation
events are scheduled, the node
+ SHOULD set TIMER(i) such that the next event will refresh remaining
b) Change:
- routers. While the node continues
to schedule periodic events for
- PRL(i), and while PRL(i) continues to actt as a router, the node
- resets TIMER(i) after each expiration eveent as described above.
To:
+ routers. While the node continues
to schedule periodic Router
+ Solicitation events for PRL(i), and while PRL(i) continues to act as
+ a router, the node resets TIMER(i) after each expiration event as
+ described above.
[3/25 Update]:
Fred Templin proposes rejecting item #2 under "MUST change" above
(reasons given in e-mail).
[3/25 Update]:
Fred Templin proposes additional change suggestion for the "MAY
change" category:
8) In Section 6.1, the text is cumbersome and does no align with
the text found in the normative reference as well as it could.
Suggest the following changes:
Change:
- ([RFC3513], section 2.5.1 and appendix A)). They are formed by concatenating
- the 24-bit IANA OUI (00-00-5E), the 8-bitt hexadecimal value 0xFE, and a
- 32-bit IPv4 address in network byte orderr as follows (where the 'm' bits
- represent the concatenated IPv4 address)::
To:
+ ([RFC3513], section 2.5.1 and appendix A) by concatenating the 24-bit
+ IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 32-bit
+ IPv4 address in network byte order as follows:
Change:
- When the IPv4 address is known to be globbally unique, the 'u' bit is set
- to 1; otherwise, the 'u' bit is set to 0 ([RFC3513], section 2.5.1).
To:
+ When the IPv4 address is known to be globally unique, the "u"
+ (universal/local) bit is set to 1; otherwise, the "u" bit is set
+ to 0. "g" is the individual/group bit, and "m" are the
bits of
+ the IPv4 address.
[3/29 Update]:
Agreement on proposed resolutions for sub-issues 1) through 8) received from
all co-authors. Issue closed.
Resolution: Accepted
Issue 8: "Site Administration" Change
Suggestion
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
26, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
[3/26 Initial Submission]:
"Site Administration Considerations" change suggestion.
Under "Site
Administration Considerations", we currently have text that unnecessarily
presumes DNS 'A' resource records. This text should have been changed in the
same
manner as the change suggestion accepted for FQDN resolution in issue #5.
Suggested resolution:
a) Change the second
sentence in section 9. to read: "The PRL is normally maintained as
a FQDN for the ISATAP service in the site's name service, but it may also be
administered
by some other means (see: section 8.3.2)."
b) Change the final
sentence in section 9. to read: "When the site's name service includes
TTLs with the IPv4 addresses returned, site administrators SHOULD configure the
TTLs
with conservative values to minimize control traffic."
[3/29 Update]:
New proposed resolution after receiving comments from Mohit; Tim:
a) "The PRL is
commonly maintained as a FQDN for the ISATAP service
in the site's name service (see: section 8.3.2)."
[3/29 Update]:
Dave suggests paragraph restructure:
Site Administrators mantain a Potential Router List (PRL) of IPv4
addresses representing ISATAP router interfaces.
The PRL is commonly
maintained as a FQDN for the ISATAP service
in the site's name service (see: section 8.3.2). There are no mandatory
rules for the selection of the FQDN, but site administrators are encouraged
to use the convention "isatap.domainname" (e.g., "isatap.example.com").
When the site's name
service includes TTLs with the IPv4 addresses
returned, site administrators SHOULD configure the TTLs
with conservative values to minimize control traffic.
Resolution: Accepted
Issue 9: Suggestion to promote RFC2529 to Normative
Reference
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
26, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
[3/26 Initial Submission]:
The Security Considerations section in older versions of the spec
cited [RFC2529] as normative text, but the reference has somehow
drifted into the informative category in isatap-21. Suggest bringing
this back to normative, since the RFC 2529 Security Considerations
section tells how site administrators should implement site security
and filtering in a way that applies identically for ISATAP.
Suggested resolution is to promote [RFC2529] reference to Normative,
and strengthen the first sentence in Security Considerations to read:
"The Security Considerations in the normative references are
taken as normative considerations for ISATAP."
[3/29 Update]:
Proposal to promote RFC 2529 to normative not supported. Alternate proposed
resolution was to add 1st paragraph of ([RFC2529], Security Considerations)
to Security Considerations for ISATAP as follows:
"Implementors should be aware that, in addition to posssible attacks against
IPv6, security attacks against IPv4 must also be considered. Use of IP security
at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons.
For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant
except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then
authentication of IPv4 will add little. Conversely, IPv4 security will not protect
IPv6 traffic once it leaves the ISATAP domain. Therefore, implementing IPv6
security is required even if IPv4 security is available."
[3/29 Update]:
Proposed alternate resolution accepted.
Resolution: Accepted
Issue 10: Add Back Security Considerations from -03.txt
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
26, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
Important passages that appeared in Security Considerations in the
'isatap-03.txt' draft are missing friom the '-21.txt' draft and should
be added back. Suggest adding back the 3rd and 4th paragraphs of Security
Considerations that appeared in the -03.txt draft (with updated section
numbers and citations). See:
http://www.geocities.com/osprey67/isatap/isatap-03.txt
[3/29 Update]:
Fred Templin to draft "consolidated security considerations rewirte" that
would obviate the above proposed resolution; send to co-authors for comment.
[4/05 Update]:
Tim Gleeson, Fred Templin, Dave Thaler agree that there is no need
to bring back the text proposed from the -03.txt draft.
Resolution: Reject
Issue 11: Add Back Security Considerations from -03.txt
(part 2)
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
26, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
Paragraph 5 of 'isatap-03.txt' had better text for expalining trust
basis than currently appears in '-21.txt. Suggest removing the
first sentence of the final paragraph of S.C. in '-21.txt', and
replacing it with the 5th paragraph of S.C. from '-03.txt' (MINUS
the final sentence of that paragraph, PLUS some minor wording
changes). Suggested text for '-21.txt' is:
"([RFC2461], section 6.1.2) implies that nodes accept Router
Advertisements received from on-link routers, as indicated by a
value of 255 in the IPv6 'hop-limit' field. Since this field is
not decremented when ip-protocol-41 packets traverse multiple
IPv4 hops, a different trust model is required for ISATAP. In
particular, ONLY those Router Advertisements received from a
member of the Potential Routers List are accepted (see: section
8.3.3). This trust model is predicated on the IPv4 source address
filtering and ip-protocol-41 filtering described above, and on
administrators ensuring that the Potential Router List for the
site is well maintained (see: section 9)."
[3/29 Update]:
Fred Templin to draft "consolidated security considerations rewirte" that
would obviate the above proposed resolution; send to co-authors for comment.
[4/05 Update]:
Tim Gleeson, Fred Templin, Dave Thaler agree that there is no need
to bring back the text proposed from the -03.txt draft.
Resolution: Rejected
Issue 12: Decapsulation Filtering Checks Broken
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March
31, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
Problem Statement:
******************
The Decapsulation filtering checks in section 7.2 are incorrect
due to both a faulty definition for the term "ISATAP address",
and broken text in section 7.2.
Proposed Resolution:
********************
1) In "Terminology", change the definition of "ISATAP address" to:
"ISATAP address:
an IPv6 unicast address with a prefix that matches an ISATAP
interface's on-link prefix, and an ISATAP interface identifier."
2) Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/
3) In section 7.2, change the text beginning at the second paragraph
to the end-of-section to the following:
"If an ISATAP interface that configures a matching locator is found,
the decapsulator MUST employ the following algorithm to determine
whether the packet's IPv4 source address is correct for the
encapsulated IPv6 source address:
if IPv6 source address is an ISATAP address
if IPv6 source address embeds IPv4 source address
IPv4 source address is correct
else
IPv4 source address is incorrect
endif
else
if IPv4 source address in PRL (see: section 8.1)
IPv4 source address is correct
else
IPv4 source address is incorrect
endif
endif
Packets for which the IPv4 source address is incorrect are processed
as specified for configured tunnels in ([MECH], section 3.6)."
[3/31 Update]:
Fred Templin proposes alternate text for Proposed Resolution, item 3):
"If an ISATAP interface that configures a matching locator is found,
the decapsulator MUST verify that the packet's IPv4 source address is
correct for the encapsulated IPv6 source address. For packets with an
ISATAP IPv6 source address, the IPv4 source address is correct if it
matches the IPv4 address embedded in the ISATAP interface identifier.
For all other packets, the IPv4 source address is correct if it is a
member of the Potential Router List (see: section 8.1).
Packets for which the IPv4 source address is incorrect are processed
as specified for configured tunnels in ([MECH], section 3.6)"
[4/1 Update]:
Tim Glesson writes that the checks don't seem to work because of not
being able to tell whether the ISATAP address is from *this* ISATAP
network or *some other* ISATAP network. Fred Templin replies that
disambiguating the "ISATAP address" definition should fix this.
[4/1 Update]:
Fred Templin proposes new definition for "ISATAP address" (to replace
the proposal given in 1) above):
"ISATAP address:
an IPv6 unicast address that matches an on-link prefix on
an ISATAP interface of the node, and includes an ISATAP
interface identifier."
[4/1 Update]:
Fred Templin suggests questions need to be answered regarding the
text for decapsulation checks:
1) If we receive a packet on an ISATAP interface with a link-local
ISATAP source address, and its embedded IPv4 address does not match
the IPv4 source address, BUT the IPv4 source address is a member of
the Potential Router List, should we drop the packet or hand it
up the stack?
2) Same question for non-link-local ISATAP source addresses.
Essentially, these questions are asking: "If an ISATAP IPv6 source
address is failed by the first test (embedded IPv4 matches the IPv4
source), do we drop the packet immediately, or give the packet a
second-chance via the second test (IPv4 source is a potential router)?"
Also, is the answer to this question the *same* for link-local
and non-link-local source addresses, or possibly different?
[4/2 Update]:
Tim Gleeson comments that ISATAP addresses failed by the first
test must be given a second chance via the second test. Fred Templin
agrees. New proposed resolution:
1) In Terminology, change definition of "ISATAP address" to:
"ISATAP address:
an IPv6 unicast address that matches an on-link prefix on
an ISATAP interface of the node, and includes an ISATAP
interface identifier."
2) Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/
3) Leave current decapsulation checks unchanged (i.e., reject the earlier
change suggestions proposed by Fred).
[4/5 Update]:
Closer review of Tim Gleeson's 4/2/04 message shows some material for
further discussion before deciding to leave current decapsulation checks
alone (see "4/2 Update"). To be discussed among all authors during
4/5/04 conference call.
Fred Templin wrote:
> > 1) If we receive a packet on an ISATAP interface with a
> > link-local ISATAP source address, and its embedded IPv4
> > address does not match the IPv4 source address, BUT the IPv4
> > source address is a member of the Potential Router List,
> > should we drop the packet or hand it up the stack?
Tim Gleeson wrote:
> Can link-local packets be redirected? I think the answer is
> YES, but would
> like confirmation. (addr-arch says "routers must not forward
> any packets
> with link-local source or destination addresses to OTHER
> links", my emphasis
> on OTHER.) If so...
>
> The answer is, DON'T DROP. It might be a redirected link
> local carrying the
> address of the original source in the IPv6 source, but the
> address of the
> router doing the redirection in the IPv4 source.
[4/5 Update]:
Tim Gleeson, Fred Templin, Dave Thaler agree to most recent proposal:
1) In Terminology, change definition of "ISATAP address" to:
"ISATAP address:
an IPv6 unicast address that matches an on-link prefix on
an ISATAP interface of the node, and includes an ISATAP
interface identifier."
2) Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/
3) Leave current decapsulation checks unchanged (i.e., reject the earlier
change suggestions proposed by Fred).
Resolution: Accepted
Issue 13: Consolidated Security Considerations section
needed
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted:
April 1, 2004
Reference:
Document: isatap-pre21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
From issues 3, 4, 9, 10, and 11 (discussed during 3/29/04 ISATAP authors' conference call)
a new Security Considerations section is needed to consolidate the changes. Closure of
this issue will automatically close issues 3, 4, 9, 10 and 11 also. Proposed text for
consolidated Security Considerations section is:
10. Security considerations
Implementors should be aware that, in addition to possible attacks
against IPv6, security attacks against IPv4 must also be considered.
Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant except if traffic
analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the ISATAP
domain. Therefore, implementing IPv6 security is required even if
IPv4 security is available.
The threats associated with IPv6 ND are described in [SENDPS]. Since
an ISATAP link spans an entire IPv4 site, restricting access to the
link (to mitigate threats) can be achieved by restricting access to
the site. As such, site border routers SHOULD implement IPv4 ingress
filtering and ip-protocol-41 filtering to prevent IPv6 source address
spoofing. Site border routers SHOULD also install a reject route for
the IPv6 prefix FC00::/7 [UNIQUE] so that packets with local IPv6
destination addresses will not be forwarded outside of the site via a
default route.
The Potential Router List (PRL) provides a trust basis for Router
Advertisement messages received on ISATAP interfaces (see: section 8).
This trust basis is predicated on restricting access to the link as
described above, and on site administrators ensuring that lists of
IPv4 addresses representing advertising ISATAP interfaces of PRL
members are well maintained (see: section 9).
The use of temporary addresses [RFC3041] and CGAs [CGA] on ISATAP
interfaces is outside the scope of this specification.
[4/5 Update]:
Second and third paragraphs updated based on Tim Gleeson,
Dave Thaler; Fred Templin discussion:
10. Security considerations
Implementers should be aware that, in addition to possible attacks
against IPv6, security attacks against IPv4 must also be considered.
Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant except if traffic
analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the ISATAP
domain. Therefore, implementing IPv6 security is required even if
IPv4 security is available.
The threats associated with IPv6 Neighbor Discovery are
described in [SENDPS].
There is a possible spoofing attack in which spurious ip-protocol-41
packets are injected into an ISATAP link from outside. Since an
ISATAP link spans an entire IPv4 site, restricting access to the link
can be achieved by restricting access to the site, i.e., by having site
border routers implement IPv4 ingress filtering and ip-protocol-41
filtering.
Another possible spoofing attack involves spurious ip-protocol-41
packets injected from within an ISATAP link by a node pretending
to be a router. The Potential Router List (PRL) provides a list of IPv4
addresses representing ISATAP interfaces of routers that hosts use
in filtering decisions. Site administrators should ensure that the PRL
is kept up to date, and that the resolution mechanism (see: section 9)
cannot be subverted.
The use of temporary addresses [RFC3041] and Cryptographically
Generated Addresses [CGA] on ISATAP interfaces is outside the
scope of this specification.
Resolution: Accepted
Issue 14:
Choosing outer header IPv4 destination address
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
Section 7:
The draft refers to [mech] for the basic tunneling
mech including outer IP header construction, but in principle
the Isatap draft doesn't say anything about
how the outer header IPv4 destination address is chosen.
Shouldn't there be a section about encapsulation like
in the early Isatap drafts, e.g v12,
specifying something like:
Encapsulation (from section 6.2 of v12)
The specifications in [mech] section 3 are used.
Additionally, the IPv6 next-hop address for packets encapsulated on
an ISATAP link MUST be an ISATAP address; other packets are discarded
and an ICMPv6 destination unreachable indication with code 3 (Address
Unreachable) is returned to the source.
[4/26/04 Update (from Fred Templin)]:
The above text first appeared in the -03 version of the spec under
an obsoleted section called: "Sending Rules".
The IPv4 address of the tunnel endpoint is determined from
the Isatap interface identifier of the next-hop address.
[4/26/04 Update (from Fred Templin)]:
The current version of the spec now has sections called "Automatic Tunneling"
and "Neighbor Discovery" that mirror the structure of ([MECH], section 3) and
[RFC2461], respectively. Proposal is to add two new subsections under
"Automatic Tunneling" as follows:
"7.2 Encapsulation
ISATAP interfaces encapsulate IPv6 packets for which the next-hop
address is an ISATAP address.
7.3 IPv4 Header Construction
ISATAP interfaces use static address resolution (see: section 8.4) on the
next-hop address to determine the IPv4 address of the tunnel endpoint."
[4/27/04 Update (from authors' conference call)]:
Upon further consideration, we are proposing no change to the draft.
As for any other interface type, the link layer address is taken from
the result of address resolution. For ISATAP, address resolution is
specified in section 8.4.
[5/05/04 Update (from Karen Nielsen)]:
OK - though
"4/27/04 Update (from authors' conference call)]:
Upon further consideration, we are proposing no change to the draft.
As for any other interface type, the link layer address is taken from
the result of address resolution. For ISATAP, address resolution is
specified in section 8.4."
Here link-layer address refer to what in [MECH], section 3,
is called IPv4 address of tunnel endpoint. [MECH] do not refer to the tunnel endpoint
address as the link layer address of the IP next hop but do explicitly say that the tunnel
endpoint address is something that is configured and stored on each individual tunnel interface.
[5/10/04 Update (from Fred Templin)]:
A new section 6 subsection on "Address Mapping -- Unicast/Anycast" could
be added, and the current section 8.4 (first paragraph) could be shortened.
Proposed text follows:
+ 6.x Address Mapping -- Unicast/Anycast
+
+ For unicast/anycast packets sent on ISATAP interfaces, the next-hop
+ address ([RFC2461], section 5.2) MUST be an ISATAP address.
+
+ ISATAP addresses are mapped to a link-layer address by a static
+ computation, i.e, the last four octets are treated as an IPv4 address
+ to be used as the destination address in the encapsulating IPv4+ header (see section 7).
...
+ 8.4 Address Resolution
+
+ The specification in ([RFC2461], section 7.2) is used.+
+ Hosts SHOULD perform an initial reachability confirmation by sending
+ Neighbor Solicitation message(s) and receiving a Neighbor
+ Advertisement message. Routers MAY perform this initial reachability
+ confirmation, but this might not scale in all environments.
[5/11/04 Update (from authors' conference call)]:
We believe that a more natural point in the document to discuss this issue
could be in an "encapsulation" section in section 7 of the document. (This
could be done in 1-2 sentences.) There was no consensus whether a
change is necessary.
[5/11/04 Update (from Mohit Talwar -seconded by co-authors)]:
Proposes moving the text that specifies address mapping from the current
section 8.4 to a new subsection in section 7 on "Encapsulation". Also, move
second paragraph in section 8.4 to end of current section 8.5 and delete
section 8.4. Proposed text follows:
+ 7.x Encapsulation
+
+ ISATAP addresses are mapped to a link-layer address by a static
+ computation, i.e, the last four octets are treated as an IPv4 address.+
+ ...
+
+ 8.4 Neighbor Unreachability Detection
+
+ Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], section 7.3).
+ Routers MAY perform neighbor unreachability detection, but this might not scale in all
+ environments.
+
+ After address resolution, hosts SHOULD perform an initial reachability confirmation
+ by sending Neighbor Solicitation message(s) and receiving a Neighbor Advertisement
+ message. Routers MAY perform this initial reachability confirmation, but this might
+ not scale in all environments.
[5/26/04 Update (from Fred Templin)]:
Updated resolution status from "Text Proposed" to "Accepted".
Resolution: Accepted
Issue 15: PRLs
only maintained on host interfaces
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Section 7.2:
Perhaps is should here be clarified that the PRLs only
are maintained on host interfaces and as such this check does not
apply to router interfaces.
[4/26/04 Update (from Fred Templin)]:
For any ISATAP interface that does not configure a PRL, the 2nd check
in section 7.2 is a NO-OP, so no clarification needed in section 7.2.
Further, it may be worthwhile to specify the following additional
decapsulation check for Isatap host interfaces:
- destination address should be an Isatap Address.
[4/26/04 Update (from Fred Templin)]:
Obviated by the current text of section 7.2. For further clarification, the
final sentence of that section could add a phrase about whether a packet
"belongs to" an ISATAP interface, e.g.:
"Packets for which the IPv4 source address is incorrect for this ISATAP
interface (or, that do not belong to this ISATAP interface) are checked
to determine whether they belong to another tunnel interface."
[4/27/04 Update (from authors' conference call)]:
We are not convinced that any change is necessary; the
current text of section 7.2 is sufficient.
[5/05/04 Update (from Karen Nielsen)]:
OK.
[5/07/04 Update (from Fred Templin)]:
Resolution updated from "Possible Reject" to "Reject".
Resolution: Reject
Issue 16:
Multicast emulation and DAD, Unsolicited RAs
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 2
Section:
Rationale/Explanation of issue:
Section 8 general:
I miss a section stating that
multicast emulation isn't considered and that DAD
shouldn't be performed as part of address autoconfiguration.
[4/26/04 Update (from Fred Templin)]:
Beginning in the -11 version of the spec, there was a subsection on
DAD that was subsequently removed; this could be added back
under "Addressing Requirements" section 6.3 as:
"6.3 Duplicate Address Detection
Duplicate Address Detection ([RFC2462], section 5.4) is not required for
ISATAP addresses, since duplicate address detection is assumed already
performed for the IPv4 addresses from which they derive."
[4/27/04 Update (from authors' conference call)]:
There is existing precedence in NBMA specs (i.e., RFC3056) for
remaining silent on DAD. The above text could be added back if
we were to revise the spec, but given the existing precedent we
don't see the need.
[5/05/04 Update (from Karen Nielsen)]:
So you don't want to say anything about how
address auto configuration is done on Isatap host interfaces except for
how the link-local address and the link identifier is constructed - ??
[5/10/04 Update (from Fred Templin)]:
Could specify a limited set of multicast mappings, including the manner in
which the Solicited-node Multicast address in Neighbor Solicitation messages
is mapped and example mappings for multicast addresses of on-link routers,
servers and relays.
A new section 6 subsection on "Address Mapping -- Multicast" could be
added. Proposed text follows:
+ 6.x Address Mapping -- Multicast
+
+ For multicast packets sent on ISATAP interfaces:
+
+ - for Neighbor Solicitation messages ([RFC2461], section 4.3)
+ with an ISATAP address in the Target Address and a Solicited-
+ Node Multicast ([RFC3513], section 2.7.1) destination address,
+ the link-layer address is determined as for unicast address
+ mapping on the Target Address.
+
+ - for packets with multicast destination addresses that target+ on-link routers, servers, or relays, e.g., the link-local scope
+ All Routers Multicast address ([RFC3513], section 2.7.1),
+ the All-DHCP_Relay_Agents_and_Servers address
+ ([RFC3313], section 5.1), etc., the link-layer address is
+ taken from V4ADDR(i) for some PRL(i) (see: section 8.1). The+ manner of selecting PRL(i) is up to the implementation.
+
+ - other multicast mappings (and mechanisms for generalized+ multicast emulation) are out of scope.
[5/11/04 Update (from authors' conference call)]:
We believe in remaining silent on multicast, as for 6to4. A separate
future document on "ISATAP multicast" could cover this.
Resolution: Reject
Issue 17: Unsolicited RAs
on ISATAP interfaces
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 2
Section:
Rationale/Explanation of issue:
Section 8.2:
"Unsolicited Router Advertisements are not sent on Isatap interfaces"
could be added for clarity.
[4/26/04 Update (from Fred Templin)]:
Mandating that advertising ISATAP interfaces of routers SHOULD/MUST
NOT send unsolicited Router Advertisements could allow the receipt of
Router Advertisements to serve as "hints of forward progress" for
Reachability Confirmation ([RFC2461], section 7.3.1).
[4/27/04 Update (from authors' conference call)]:
We have the existing precedent for remaining silent on unsolicited
RAs from RFC3056.
[5/05/04 Update (from Karen Nielsen)]:
OK - Though
The only mentioning of RA/RSs in 3056 was to refer to
a section of RFC2893 (now deprecated) which stated explicitly that
no aspects of ND (except for link-local addresses) should apply to
6to4 interfaces (as uni-directional automatic tunnel interfaces).
I don't get the precedence.
Isatap seems to have no need for unsolicited RAs and the security situation
as well as the reachability situation may be easier without them, but this
is a small issue and certainly not worth a fight.
[5/05/04 Update (from authors' conference call)]:
We don't see sufficient reason for any change in this.
Resolution: Reject
Issue 18:
Mechanisms for PRL population
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Section 8.3.2:
Perhaps it would be worthwhile to specify one (or several)
MUST be supported mechanism(s) for PRL population.
A standard FQDN identifier to use for DNS record lookups
should be specified, e.g., "isatap.<domain_name>", where
<domain_name> is the DNS suffix configured on the underlying
IPv4 interface.
[4/26/04 Update (from Fred Templin)]:
Beginning in version -04 of the spec, there was similar text on
determining the FQDN for PRL resolution. See: section 5.2.1 of:
http://www.geocities.com/osprey67/isatap/isatap-04.txt
Alternate proposal could be to add a phrase to the end of the
second sentence of the current section 8.3.2 such as:
"FQDNs are established via manual configuration or an unspecified
alternate method, but the convention "isatap.domainname", where
"domainname" is the DNS suffix configured on the underlying IPv4
interface, SHOULD be supported."
[4/27/04 Update (from authors' conference call)]:
Text similar to that proposed appeared in earlier versions of the spec,
however the working group could not agree on any mandatory mechanisms.
See: Section 9 for best current practice recommendations for site administrators.
[5/05/04 Update (from Karen Nielsen)]:
How about specifying some possibly (if not mandated) mechanisms in detail then ??
[5/1/04 Update (from authors' conference call)]:
Please see our response from 4/27/04. We believe that it would be
difficult to gain consensus on any additional details for even optional
mechanisms.
Resolution: Reject
Issue 19:
Validity check for RAs
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Section 8.3.3:
The following check should also be applied to RAs:
- the ipv6 source address is an
Isatap address that embeds the Ipv4 source address
in its interface identifier.
(this is not ensured by the "or'ed" rules in 7.2).
[4/26/04 Update (from Fred Templin)]:
The validity checks for RAs are performed at layer 3, but the IPv4
source address is discarded during decapsulation at layer 2.5 and therefore
not available to satisfy the proposed check. As long as the PRL(i) always
uses an ISATAP address that embeds V4ADDR(i) as the IPv6 source,
the "or'ed" rules for decapsulation in section 7.2 are already sufficient to
filter illegal RAs.
[4/27/04 Update (from authors' conference call)]:
We believe that security considerations adequately covers ip-protocol-41
filtering such that no further specification is needed.
[5/05/04 Update (from Karen Nielsen)]:
OK - It is however not true, as stated, that the PRL check is sufficient
to filter out illegal RAs. But you may say that if you trust the PRL, then you trust
it also not to send bogus RAs. For future security considerations perhaps.
[5/05/04 Update (from authors' conference call)]:
We agree with the above statement (as also stated in our 4/27/04 update)
and that this could go in a future security considerations document.
Resolution: Reject
Issue 20:
Address Resolution and NUD
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Section 8.4:
From a security perspective
as well as from an implementation perspective
I would like to see this section strengthened a bit
along the following lines:
IPv6 Address resolution on Isatap interfaces consists of two steps:
- Link-layer address resolution
- IPv6 address reachability confirmation
Link-layer address resolution on Isatap interfaces
is performed by static computation from the Isatap Interface identifier
of the next-hop Isatap address.
[4/26/04 Update (from Fred Templin)]:
Already covered under section 8.4.
[4/29/04 Update (from authors' conference call)]:
No change needed.
Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
* Link-layer address must correspond to the Ipv4 address embedded within
the Isatap interface identifier of the neighbor address.
[4/26/04 Update (from Fred Templin)]:
Same as for issue #22; see the proposed resolution under issue #22.
[4/29/04 Update (from authors' conference call)]:
No change needed.
IPv6 address reachability confirmation is performed by sending
unicast Neighbor Solicitation
messages and receiving a Neighbor Advertisment message.
[4/26/04 Update (from Fred Templin)]:
Already covered under section 8.4.
[4/29/04 Update (from authors' conference call)]:
No change needed.
During address resolution then a neighbor entry is considered
in INCOMPLETE state until Reachability Confirmation in form
of a solicited Neighbor Advertisement has been received.
[4/26/04 Update (from Fred Templin)]:
It doesn't seem that there is a need to define specific state
transitions for neighbor cache entries on ISATAP interfaces.
As long as an implementation is consistent with how it handles
NUD on ISATAP interfaces, there should be no interoperability
issues and, hence, no need for state handling specifications.
[4/29/04 Update (from authors' conference call)]:
Agree with 4/26/04 update, i.e., no change needed.
For security and scalability reasons the
IPv6 address reachability Confirmation step SHOULD be omitted
on Router Interfaces.
[[FOR DISCUSSION: This behavior could be configurable on Router interfaces.
in trusted environments it could be useful to have NUD on the router also.
Default should be not to perform the reachability step]]
[4/26/04 Update (from Fred Templin)]:
A possible clarification could be to change the last sentence of section 8.4 to:
"Routers MAY perform this initial reachability confirmation, but this might
not be secure and scalable in all environments."
[4/29/04 Update (from authors' conference call)]:
We believe that the current text of 8.4 and 8.5 adequately address the issue.
Host SHOULD perform the IPv6 address reachability step when performing
address resolution.
If the IPv6 address reachability step is omitted, NUD will not succeed.
[4/26/04 Update (from Fred Templin)]:
Whether/not the initial reachability confirmation is performed, the -21
spec uses the specification from ([MECH], section 3.8) that says: "nodes
MUST accept and respond to the probe packets used by NUD (sic)".
Therefore, we have the necessary mechanism to support NUD.
[4/29/04 Update (from authors' conference call)]:
We don't believe there is anything in this that would necessitate a
change to the spec.
[5/05/04 Update (from Karen Nielsen)]:
The reference to [MECH] wrt NUD doesn't apply
since the bidirectional tunnels
of [MECH] support multicast and the Isatap tunnels doesn't.
[5/11/04 Update (from authors' conference call)]:
We agree that the wording of ([RFC2893], section 3.8) is confusing.
But, ISATAP interfaces take as normative reference all of RFC2893(bis),
section 3 which provides unambiguous guidance on NUD.
The multicast aspect of the comment is irrelevant, since NUD does
not use multicast.
Resolution: Reject
Issue 21:
SENDPS Implications for ISATAP
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Section 10:
You may wish to take the following observations into consideration:
[4/26/04 Update (from Fred Templin)]:
The suggestions below appear to be the makings of a new document
on "Security Considerations for ISATAP", i.e., similar to:
www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt
See below for specific comments:
A number of the threats described in [SENDPS] on Isatap ND are
non-applicable to and/or easily preventable, Indeed:
4.1.1. Non-applicable given the above mentioned validity check
on neighbor cache entries - that is:
Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
* Link-layer address must correspond to the Ipv4 address embedded within
the Isatap interface identifier of the neighbor address.
[4/26/04 Update (from Fred Templin)]:
Same as for proposed resolution of issue #22.
[4/29/04 Update (from authors' conference call)]:
See our response to this in issue #20 and #22..
4.1.3: Non-applicable if DAD is omitted
4.2.1: Non-applicable given that a trust worthy PRL population
mechanism is deployed.
4.2.2:
Threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.
That is, host-to-host only scenario not considered.
[4/26/04 Update (from Fred Templin)]:
Suggestions look reasonable, but for base specification or seperate
"Security Considerations for ISATAP" document?
[4/29/04 Update (from authors' conference call)]:
We agree with points 4.1.3 and 4.2.1, but we believe that better
mitigations exist for 4.2.2.
4.2.3:
Limited to the time in between successive refreshments of the PRL
given that a trust worthy PRL population
mechanism is deployed.
4.2.4
One may want to consider eliminating 4.2.4 of [SENDPS] simply
(and boldly) by disallowing the redirect functionality on Isatap interfaces.
[4/26/04 Update (from Fred Templin)]:
Suggestion looks reasonable, but for base specification or seperate
"Security Considerations for ISATAP" document?
[4/29/04 Update (from authors' conference call)]:
We don't believe this issue is necessarily different than the
situation of malicious last-hop router.
The risk of not supporting the redirect functionality is very small;
The Redirect function is generally used to:
§ Inform Isatap hosts of destinations with Isatap prefixes
that are directly reachable by ISATAP tunneling from the IPv4 site of the Isatap host.
§ Redirect Isatap hosts to a better first-hop on-link Isatap router for a specific destination
However, in the first situation above, a correct functioning Isatap host
will learn of the on-link ISATAP prefixes from the RS/RA exchange performed
periodically with all routers from its, also periodically updated, PRL list,
and hence only a limited amount of time can elapse before it would correct its behavior.
The second situation is probably not relevant for ISATAP scenarios given that
router-to-router tunneling isn't supported. Indeed it is our experience that
routers typically only send Redirect messages indicating better
first-hop router if the egress interface towards this better
first-hop router for the packet in question is the same as
the ingress that it received the packet on. In ISATAP scenarios,
the ingress interface would be an ISATAP interface and
such an interface cannot be used for Router-to-Router forwarding.
4.3.2:
Non-applicable if the Ipv6 address reachability step of
address resolution isn't implemented on Isatap router interfaces.
Security threats on Isatap ND in secured corporate intranet/enterprises :
------------------------------------------------------------------------
Given that 4.2.2 and 4.2.4 are prevented by specifying a particular behavior
on Isatap interfaces (as indicated right above). Then in accordance with
the table in section 4.4. of [SENDPS] only 4.3.1 remain a real concern
in this environment. This is for further investigation.
Security threats on Isatap ND in IPv4 source proof and protocol-41 perimeter guarded sites:
-------------------------------------------------------------------------------------------
The additional security treats associated with IPv6 neighbor discovery
described in [SENDPS] for the most part are non-applicable or
can be prevented by simple measures to
Isatap host and routers in sites that are
guarded against ip-protocol-41 at the perimeter
and for which IPv4 source spoofing isn't possible.
A prime example of an IPv4 source proof and protocol-41 perimeter guarded site
is the network a mobile operator where the GGSN have
activated IPv4 address spoofing protection
and which in addition implement ip-protocol-41 filtering at the edges.
Note that IPv4 source address proof and ip-protocol-41
site perimeter filtering together with the Isatap decapsulation rules
effectively establish source proofing on IPv6 Isatap addresses.
The following refer to the threats described in [SENDPS]:
4.1.2: Given Ipv4 source address proof,
this attack may be prevented by requirering the following validity check
to be applied to received NA messages on Isatap interfaces:
In addition to the validity checks given in RFC 2461 a NA message must
pass the following validity check:
* the IPv6 address in the target field must
be an Isatap address which embeds the v4 source address.
However it should be noted that this check will disallow ND proxy functionality
on Isatap sites, whether that's undesirable is not clear to me.
(one implication of course would be that the MIpv6 HA service cannot be provided
on Isatap sites but one would never want to do that anyway I think).
4.2.5+4.2.6+4.2.7:
Non-applicable given IPv4 source address spoofing prevention
if trustworthy PRL population mechanism is deployed.
4.2.2:
Spoofed RA message with zero-lifetime is not applicable.
As mentioned above this threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.
[4/26/04 Update (from Fred Templin)]:
For base specification, or for separate "Security Considerations
for ISATAP" document?
[4/29/04 Update (from authors' conference call)]:
See earlier response to 4.2.2.
4.2.3:
Limited to the time in between successive refreshments of the PRL
for the same reasons as 4.2.1.
In addition then compromising the Isatap router itself
is a doubtful scenario in carefully managed networks
such as e.g. 3GPP/3GPP2 and enterprise networks.
4.2.4:
Is limited by Ipv4 source address spoofing prevention.
In addition then compromising the Isatap router itself
is a doubtful scenario in 3GPP/3GPP2 and enterprise networks
May be prevented altogether by disallowing the redirect
functionality on Isatap interfaces as mentioned above.
4.3.1:
Non-applicable by Ipv4 source address spoofing prevention.
[4/29/04 Update (from authors' conference call)]:
The above discussion provides useful and good analysis. We have gone through
the points, and believe that many are valid and could be made into a separate
document on ISATAP security. We believe that the base spec already provides
sufficient guidance for implementers and site administrators.
[5/05/04 Update (from Karen Nielsen)]:
OK - for future security considerations perhaps.
[5/07/04 Update (from Fred Templin)]:
Resolution updated from "Possible Reject" to "Reject".
Resolution: Reject
Issue 22:
Neighbor Cache Entries for ISATAP interfaces
Submitter: Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
I've some problem with section 8:
...
8. Neighbor Discovery for ISATAP Interfaces
ISATAP nodes use the neighbor discovery mechanisms specified in
[RFC2461] to create/change neighbor cache entries. ISATAP interfaces
also implement the following specifications:
...
I don't see how a neighbor cache entries would get created. You cannot
run normal RFC2461 neighbor discovery on ISATAP interface to detect
link layer addresses: ISATAP interface does not support multicast!
I think all references to neighbor cache could be removed (there is no
need for link layer addresses). Like, in section 8.4
[4/27/04 Update (from Fred Templin)]:
Proposal is to change first two sentences of section 8 to:
"ISATAP nodes use the mechanisms in [RFC2461] that apply
to NBMA interfaces and also implement the following specifications."
[4/27/04 Update (from authors' conference call)]:
The conceptual sending algorithm in (RFC2461, section 5.2) applies
equally to ISATAP interfaces. This includes creating/changing neighbor
cache entries.
...
8.4 Address Resolution
The specification in ([RFC2461], section 7.2) is used. ISATAP
addresses for which the neighbor's link-layer address cannot
otherwise be determined (e.g., from a neighbor cache entry) are
resolved to link-layer addresses by a static computation, i.e., the
last four octets are treated as an IPv4 address.
...
Change above just into
...
8.4 Address Resolution
ISATAP addresses are resolved to link-layer addresses by a static
computation, i.e., the last four octets are treated as an IPv4
address.
[4/26/04 Update (from Fred Templin)]:
The text in question is a known artifact that was scheduled for
removal prior to publication of -21.
[4/27/04 Update (from authors' conference call)]:
We believe the text is correct either way, with slight preference
toward Markku's suggestion.
...
A corollary to above is: ISATAP IPv6 "nexthop address" is always based
on one of the PRL addresses.
[4/26/04 Update (from Fred Templin)]:
Not necessarily correct; this doesn't belong in the spec.
[4/27/04 Update (from authors' conference call)]:
We disagree with the statement.
[5/05/04 Update (from Markku Savela)]:
For 22-23, I still don't agree with the conclusion:
[4/27/04 Update (from authors' conference call)]:
The conceptual sending algorithm in (RFC2461, section 5.2) applies
equally to ISATAP interfaces. This includes creating/changing
neighbor cache entries.
If you check RFC2461 5.2...
...
Once the IP address of the next-hop node is known, the sender
examines the Neighbor Cache for link-layer information about that
neighbor. If no entry exists, the sender creates one, sets its state to
INCOMPLETE, initiates Address Resolution, and then queues the data
packet pending completion of address resolution. For multicast-
capable interfaces Address Resolution consists of sending a Neighbor
Solicitation message and waiting for a Neighbor Advertisement. ...
...
Yes, NCE is created, but in INCOMPLETE state. And, in ISATAP draft,
there is nothing to advice how it will change from that state. RFC2461
specifies that only for multicast capable links.
Referencing NBMA RFC2491 is no help. It again relies on MARS (RFC2022)
for ND. This seems like a huge overkill for ISATAP. A simpler solution
would be better.
For example, the problem might be simply solved by stating:
On ISATAP interface, NCE entry created by RFC2461 5.2 process into
INCOMPLETE state is implicitly set to REACHABLE state.
[5/05/04 Update (from Dave Thaler)]:
That is the intended behavior yes. This is no different from any other
interface that uses algorithmic mappings, such as 6to4.
[5/05/04 Update (from Markku Savela)]:
However, this is not how standard IPv6 stack would work. This requires
either change in the stack, some special flag for ISATAP type
interface, or the ISATAP driver needs to have a way to modify the
state of the neighbor cache in the stack.
[5/05/04 Update (from Dave Thaler)]:
There's nothing ISATAP-specific here. ISATAP is just another
link-layer media in the class of algorithmically-mapped ones.
[5/05/04 Update (from Markku Savela)]:
All I'm trying to say, there is a "gap" in the specification: no
advice how INCOMPLETE magically changes into REACHABLE (and usable
NCE).
[5/05/04 Update (from Dave Thaler)]:
In my opinion, the "gap" would best be filled in a generic spec like
2461bis or 2893bis.
[5/05/04 Update (from Markku Savela)]:
On the other hand, I also question the usefulnes of the NCE entries
for anything else but routers in PRL list. What purpose they serve for
ISATAP?
[5/05/04 Update (from Dave Thaler)]:
Neighbor Unreachability Detection, same as with 6to4.
[5/05/04 Update (from Markku Savela)]:
Why would you talk to neighbors that are reachable directly by
IPv4 through ISATAP?
[5/05/04 Update (from Dave Thaler)]:
Because the application wants to use IPv6, same as with any
transition mechanism.
[5/05/04 Update (from Karen Nielsen)]:
> Neighbor Unreachability Detection, same as with 6to4.
As previously discussed, NUD will not work if static address computation alone
results in an NCE entry in REACHABLE STATE.
I don't believe this is the same for 6to4 interfacesas, NUD is not specified
to be performed on these interfaces.
[5/05/04 Update (from Dave Thaler)]:
> As previously discussed, NUD will not work if static address computation alone
> results in an NCE entry in REACHABLE STATE.
Two responses:
1) yes it does. NUD kicks in after the entry goes to STALE.
2) My mistake when I said creating in REACHABLE was intended (although
as above, NUD isn't broken, it's just delayed). It is better to
create it in the STALE state (immediately moving to PROBE since
you're sending a packet), and in fact this is what the co-authors
had discussed, not creating in REACHABLE.
> I don't believe this is the same for 6to4 interfacesas, NUD is not specified
> to be performed on these interfaces.
Yes it is. See section 3.1 of RFC 3056 (6to4).
5/05/04 Update (from Karen Nielsen)]:
> Two responses:
> 1) yes it does. NUD kicks in after the entry goes to STALE.
> 2) My mistake when I said creating in REACHABLE was intended (although
> as above, NUD isn't broken, it's just delayed). It is better to
> create it in the STALE state (immediately moving to PROBE since
> you're sending a packet), and in fact this is what the co-authors
> had discussed, not creating in REACHABLE.
I agree that the NUD algorithm kicks in,
but I believe that it will have no effect unless
the reachability of the peer is
confirmed as part of the address
resolution step - even in STALE, DELAY, PROBE packets are send,
only in INCOMPLETE they are not.
If the peer isn't reachable then yes
NUD will ensure that the NCE at some point is deleted
which merely means that static address resoltion will be performed anew
when the next packet arrives, a NCE will be created in STALE/REACHABLE
and we can start the NUD cycle once more while we continuosly are transmitting packets.
This regardless of whether the NCE initially is put in REACHABLE or
in STALE state.
Or - what am I missing ?
> > I don't believe this is the same for 6to4 interfacesas, NUD is not
> > specified
> > to be performed on these interfaces.
>
> Yes it is. See section 3.1 of RFC 3056 (6to4).
Which refers to 2893 which says that NUD does not apply to
unidirectional automatic tunnels - but only to bidirectional configured
tunnels which 6to4 explicitly is said not to be - ?
BTW - exactly this reference of 3056 to 2893 has aways puzzled me - if would
have been easier simply to state that ND didn't apply than
to refer to another document which says just that.
Which again may mean that I am reading it wrong as you seem to think.
[5/11/04 Update (from authors' conference call)]:
We agree that the wording of ([RFC2893], section 3.8) is confusing.
But, ISATAP interfaces take as normative reference all of RFC2893(bis),
section 3 which provides unambiguous guidance on NUD.
[5/11/04 Update (from Tim Gleeson)]:
I think issue #22 has several subpoints that we should pull out, including
at least:
A) Can NCE's ever get created?
B) What state should an NCE start in? If not INCOMPLETE, in what doc should
the initial state be specified?
C) What use are NCE's? Are NCE's effective for NUD?
D) If we want NUD, is it implicitly/explicitly specified and if so, where?
E) Address resolution specification, notably multicast addresses
[5/11/04 Update (from Fred Templin)]:
> A) Can NCE's ever get created?
Yes it can; a NCE can get created:
1) In the INCOMPLETE state when sending a first packet to a neighbor
via address resolution as for ordinary multicast-capable interfaces. (ISATAP
interfaces can support a *limited* multicast capability, including a means for
mapping the Solicited Node Multicast address to a Link layer address.
Thus, they can perform "Address Resolution emulation".)
2) In the STALE state when sending a first packet to a neighbor if the
implementation has a way of performing this "specialized" step for ISATAP
interfaces. This could be done via a special case statement in the IP layer,
in the ISATAP link-layer driver, etc.
3) In the STALE state upon receipt of a NS, RS, RA, or Redirect.
> B) What state should an NCE start in?
Implementations can use "Address Resolution emulation", i.e., create a NCE in
the INCOMPLETE state, send a NS to the Solicited Node Multicast address
of the neighbor tunneled to the unicast IPv4 address of the neighbor, and keep
a short queue of data packets while waiting for an NA response.
An alternate approach would be to create the NCE in the STALE state and
immediately send data packets to the known link-layer address of the neighbor,
since subsequent reachability confirmation from the neighbor (and/or going to
the DELAY/PROBE states, sending unicast NSs and getting an NA back)
will quickly cause the NCE to go to the REACHABLE state. This would
be more efficient than the Address Resolution emulation method.
The problem with the alternate approach occurs when a neighbor is
unreachable but the original source continues to send. In that case, the
NCE will be created, cycle through the states, and be deleted indefinitely.
Coupling this "create-in-STALE-state" method with an initial unicast NS/NA
exchange provides timely reachability confirmation (if the neighbor is indeed
reachable), but will still cycle through the states with no feedback to the
original source if the path to the neighbor subsequently fails. In short, since
the create-in-STALE-state method does not keep a queue of data packets
pending reachability confirmation, a different method (e.g., link-specific
information that a path to a neighbor has failed) is needed to return ICMP
feedback to the original source.
> If not INCOMPLETE, in what doc should
> the initial state be specified?
Does not seem like material for the base specification - rather for an "NBMA
implementor's guide" document (sic). Such a document could be an IETF
informational/BCP category submission, or could just be a whitepaper on
a well-know www page (such as the current document).
> C) What use are NCE's?
In the Address Resolution emulation method, to detect when a path to a
neighbor is failing or has failed and send ICMP feedback to the original
source based on a queue of pending packets, as for any IPv6 interface
over which ND applies. In the create-in-STALE-state method, possibly
no use, since the only path failure feedback to the original source would
come from link-specific information, i.e., since no queue of pending packets
is kept. But, in this case, there would not seem to be a need for NUD
anyway.
> Are NCE's effective for NUD?
For the Address Resolution emulation method - yes.
For the create-in-STALE-state method - possibly not.
> D) If we want NUD, is it implicitly/explicitly specified and if so, where?
If Address Resolution emulation method is used, NUD is performed exactly
as in RFC2461, section 7.3 assuming the Solicited Node Multicast address
in a Neighbor Solicitation is mapped to a unicast link-layer (IPv4) addresses.
> E) Address resolution specification, notably multicast addresses
See issue 16.
[5/11/04 Update (from authors' conference call)]:
> A) Can NCE's ever get created?
Up to the implementation.
> B) What state should an NCE start in? If not INCOMPLETE, in what doc should
> the initial state be specified?
We suggest starting in the STALE state. But, since this is not specific
to ISATAP (and, since ISATAP does not require NCEs), we suggest
that this go in RFC2461(bis) or a future document discussing the class
of interface that use static mapping for address resolution.
> C) What use are NCE's? Are NCE's effective for NUD?
A naive implementation of RFC2461 will spin through the NCE states and
be ineffective, but implementations can use, e.g., negative cache entries
for effective NUD on such interfaces.
> D) If we want NUD, is it implicitly/explicitly specified and if so, where?
No change for the ISATAP spec in this regard.
> E) Address resolution specification, notably multicast addresses
See issue 16.
[5/11/04 Update (from authors' conference call)]:
We agree that references to the neighbor cache entries could
be removed, since NCE's are an implementation mechanism.
(RFC3056 took the same approach.)
[5/26/04 Update (from Fred Templin)]:
Updated resolution status from "Text Proposed" to "Accepted".
Resolution: Accepted
Issue 23: Type
of IPv6 interface in ISATAP interface definition
Submitter: Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first submitted:
April 20, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 2
Section:
Rationale/Explanation of issue:
I was hoping that the ISATAP interface would look like standard IPv6
interface to the stack. The above procedure is not what stack would do
on any interface. The currently defined choices for "standard" IPv6
interfaces are:
1) Point-to-point (no addresses on the link)
2) "Ethernet type", link layer addresses, RFC2461 style neighbor
discovery (which relies on multicast).
[4/27/04 Update (from authors' conference call)]:
The correct RFC2461-specified interface type for ISATAP is
"non-broadcast multi-access (NBMA)". This could be clarified under
"Terminology" by changing "point-to-multipoint" to "non-broadcast
multi-access (NBMA)" under the ISATAP interface definition, but
we don't see this as necessary.
[5/11/04 Update (from authors' conference call)]:
We agree that this could be changed as per 4/27/04 update.
[5/26/04 Update (from Fred Templin)]:
Updated resolution status from "Text Proposed" to "Accepted".
Resolution: Accepted
Issue 24:
Splitting the PRL into Ingress and Egress Lists
Submitter: Fred L. Templin
Submitter email address: fred.templin@nokia.com
Date first submitted:
April 27, 2004
Reference:
Document: isatap-21.txt
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The PRL gives the IPv4 addresses of on-link routers. The definition for
"ISATAP link" needs to be clearly understood before the PRL can be
clearly understood:
- from the perspective of a host that sends packets to the next-hop on an
ISATAP interface, the extent of the ISATAP link depends on the first NAT
(if any) along the path toward the final destination that would modify the IPv4
destination. In other words, from the perspective of a node sending packets
on an ISATAP interface, the first NAT that would modify the IPv4 destination
occurs in the same topological location as the next-hop router at the egress
edge of the ISATAP link.
- from the perspective of a host that receives packets from a last-hop on an
ISATAP interface, the extent of the ISATAP link depends on the final NAT
(if any) that would modify the IPv4 destination before the packet is delivered to
the host. In other words, from the perspective of a node receiving packets on an
ISATAP interface, the final NAT that would modify the IPv4 destination before
the packet is delivered to the host occurs in the same topological location as the
last-hop router at the ingress edge of the ISATAP link.
The extent of the ISATAP link is therefore asymmetric based on ingress vs. egress
directions. The current Potential Routers List definition should be clarified to explain that
it applies ONLY to the egress path, and a new list: "Ingress Router List (IRL)" should be
added. The text of section 7.2 (decapsulation) should be changed to deal with the IRL
only, and the text of section 8.3 should be changed to deal with both lists. Change
suggestions are:
1) In section 7.2, change the second "or'd" rule to:
- the IPv4 source address is a member of the Ingress Router List (IRL)
(see section 8.1).
2) Change section 8.1 to read:
"8.1 Conceptual Model of a Host
To the list of Conceptual Data Structures ([RFC2461], section 5.1),
ISATAP interfaces add:
Potential Router List (PRL)
A set of entries about egress routers; used to support router and
prefix discovery. Each entry ("PRL(i)") has an associated timer
("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that represents
an egress router's advertising ISATAP interface.
Ingress Rotuer List (IRL)
A list of IPv4 addresses about ingress routers; used for ingress
filtering during decapsulation (see: section 7.2). Each IPv4 address
represents an ingress router's forwarding ISATAP interface.
3) In section 8.3.2, first sentence, change the phrase: "a DNS fully-
qualified domain name (FQDN)" to: "DNS fully-qualified domain
names (FQDNs)".
4) Add a new section (section 8.3.3) on Ingress Router List Initialization:
"8.3.3 Ingress Router List Initialization
ISATAP nodes initialize an ISATAP interface's IRL with IPv4 addresses
discovered based on their detection of IPv4 network attachment. For ISATAP
interfaces that configure a locator set comprising global IPv4 addresses, the
IRL is initialized to the list of all global IPv4 addresses excluding the node's
own address(es). For ISATAP interfaces that configure a locator set comprising
private addresses, the IRL is initialized as for PRL initialization (see: section
8.3.2). When an FQDN is used, the convention "isatap.domainname",
where "domainname" is the DNS suffix discovered during detection of
IPv4 network attachment, SHOULD be supported.
.
After initializing an ISATAP interface's IRL, the node re-initializes the list
as for reinitialization of the PRL. The node also re-initialized the list when
when its the IPv4 network attachment changes, e.g., when the node moves
to a new site, etc."
5) In section 10, change the 4th paragraph into *two* paragraphs as follows:
"Another possible spoofing attack involves spurious ip-protocol-41
packets injected from within an ISATAP link by a node pretending
to be a router. The Ingress Router List (IRL) provides a list of IPv4
addresses representing forwarding ISATAP interfaces of ingress
routers that hosts use for ingress filtering.
The Potential Router List (PRL) provides a list of IPv4 addresses
representing advertising ISATAP interfaces of egress routers that
hosts use for router and prefix discovery. Site administrators
should ensure that the PRL is kept up to date, and that the
resolution mechanism (see: section 9) cannot be subverted."
NOTE: With the above changes 1) thru 5), the document could do
a global change of "potential router list" to "egress router list" for
greater clarity (optional).
[4/27/04 Update (from authors' conference call)]:
While it is possible to describe the PRL as comprising separable ingress
and egress components, this is not necessary for documenting the widely-
deployed implementations. Also, current practices have the ingress and
egress router functions combined in a single box (i.e., not "split" with an
IPv4 network between them), and this is correctly described by the current
PRL text. The suggestions could go as part of a separate document, but
not for the base specification.
Resolution: Reject