Subject: Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 07 Jan 2011 15:49:49 -0500

I do not see how 6rd can be handled.  There is not really any meaningful 
"domain" to use to figure out who is using what 6rd prefix.

And what token does ISATAP use?  I presume that I missed something when 
the only token I could find was in the lower 64 bits (and tehrefore 
could be accidentally duplicated elsewhere.

Thanks,
Joel

On 1/7/2011 3:43 PM, Fred Templin wrote:
> Hi Joel,
>
> Thank you for your time in reviewing this work. In Section 3.1, under
> this proposed
> mitigation the tunnel router ideally indeed must check for all
> encapsulation formats in
> which an IPv4 address may be embedded within an IPv6 address. This means
> that
> the router must check for all known protocol-41 encapsulation formats
> and must be
> modified to check for any new formats should new ones be specified. In
> practice, if
> a router is configured to check only a subset of encapsulation formats,
> then it will be
> immune only to attacks in which the attacker uses the configured
> encapsulation
> formats in the source/destination address of the attack packet.
>
> Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a well-known
> "token" indicating that an IPv4 address is embedded. Other formats
> (e.g., 6rd)
> do not include such a token and hence would require special configuration at
> the router to indicate which IPv6 prefixes within the routing domain are
> 6rd ones.
>
> Do you feel there are any additional clarifications on this needed
> beyond what
> already appears in Section 3.1?
>
> Fred and Gabi
>
> *From:* Joel M. Halpern <[email-masked]>
> *To:* Mary Barnes <[email-masked]>
> *Cc:* [email-masked]; Joel Jaeggli <[email-masked]>; Ron Bonica
> <[email-masked]>; [email-masked];
> IPv6 Operations <[email-masked]>
> *Sent:* Tue, December 28, 2010 1:43:14 PM
> *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-v6ops-tunnel-loops-01.txt
> Routing Loop Attack using IPv6 Automatic Tunnels:
> Problem Statement and Proposed Mitigations
> Reviewer: Joel M. Halpern
> Review Date: 28-Dec-2010
> IETF LC End Date: 29-Dec-2010
> IESG Telechat date: 06-Jan-2011)
>
> Summary: Nearly ready for publication as an Informational RFC
>
> Major issues: It is unclear in the document what assumptions section 3.1
> makes about the relationship between supported tunnels and checked
> embedded addresses. Is there an assumption that the router only has to
> check for addresses in the format and prefix it supports? I hope so.
> Otherwise, a router seems to be expected to look at an arbitrary IPv6
> addresses, guess whether it has an embedded IPv4 addresses, and perform
> filter checks on that guessed addresses against its own addresses.
> If indeed their is a relationship, then it would really help if section
> 3.1 said that.
> Unfortunately, I am afraid no such relationship is assumed. If not, I
> would like to see significantly better explanation of how the router is
> to reliably know that there is a 6rd or ISATAP address embedded in the
> v6 address.
>
> Minor issues:
>
> Nits/editorial comments:

---

From: Fred Templin <[email-masked]>
Date: Fri, 7 Jan 2011 12:43:29 -0800 (PST)

Hi Joel,

Thank you for your time in reviewing this work. In Section 3.1, under this 
proposed
mitigation the tunnel router ideally indeed must check for all encapsulation 
formats in
which an IPv4 address may be embedded within an IPv6 address. This means that
the router must check for all known protocol-41 encapsulation formats and must 
be
modified  to check for any new formats should new ones be specified. In  
practice, if
a router is configured to check only a subset  of encapsulation formats, then it  
will be
immune only to attacks in which the attacker uses the  configured encapsulation
formats in the source/destination address of  the attack packet.

Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a well-known
"token" indicating that an IPv4 address is embedded. Other formats (e.g., 6rd)
do not include such a token and hence would require special configuration at
the router to indicate which IPv6 prefixes within the routing domain are 6rd 
ones.

Do you feel there are any additional clarifications on this needed beyond what
already appears in Section 3.1?

Fred and Gabi

________________________________
From: Joel M. Halpern <[email-masked]>
To: Mary Barnes <[email-masked]>
Cc: [email-masked]; Joel Jaeggli <[email-masked]>; Ron Bonica 
<[email-masked]>; [email-masked]; IPv6 
Operations  <[email-masked]>
Sent: Tue, December 28, 2010 1:43:14 PM
Subject: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Major issues: It is unclear in the document what assumptions section 3.1 makes 
about the relationship between supported tunnels and checked embedded 
addresses.  Is there an assumption that the router only has to check for 
addresses in the format and prefix it supports?  I hope so. Otherwise, a router  
seems to be expected to look at an arbitrary IPv6 addresses, guess whether it 
has an embedded IPv4 addresses, and perform filter checks on that guessed 
addresses against its own addresses.
If indeed their is a relationship, then it would really help if section 3.1 said 
that.
Unfortunately, I am afraid no such relationship is assumed.  If not, I would 
like to see significantly better explanation of how the router is to reliably 
know that there is a 6rd or ISATAP address embedded in the v6 address.

Minor issues:

Nits/editorial comments:

---

From: Fred Templin <[email-masked]>
Date: Fri, 7 Jan 2011 14:19:56 -0800 (PST)

Hi Joel,

In response to your questions below, 6rd can only be handled by explicit
configuration of known 6rd prefixes. As you  indeed mention, there is no
meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed
there is a chance of 2^-32 that a non-ISATAP address  will be recognized
as an ISATAP-address. In this case, an erroneous drop  will occur only if
the lower 32 bits of the IID will be equal to the IP address of the current 
host.
The chance of that happening is 2^-32, if the IID is random. This means that
an erroneous drop will occur with a chance of 2^-64,  which is very slim
(albeit possible).

Fred and Gabi

________________________________
From: Joel M. Halpern <[email-masked]>
To: Fred Templin <[email-masked]>
Cc: Mary Barnes <[email-masked]>; [email-masked]; Joel Jaeggli 
<[email-masked]>; Ron Bonica <[email-masked]>; 
[email-masked]; IPv6 Operations 
<[email-masked]>
Sent: Fri, January 7, 2011 12:49:49 PM
Subject: Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt

Thanks,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 07 Jan 2011 17:44:32 -0500

I am sorry, but what you have just said translates to me as
1) This proposal can not handle 6rd
2) It is a heuristic, with decent odds, for this to avoid false 
positives on other schemes, such as ISATAP, since most of these 
techniques are not designed to allow an arbitrary device elsewhere in 
the net to detect and accurately extract the IPv4 address from the 
embedding.

Russ may decide it is acceptable, but from where I sit this does not 
represent solving the problem.  Advising folks to configure every 6rd 
prefix in use anywhere is simply not acceptable.

Yours,
Joel

On 1/7/2011 5:19 PM, Fred Templin wrote:
> the lower 32 bits of the IID will be equal to the IP address of the
> current host.
> *To:* Fred Templin <[email-masked]>
> *Cc:* Mary Barnes <[email-masked]>; [email-masked]; Joel
> Jaeggli <[email-masked]>; Ron Bonica <[email-masked]>;
> *Sent:* Fri, January 7, 2011 12:49:49 PM
> *Subject:* Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
>
>  > *From:* Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>>
>  > *To:* Mary Barnes <[email-masked]
> <mailto:[email-masked]>>
>  > *Cc:* [email-masked] <mailto:[email-masked]>; Joel Jaeggli
> <[email-masked] <mailto:[email-masked]>>; Ron Bonica
>  > <[email-masked] <mailto:[email-masked]>>;
> [email-masked]
> <mailto:[email-masked]>;
>  > IPv6 Operations <[email-masked] <mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Jan 2011 08:48:59 -0500

Yes, I think that the drawback needs to be stated more clearly and thus 
this choice removed from the recommendations.

Thank you,
Joel

On 1/11/2011 2:01 AM, Gabi Nakibly wrote:
> Hi Joel,
>
> We are in agreement regarding the 6rd issue. Indeed, in practice this specific
> measure can not handle 6rd. We only suggested the configuration option so the
> draft will be complete. Nonetheless, we think that this measure is useful in
> other cases such as ISATAP and especially 6to4. So we think it still has a place
>
> in the draft.
>
> This mitigation measure has some drawbacks which are explicitly described in the
>
> draft. We can make the wording on the 6rd drawback stronger and drop the
> configuration suggestion, if this will make you feel more comfortable.
>
> Gabi
>
>
>
>
> ----- Original Message ----
>> From: Joel M. Halpern<[email-masked]>
>> To: Fred Templin<[email-masked]>
>> Cc: IPv6 Operations<[email-masked]>;
>> [email-masked]; [email-masked]; Mary Barnes
>> <[email-masked]>
>> Sent: Sat, January 8, 2011 12:44:32 AM
>> Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
>>
>>> *From:* Joel M. Halpern<[email-masked]>
>>> *To:* Fred Templin<[email-masked]>
>>> *Cc:* Mary Barnes<[email-masked]>; [email-masked]; Joel
>>> Jaeggli<[email-masked]>; Ron Bonica<[email-masked]>;
>>>    >  *From:* Joel M. Halpern<[email-masked]
>>>    >  *To:* Mary Barnes<[email-masked]
>>>    >  *Cc:* [email-masked]<mailto:[email-masked]>; Joel Jaeggli
>>> <[email-masked]<mailto:[email-masked]>>; Ron Bonica
>>>    >  <[email-masked]<mailto:[email-masked]>>;
>>>    >  IPv6 Operations<[email-masked]<mailto:[email-masked]>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
>
>

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 10 Jan 2011 23:01:06 -0800 (PST)

Hi Joel,

in the draft. 

Gabi

----- Original Message ----
> Cc: IPv6 Operations <[email-masked]>; 
> >  > Hi Joel,
> >  >
> >  > Thank you for your time in reviewing this work. In Section 3.1, under
> >  > this proposed
> >  > mitigation the tunnel router ideally indeed must check for all
> >  > encapsulation formats in
> >  > which an IPv4 address may be embedded within an IPv6 address. This means
> >  > that
> >  > the router must check for all known protocol-41 encapsulation formats
> >  > and must be
> >  > modified to check for any new formats should new ones be specified. In
> >  > practice, if
> >  > a router is configured to check only a subset of encapsulation formats,
> >  > then it will be
> >  > immune only to attacks in which the attacker uses the configured
> >  > encapsulation
> >  > formats in the source/destination address of the attack packet.
> >  >
> >  > Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a
> > well-known
> >  > "token" indicating that an IPv4 address is embedded. Other formats
> >  > (e.g., 6rd)
> >  > do not include such a token and hence would require special
> > configuration at
> >  > the router to indicate which IPv6 prefixes within the routing domain are
> >  > 6rd ones.
> >  >
> >  > Do you feel there are any additional clarifications on this needed
> >  > beyond what
> >  > already appears in Section 3.1?
> >  >
> >  > Fred and Gabi
> >  >
> >  > *From:* Joel M. Halpern <[email-masked]
> >  > *To:* Mary Barnes <[email-masked]
> >  > *Cc:* [email-masked] <mailto:[email-masked]>; Joel Jaeggli
> >  > <[email-masked] <mailto:[email-masked]>>;
> >  > IPv6 Operations <[email-masked] <mailto:[email-masked]>>
> >  > *Sent:* Tue, December 28, 2010 1:43:14 PM
> >  > *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
> >  >
> >  > I am the assigned Gen-ART reviewer for this draft. For background on
> >  > Gen-ART, please see the FAQ at
> >  >
> >  > Please resolve these comments along with any other Last Call comments
> >  > you may receive.
> >  >
> >  > Document: draft-ietf-v6ops-tunnel-loops-01.txt
> >  > Routing Loop Attack using IPv6 Automatic Tunnels:
> >  > Problem Statement and Proposed Mitigations
> >  > Reviewer: Joel M. Halpern
> >  > Review Date: 28-Dec-2010
> >  > IETF LC End Date: 29-Dec-2010
> >  > IESG Telechat date: 06-Jan-2011)
> >  >
> >  > Summary: Nearly ready for publication as an Informational RFC
> >  >
> >  > Major issues: It is unclear in the document what assumptions section 3.1
> >  > makes about the relationship between supported tunnels and checked
> >  > embedded addresses. Is there an assumption that the router only has to
> >  > check for addresses in the format and prefix it supports? I hope so.
> >  > Otherwise, a router seems to be expected to look at an arbitrary IPv6
> >  > addresses, guess whether it has an embedded IPv4 addresses, and perform
> >  > filter checks on that guessed addresses against its own addresses.
> >  > If indeed their is a relationship, then it would really help if section
> >  > 3.1 said that.
> >  > Unfortunately, I am afraid no such relationship is assumed. If not, I
> >  > would like to see significantly better explanation of how the router is
> >  > to reliably know that there is a 6rd or ISATAP address embedded in the
> >  > v6 address.
> >  >
> >  > Minor issues:
> >  >
> >  > Nits/editorial comments: