Subject: RE: Security Requirements for IPv6 Node Req summary

From: Tim Enos <[email-masked]>
Date: Thu, 06 Mar 2008 11:49:39 -0600 (CST)

I too would be in favor of a SHOULD for the AH requirement, with language dedicated both to a specific example of where AH is arguably a MUST (e.g. for nodes implementing OSPFv3), and other language which at least outlines where AH is and is not applicable.

Best regards,

Tim Enos
Ps 84:10-12

>I also suggest that the AH requirement be SHOULD, or even better MUST,
>for nodes implementing OSPFv3, RFC 2740.  This is based on the removal
>of the authentication LSA from OSPFv3, which was done with the
>expectation that AH would be mandatory.  Thoughts?
>
>Best Regards,
> 
>Jeffrey Dunn
>Info Systems Eng., Lead
>MITRE Corporation.
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Brian E Carpenter
>Sent: Wednesday, March 05, 2008 4:22 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: Security Requirements for IPv6 Node Req summary
>
>If we write a SHOULD we really do need some guidance
>as to when it doesn't apply. Otherwise we make it too
>easy for product managers to simply cross it off the list.
>How about
>
>  The normal expectation is that a complete IPv6 stack
>  includes an implementation of ESP. However, it is
>  recognized that some stacks, implemented for low-end
>  devices that will be deployed for special purposes
>  where strong security is provided by other protocol
>  layers, may omit ESP.
>
>Regards
>   Brian Carpenter
>   University of Auckland
>
>
>On 2008-03-06 09:14, [email-masked] wrote:
>> Sorry, that was a cut & paste mistake. AH is a MAY.
>> 
>> John 
>> 
>>> -----Original Message-----
>>> From: ext Vishwas Manral [mailto:[email-masked]] 
>>> Sent: 05 March, 2008 12:12
>>> To: Loughney John (Nokia-OCTO/PaloAlto)
>>> Cc: [email-masked]
>>> Subject: Re: Security Requirements for IPv6 Node Req summary
>>>
>>> Hi John,
>>>
>>> RFC4301 states AH is optional. Is there a reason why we are 
>>> making it a MUST be supported feature. Below quoting RFC4301:
>>>
>>> "IPsec implementations MUST support ESP and MAY
>>>   support AH."
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On Wed, Mar 5, 2008 at 11:46 AM,  <[email-masked]> wrote:
>>>> Hi all,
>>>>
>>>>  The RFC 4294-bis draft has the following requirement, which comes 
>>>> from  the initial RFC.
>>>>
>>>>   8.1. Basic Architecture
>>>>
>>>>    Security Architecture for the Internet Protocol [RFC-4301] MUST
>be
>>>>    supported.
>>>>
>>>>   8.2. Security Protocols
>>>>
>>>>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be 
>>> supported.
>>>>  We have had a lot of discussion that people basically feel 
>>> that these  
>>>> requirements  are not applicable and should be moved to SHOULD.  I 
>>>> would say that  there is rough  WG Consensus on this.  Do 
>>> people feel 
>>>> if there should be additional text  to explain  this?
>>>>
>>>>  I suggest that the WG Chairs and our ADs discuss this with the 
>>>> Security  ADs to ensure  that this is a reasonable consensus 
>>> to adopt 
>>>> - so that we do not run  into issues  during the eventual IETF/IESG
>
>>>> review.  I am not sure that we can go much  further in  
>>> discussions in 
>>>> the WG.
>>>>
>>>>  Does anyone have comments on this approach?
>>>>
>>>>  John
>>>>
>>>>
>--------------------------------------------------------------------
>>>>  IETF IPv6 working group mailing list
>>>>  [email-masked]
>>>>  Administrative Requests:
>https://www.ietf.org/mailman/listinfo/ipv6
>>>>
>--------------------------------------------------------------------
>>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 6 Mar 2008 10:09:47 -0800

Hi Tim,

You may have not read the OSPFv3 security RFC - RFC4552. It states clearly:

   In order to provide authentication to OSPFv3, implementations MUST
   support ESP and MAY support AH.

Thanks,
Vishwas

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 6 Mar 2008 14:57:27 -0500

Vishwas and Tim,

I would prefer to require one or the other.  This is because a router
implementing OSPFv3 MUST provide some means of authenticating messages.
The options are:

1. ESP-NULL: ESP without confidentiality and with integrity
2. ESP-ENC: ESP with confidentiality
3. AH: AH with integrity

I suggest we require implementations to do one or more.

Best Regards,
 
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 1:10 PM
To: Tim Enos
Cc: Brian E Carpenter; Dunn, Jeffrey H.; [email-masked];
[email-masked]

Hi Tim,

You may have not read the OSPFv3 security RFC - RFC4552. It states
clearly:

Thanks,
Vishwas

On Thu, Mar 6, 2008 at 9:49 AM, Tim Enos <[email-masked]> wrote:
> I too would be in favor of a SHOULD for the AH requirement, with
language dedicated both to a specific example of where AH is arguably a
MUST (e.g. for nodes implementing OSPFv3), and other language which at
least outlines where AH is and is not applicable.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2008 13:15:37 +1300

I don't see why this would belong in a generic IPv6 node
requirement. It belongs in the OSPFv3 spec.

   Brian

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 6 Mar 2008 23:02:36 -0500

Brian,

Your question points up my entire problem with this document.  If we
try to define the lowest common denominator for an IPv6
Capable/Complaint/Compatible device (note the lack of any real
nomenclature), we risk setting the expectation level at ground.  As a
result, I question the need for the document.  What problem are we
trying to solve?

Best Regards,
 
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 7:16 PM
To: Dunn, Jeffrey H.
Cc: Vishwas Manral; Tim Enos; [email-masked]; [email-masked]
Subject: Re: Security Requirements for IPv6 Node Req summary

   Brian

On 2008-03-07 08:57, Dunn, Jeffrey H. wrote:
>>  >>>> requirements  are not applicable and should be moved to
SHOULD.
> I

---

From: Bob Hinden <[email-masked]>
Date: Fri, 7 Mar 2008 10:32:52 -0800

> requirement. It belongs in the OSPFv3 spec.

It certainly belongs in the OSPFv3 specification, but I don't see any  
harm in putting a note into IPv6 node requirements that the IPSEC  
requirements for routers running OSPFv3 can be found in Section X.X  
of RFC4552.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Mar 2008 08:28:44 +1300

On 2008-03-08 07:32, Bob Hinden wrote:
> requirements for routers running OSPFv3 can be found in Section X.X of
> RFC4552.

I fully agree.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Mar 2008 08:33:07 +1300

I believe that the purpose of this document is to list a minimum
set of components that will allow for layer 3/4 interoperation.
So yes, that is a baseline specification.

I think that anything beyond that really is better left to
vendors and purchasers.

Regards
   Brian Carpenter
   University of Auckland

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Mar 2008 06:38:25 -0400

Suresh,

First, one simple comment.

1. In section 1 of your draft you say 

[may need to look at the transport layer header fields...]

Change "transport layer header" to "upper layer header" because 

(a) You must use language consistent with RFC 2460.
(b) Use of transport layer is incorrect because ICMP is a layer 3
protocol that is also upper layer for IPv6 Extended Header (EH) while
the transport layer is layer 4.

On to more critical issues. 

2. I and Wes don't agree at all with bullet 2 in section 4 (Future work)
of this draft that says:

[Extension headers must be processed in any order they appear]

Hop-by-hop option is processed by every intermediate router and such
router's fast path silicon is usually a hardware engine that parses the
first x bytes of the Extended header (EH) where x can be say, 64 bytes.
I suspect that was the design theme when folks wrote RFC 2460 and made
sure hop-by-hop was always the first EH. Also, as reviewers of your
draft we still keep in mind that hop-by-hop hasn't been deprecated. 

Further, section 4.1 of RFC 2460 also defines a specific sequence of
EH's. We want your draft to still comply to RFC 2460 in this regard -
comply with section 4.1 of RFC 2460 and preserve this section's EH
Order. Further this section from RFC 2460 says:

[If and when other extension headers are defined, their ordering
constraints relative to the above listed headers must be specified].

This constraint cannot be dispensed with without very careful thought.

3. RFC 2460 clearly says in section 4 that EH's are not processed by
intermediate nodes unless the EH is a hop-by-hop EH. Since your draft
ignores this rule of RFC 2460, it's up to the IPv6 community to first
agree to such a change to RFC 2460 before looking at your draft.

Hemant & Wes

---

From: james woodyatt <[email-masked]>
Date: Wed, 12 Mar 2008 09:34:57 -0400

> Change "transport layer header" to "upper layer header" because

I agree with that recommendation.

> [Extension headers must be processed in any order they appear]

I agree with that recommendation too.

> ignores this rule of RFC 2460, ...

I don't agree with this.  It may have informative text that seems a  
bit more cavalier than necessary, but that can be fixed prior to last  
call.  It does not define any new types of extension header.  Assuming  
your previous criticisms are addressed properly, then it will define  
any new extension header processing requirements either.

> ...it's up to the IPv6 community to first agree to such a change to  
> RFC 2460 before looking at your draft.

I don't think the intent is to define any changes to current  
requirements for processing extension headers.  The idea is to define  
a minimal set of new requirements for defining extension headers, for  
the purpose of allowing packet analyzers to identify unambiguously the  
upper layer header type of IPv6 datagrams containing any and all  
extension headers that may be defined in the future.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 17 Mar 2008 18:47:19 -0400

Hi Hemant,
   Thanks for your comments. Please see responses inline.

> the transport layer is layer 4.

Will do.

> This constraint cannot be dispensed with without very careful thought.

I agree with you in spirit, but the requirement for ordering is very 
fuzzy. For example If there is a routing header of type 0 and a routing 
header of type 2 what is the order in which they should appear. I think 
the text should read

"Extension headers must be processed in the order they appear"

This is, I think, a valid paraphrase of the text "Therefore, extension 
headers must be processed strictly in the order they appear in the 
packet" that appears in RFC2460.

> agree to such a change to RFC 2460 before looking at your draft.

I am not sure I understand what you mean. The draft does not recommend 
anybody to look at the EHs other than the HBH. The draft says that, if 
someone does (e.g. firewalls and other middleboxes) it makes sense to 
have a standard header format. Not that I condone it, but this paradigm 
(of routers being L3 only devices) has been broken long time ago. Every 
router I know of has the capability to look at and filter at least on 
the transport layer port.

Thanks
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 17 Mar 2008 15:53:43 -0700

Hi,

I agree with Suresh here.
>  the transport layer port.

Not just for middle-boxes, but for a simple function like doing ECMP
load balancing we need to look up the upper layer headers (TCP/ UDP).

That said I would encourage the work on HBH too. On a similar note
have a look at the "Tiny Fragements" draft I had put across some while
back:

http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02

Thanks,
Vishwas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Mar 2008 10:34:37 -0400

Suresh,

I thought my arguments were clear enough from my original email. But let
me give it another shot.

Please see in line below between <hs> and </hs> 

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Monday, March 17, 2008 6:47 PM
To: Hemant Singh (shemant)
Cc: IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

Hi Hemant,

Will do.

> 2. I and Wes don't agree at all with bullet 2 in section 4 (Future 
> work) of this draft that says:
> 
> router's fast path silicon is usually a hardware engine that parses 
> the first x bytes of the Extended header (EH) where x can be say, 64
bytes.

<hs>

Your example is not a good one for more reasons than one and the
ordering is not fuzzy. First, RH0 has been deprecated. Secondly, RFC
3775, the RFC that defined the RH2 clearly says in section 6.4.1 as
follows:

[The ordering rules for extension headers in an IPv6 packet are
described
 in Section 4.1 of RFC 2460 [11].  The type 2 routing header defined
 for Mobile IPv6 follows the same ordering as other routing headers.
 If both a type 0 and a type 2 routing header are present, the type 2
 routing header should follow the other routing header.  A packet
 containing such nested encapsulation should be created as if the
 inner (type 2) routing header was constructed first and then treated
 as an original packet by the outer (type 0) routing header
 construction process.]

Further evidence for ordering not being fuzzy is shown in the following
text from section 4.1 of RFC 2460.

[When more than one extension header is used in the same packet, it is
 recommended that those headers appear in the following order:

           IPv6 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           Fragment header

           Authentication header (note 2)
           Encapsulating Security Payload header (note 2)
           Destination Options header (note 3)
           upper-layer header]

The same section goes on to say, 

[If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.]

</hs>

<hs>Of course, firewall vendors will be biased towards inspecting an EH
that is not the HBH. But that is not what RFC 2460 says. Here is text
from RFC 2460 that clearly says, no intermediate node will
inspect/process any EH besides the HBH. 

[With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.]

Pardon my ignorance, but I need to see an explicit RFC that says
firewalls being intermediate nodes, are allowed to inspect an EH that is
not HBH and that RFC should also say that the RFC updates RFC 2460. 
</hs>

Thanks.

Hemant

Thanks
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 19 Mar 2008 10:23:03 -0700

Hi Hemant,

>  not HBH and that RFC should also say that the RFC updates RFC 2460.
It is not just firewalls, like I have mentioned earlier. In case there
are two routes to a destination which are of Equal cost (ECMP), a
router actually does load balancing by calculating a hash based on the
inner header fields like 5-tuple fields. I think this is basic to just
about any router and not firewalls itself.

Thanks,
Vishwas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 19 Mar 2008 11:13:47 -0700

At Wed, 19 Mar 2008 10:34:37 -0400,

> > [Extension headers must be processed in any order they appear]

[snip]

>    constraints relative to the above listed headers must be specified.]

This part of RFC2460 talks about the sender side; I'm afraid you're
referring to the wrong part of RFC2460.  In my understanding, we are
talking about the receiver side (whether it's a final e2e destination,
or a router that has to see some portion of the packet, or an
intermediate node that processes a routing header, or even an evil,
layer-violating filtering/inspection device), and RFC2460 is pretty
generous on this point:

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header which is restricted to
   appear immediately after an IPv6 header only.

BTW, if your concern is specifically the position of a hop-by-hop
header, yes, the RFC states very clearly that it (when it appears)
must appear immediately after the IPv6 header.  But I didn't think the
following bullet of draft-krishnan-ipv6-exthdr-01

   o  Extension headers must be processed in any order they appear

intended to amend the restriction.  My interpretation was it meant
headers except the hop-by-hop options header.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 09:48:47 -0400

Vishwas,

In one email you use the term "inner header fields" and in another email
you use the term "upper layer headers" to describe the same problem. The
discussion will not be fruitful unless we use a terminology that all of
us understand.

Anyhow, that is one router implementation you speak of below in the load
balancing (LB) case. A router may use any set of fields to perform hash
for LB, not just the specific fields you speak of. The router LB is a
weak reason that is not strong enough for a case for this draft.

Anyhow, I would like folks to wait till the Meeting minutes from 6man @
IETF 71 are published to the mailer. You will see what the meeting
feedback on this draft was.

I will reply to Tatuya in a short while. 

Thanks.

Hemant

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2008 1:23 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

Hi Hemant,

>  <hs>Of course, firewall vendors will be biased towards inspecting an 
> EH  that is not the HBH. But that is not what RFC 2460 says. Here is 
> text  from RFC 2460 that clearly says, no intermediate node will  
> firewalls being intermediate nodes, are allowed to inspect an EH that 
> is  not HBH and that RFC should also say that the RFC updates RFC
2460.
It is not just firewalls, like I have mentioned earlier. In case there
are two routes to a destination which are of Equal cost (ECMP), a router
actually does load balancing by calculating a hash based on the inner
header fields like 5-tuple fields. I think this is basic to just about
any router and not firewalls itself.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 20 Mar 2008 07:27:16 -0700

Hi Hemant,

Sorry for using the term "inner header". I wasn't sure it would be
unclear to anyone. Sorry again for not using the exact terminology as
in the RFC.

That said it seems you miss the basic idea of load balancing. No, we
certainly cannot use any set of fields, and this is very well known.
The entire idea of using the inner header(TCP/ UDP) for load balancing
is that we do not reorder micro flows. Reordering TCP micro-flows
causes issues for TCP.

Can you let me know any hardware which can use "any" set of fields? It
would be interesting to  know that.

Thanks,
Vishwas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 11:14:19 -0400

Tatuya,

I understand receiver vs. sender. I am talking about the fact that RFC
2460 says no intermediate node may inspect/process any EH besides the
HBH EH. That is the reason for which I quote this para from section 4 of
RFC 2460:

This text would prohibit a firewall, which is an intermediate node, to
inspect/process any EH. I also asked if any RFC exists that changed this
behavior from RFC 2460 to allow an intermediate node like a firewall to
inspect/process EH's besides the HBH.

I agree with you that a receiver may process the EH's in any order
except the HBH EH. Yes, my concern with text from Suresh's draft was
indeed that HBH was not mentioned with 

" o  Extension headers must be processed in any order they appear"

Also, the same bullet above does not mention the EH Order defined in
section 4.1 of RFC 2460. If the order is followed by a sender, a
receiving node will receive the EH's in order. 

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2008 2:14 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

[snip]

> Further evidence for ordering not being fuzzy is shown in the 
> following text from section 4.1 of RFC 2460.
> 

BTW, if your concern is specifically the position of a hop-by-hop
header, yes, the RFC states very clearly that it (when it appears) must
appear immediately after the IPv6 header.  But I didn't think the
following bullet of draft-krishnan-ipv6-exthdr-01

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 20 Mar 2008 11:35:30 -0700

At Thu, 20 Mar 2008 11:14:19 -0400,
 
> receiving node will receive the EH's in order. 

Of course, but the point is that the receiver cannot (or even must
not) assume that ordering.  This is a typical example of "Be liberal
in what you accept(, and conservative in what you send)".

> HBH EH. That is the reason for which I quote this para from section 4 of

I don't understand why you mentioned this in a response to my previous
message; I didn't argue about this point.  I specifically responded
the quoted (below) part of your previous response to Suresh, where I
don't see any relevance to the inspection by an intermediate node.

---
JINMEI, Tatuya

=====================from here =======================================
Suresh,

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Monday, March 17, 2008 6:47 PM
To: Hemant Singh (shemant)
Cc: IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

Hi Hemant,

[snip]

bytes.

<hs>

           IPv6 header

</hs>
=======================to here =======================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 15:51:46 -0400

Hi Hemant,
   Please find responses inline.

>  identified in the Destination Address field of the IPv6 header.] 

This text is not normative, as you can clearly see. "headers are not" is 
way different from "headers must not be"

> except the HBH EH. 

No. The receiver MUST process the extension headers in the order they 
appear. Please see the following text from RFC2460

> Yes, my concern with text from Suresh's draft was indeed that HBH was not mentioned with 
> 

I already suggested replacement text for this in my earlier mail. Did 
you not receive it? Anyway the intent of this text was to say

Thanks
Suresh

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 16:10:51 -0400

> " o  Extension headers must be processed in any order they appear"

Why isn't the wording in RFC 2460 even clearer? Quoting:

   Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

Bert

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 16:16:39 -0400

Hi Bert,

>    processing all preceding ones.

It is very clear. And that is exactly the problem I am talking about in 
the draft. The real issue is that when you reach an unknown header of an 
unknown format you have no way of proceeding any further with the 
processing. The text Hemant was quoting is not from the meat of the 
draft but from the future work section.

Thanks
Suresh

---

From: Markku Savela <[email-masked]>
Date: Thu, 20 Mar 2008 22:21:26 +0200

> From: Suresh Krishnan <[email-masked]>

And, if you hit unknown header, there is *NO WAY* to skip over it. You
have no idea whether it is an extension header (following the standard
format), or something totally different.

This seems moot all text in the draft...
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 16:30:02 -0400

Hi Markku,

> format), or something totally different.

And hence this text in the future work section of the draft about 
remaining issues to be resolved.

    o  Unknown extension headers cannot be differentiated from unknown
       upper layer protocols

We had discussed this in the 6man meeting and there is no consensus on 
the way forward. A common extension header format is ONLY ONE STEP in 
the direction of the solution. It is certainly not the complete answer 
and there is no claim in the draft that says otherwise.

Thanks
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 20 Mar 2008 13:30:15 -0700

Hi Markku,

I totally agree with you on this.

As there is no way to distinguish between an IPv6 extension header and
an upper layer header (TCP/ UDP) there is no way to find this out.
Also the upper layer header is not be IPv6 specific, but common for
IPv4 and IPv6.

Thanks,
Vishwas

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 16:34:19 -0400

> Sent: Thursday, March 20, 2008 4:30 PM
> To: Markku Savela

> and there is no claim in the draft that says otherwise.

I think the wording I quoted previously from RFC 2460 is intended to
keep the receiver of the packet, the one identified in the IP DA, from
skipping over unknown EHs. Which seems like the right thing to do. An
unknown EH at the receiver should generate and ICMP error, I think.

If this draft wants to bypass that rule:

   If new extension headers are defined and the
   intermediate node is not aware of them, the intermediate node cannot
   proceed further in the header chain since it does not know where the
   unknown header ends and the next header begins.  The main issue is
   that the extension header format is not standard and hence it is not
   possible to skip past the unknown header.  This document intends to
   define a standard format for IPv6 extension headers.

perhaps it makes sense to specify clearly that this skipping option ONLY
applies to intermediate nodes? It doesn't seem prudent to leave that
unspecified.

Bert

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 16:47:18 -0400

Hi Bert,

> unknown EH at the receiver should generate and ICMP error, I think.

I agree with you on this.

> If this draft wants to bypass that rule:

The goal of the draft is not to make any recommendations to either 
receiving end nodes or intermediate nodes. The goal of the draft is to 
propose a standard extension header format. That's it. Period. If you 
found any text in the draft that suggests some action on the nodes, I 
can remove it (Please point it out to me). It was not my intention to 
specify any skip/drop behavior on the nodes.

Thanks
Suresh

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 16:51:09 -0400

> specify any skip/drop behavior on the nodes.

I understand what you are saying. But my point is that it was
specifically this lack of explicit limits on who may safely "skip over"
any EH that made my knee jerk. It's almost like the draft conflicts with
RFC 2460, or at least seems to PERMIT such a conflict to occur.

Bert

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 16:51:34 -0400

Suresh,

I have snipped some of your response sentences below followed by my
reply preceded by "<hs>".

<hs> Ok, I am leaning to agree with that.
 
you not receive it? 

<hs> Sorry, I didn't receive that email. Anyhow, I understand your
intent and the issue in the "Future work" section is closed between us.

Thanks.

Hemant

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Thursday, March 20, 2008 3:52 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

Hi Hemant,

> HBH EH. That is the reason for which I quote this para from section 4 
> of RFC 2460:
> 

> inspect/process any EH. I also asked if any RFC exists that changed 
> this behavior from RFC 2460 to allow an intermediate node like a 
> firewall to inspect/process EH's besides the HBH.
> 
> 

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 16:56:56 -0400

Hi Bert,

> RFC 2460, or at least seems to PERMIT such a conflict to occur.

I do see what you mean. Is this the text you were referring to that made 
you uncomfortable?

"  This document proposes that all IPv6 extension headers be encoded in
    a consistent TLV format so that it is possible for nodes to skip over
    unknown extension headers and continue to further process the header
    chain."

If I add the word intermediate in the text in order to read

"  This document proposes that all IPv6 extension headers be encoded in
    a consistent TLV format so that it is possible for intermediate nodes
    to skip over unknown extension headers and continue to further
    process the header chain."

would this make it more palatable for you?

Thanks
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 16:56:42 -0400

Indeed Markku.

Snipped from RFC 2460 is following text:

   [If, as a result of processing a header, a node is required to
proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet, with an
   ICMP Code value of 1 ("unrecognized Next Header type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv6 header.]
 
Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Markku Savela
Sent: Thursday, March 20, 2008 4:21 PM
To: Suresh Krishnan
Cc: [email-masked]
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

> From: Suresh Krishnan <[email-masked]> Manfredi, Albert 
> E wrote:
> It is very clear. And that is exactly the problem I am talking about 
> in the draft. The real issue is that when you reach an unknown header 
> of an unknown format you have no way of proceeding any further with 
> the processing. The text Hemant was quoting is not from the meat of 
> the draft but from the future work section.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Mar 2008 09:56:36 +1300

>>  It was not my intention to 

But that's exactly what IETF specs should always do,
to promote interoperability. Even if the recommended
behaviour is silent discard, that should always be
specified IMHO.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 17:02:20 -0400

> would this make it more palatable for you?

Hi Suresh, yes, that would help a lot. Also perhaps, "The intention of
RFC 2460 that destination hosts not be permitted to skip unknown
extension headers continues to apply."

Or words to that effect.

Bert

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 17:04:21 -0400

Suresh,

Introduction para of your draft says "However, some intermediate nodes
such a firewalls, may need to look at the transport layer header fields
in order to make a decision to allow or deny the packet."

Well, isn't the sentence suggesting that the firewall drops the packet?
Also, seeing the term "intermediate", I had to check RFC 2460 and hence
questioned if even an intermediate node was legal to inspect and process
an EH that was not HBH. It may make sense to clarify RFC 2460 is this
regard.

Also, in response to your latest email that suggested new text, I don't
like the "all IPv6 extension headers". I would rather have it as "all
the new IPv6 extension headers".

Anyhow, didn't you hear in the 6man at IETF 71 that there has been no EH
defined in the past 10 years (or maybe one), so why does one need this
draft?

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Suresh Krishnan
Sent: Thursday, March 20, 2008 4:47 PM
To: Manfredi, Albert E
Cc: [email-masked]
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

Hi Bert,

Manfredi, Albert E wrote:
>> We had discussed this in the 6man meeting and there is no consensus 
>> on the way forward. A common extension header format is ONLY ONE STEP

>> in the direction of the solution. It is certainly not the complete 
>> answer and there is no claim in the draft that says otherwise.
> 

Thanks
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 17:11:03 -0400

I agree with Brian. That is why I said the text in RFC 2460 that Suresh
says isn't Normative and I am quoting ad nauseum is text that deals with
an important issue. The issue being, does an intermediate node
inspect/process any EH besides the HBH? The text says, no, but Suresh
says, this text is not Normative.

Go see IPv6 docs on the Internet and see how many docs say, an
intermediate node does not inspect/process any EH besides the HBH. Some
network sniffers and generators for IPv6 have such information in their
product documentation! 

This isn't an issue one should gloss over. Some new document needs to
update this fact in RFC 2460.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian E Carpenter
Sent: Thursday, March 20, 2008 4:57 PM
To: Suresh Krishnan
Cc: [email-masked]
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

>> specify any skip/drop behavior on the nodes.

But that's exactly what IETF specs should always do, to promote
interoperability. Even if the recommended behaviour is silent discard,
that should always be specified IMHO.

    Brian

---

From: Markku Savela <[email-masked]>
Date: Thu, 20 Mar 2008 23:16:56 +0200

>     process the header chain."

But, but... how can intermediate skip over "unknown extension header",
if it doesn't know the header.

The part of draft, that proposes new extension headers follow the TLV
format is OK. Although, I have always assumed that this was already
implicit or even specified. If not, the draft could be seen as an
emendation to the existing drafts.

What irks me, is the talk of intermediates skipping "unknowns", which
depends on them somehow recognizing the header as "extension
header". But, if they recognize it, it is not *unknown* anymore. Seems
to be a "thought loop".

For your "skipping scheme" to work, then *ALL* headers would need some
special bit in exactly the same location, and this bit would tell
whether header is an extension header or not.

So, to make your draft complete, you would also need to enforce that
*ALL* new headers extension or not, will have this bit reserved for
the purpose. This may be a bit too much to define at this point...

---

From: Jim Hoagland <[email-masked]>
Date: Thu, 20 Mar 2008 14:22:40 -0700

There is actually a small amount of value from this, even absent a way to
distinguish unknown extension headers and unknown upper layer headers.
Specifically, the implementation of a parser for (known) extension headers
can be simplified due to the uniform layout of at least the start of the
header.  In software, you could use a single subroutine to start the parsing
of any extension header.  Hardware implementations would have a similar
advantage.  While at present most extension headers can use the same
subroutine, that is less certain for the future unless a standard format is
specified.

At present, when people are thinking about parsing extension headers, I
always tell them to be careful not to treat parsing the Fragment header the
same way as other defined extension headers, since a non-zero value in the
second octet of that needs to be treated differently than the other cases
(i.e., it does not indicate a longer length).  It would nice to no longer
have to give this advice.

-- Jim

-- 
Jim Hoagland, Ph.D., CISSP
Principal Security Researcher
Advanced Threat Research
Symantec Security Response
www.symantec.com
--------------------------
Office: (650) 527-0946

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 17:28:17 -0400

Hi Bert,

> extension headers continues to apply."

That sounds good. I will make this addition to the text.

Thanks
Suresh

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 17:32:55 -0400

> From: Markku Savela [mailto:[email-masked]] 

> header". But, if they recognize it, it is not *unknown* anymore. Seems

The 8-bit "next header" field, the first byte, uses the same coding as
the IPv4 Protocol field. And the next 8 bits after that provide the
length of the EH.

Why can't the intermediate node work its way down all unknown EHs until
it reaches a "next header" you can identify? This should always occur.

Bert

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 17:35:37 -0400

Since the subject of interoperability was brought up, I couldn't resist
this thought.

In a lot of deployed protocols out there from IETF, or ITU telephony
protocols, or cable docsis protocol, there is one common thread. For
core protocol messages and message headers, the messages are defined in
a specific format that is NOT TLV based. The first reason is because one
wants interoperability for the core protocol messages. One also does not
want a new message proposed every day from someone's backyard. Since, by
deliberation, the core protocol messages do not follow a TLV format, it
is hard for the standard to change in a heartbeat without proper
thinking. I feel the EH in IPv6 is such a core header. I don't want IPv6
to be that flexible that folks grow a new EH in their backyard and start
developing products with the new EH.

I raise the point again on another question. How many new EH's have been
defined new in the past decade that one needs a flexible format for EH?

Further, even I don't have a strong opinion on the TLV format proposed
in this draft nor do I have a big problem with it. But I do have some
basic questions and issues raised above.

Lastly, let's get to the root cause of what needs fixed and stay focused
on that problem and its solution - as one can see, using a TLV based
format for EH doesn't fix the problem. As Markku asked, how does one
know the EH is unknown for a node to even skip such an EH?

Thanks.

Hemant

-----Original Message-----

    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 17:41:55 -0400

Hi Hemant,

> Well, isn't the sentence suggesting that the firewall drops the packet?

No. I am not sure why you think that. The truth is that firewalls exist 
and they make decisions to allow/deny packets based on configured policy.

> an EH that was not HBH. It may make sense to clarify RFC 2460 is this

 From my reading of RFC2460, it is not legal for an intermediate node to 
read other EHs than the HBH. But that does not stop any intermediate 
node, like a firewall, from doing so. What can we do about it? Ban 
firewalls?

> the new IPv6 extension headers".

OK.

> defined in the past 10 years (or maybe one), so why does one need this

Of course I heard that, but it does not matter. History is not a good 
predictor of the future. Pick from one of the following options and then 
we can argue further on this.

1) We will have no more extension headers: In this case make a 
recommendation to not use extension headers but use destination options 
instead. Right now RFC2460 mentions both EHs and DOs as expansion 
mechanisms and someone can base their protocol design on EHs.
2) We will have more extension headers: Specify a standard format for them.

Thanks
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 20 Mar 2008 14:42:31 -0700

Hi Albert,

>  it reaches a "next header" you can identify? This should always occur.
How can a node know it is a new Extension Header (which follows the
format as specified in the new draft) or another upper layer protocol?
There can be two unknowns - unknown upper layer protocol and unknown
EH.

Say if we get a value of x, which is unknown in the Next Header field,
there is no way we can assume the next header is either EH or an upper
layer protocol. So there is no way to say the Next Header follows the
format as specified in the EH.

Thanks,
Vishwas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Mar 2008 17:43:29 -0400

Jim,

We don't change IETF core protocol header fields for parser
simplification. Let's discuss the fundamental problem and find a
solution for it.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jim Hoagland
Sent: Thursday, March 20, 2008 5:23 PM
To: Vishwas Manral; Markku Savela
Cc: [email-masked]; Suresh Krishnan
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt

There is actually a small amount of value from this, even absent a way
to distinguish unknown extension headers and unknown upper layer
headers.
Specifically, the implementation of a parser for (known) extension
headers can be simplified due to the uniform layout of at least the
start of the header.  In software, you could use a single subroutine to
start the parsing of any extension header.  Hardware implementations
would have a similar advantage.  While at present most extension headers
can use the same subroutine, that is less certain for the future unless
a standard format is specified.

At present, when people are thinking about parsing extension headers, I
always tell them to be careful not to treat parsing the Fragment header
the same way as other defined extension headers, since a non-zero value
in the second octet of that needs to be treated differently than the
other cases (i.e., it does not indicate a longer length).  It would nice
to no longer have to give this advice.

-- Jim

---

From: Jim Hoagland <[email-masked]>
Date: Thu, 20 Mar 2008 14:44:48 -0700

Perhaps foolishly stepping in here when I am behind in other work :) ...

I agree that both the issue of being able to distinguish an unknown EH from
an unknown upper layer header and having a uniform start to extension
headers are important and both must be in place in order to get the full
value.  However, I am fine with these being resolved separately.

Since the distinction between an unknown extension header or an unknown
next layer protocol is important, let me informally propose a solution...

--
My suggestion for how to solve this problem lies in setting aside a next
header range for future extension headers.  For example set aside the range
240-247.

Within that, I'd suggest reserving 247 as a special case, to allow for
expansion.  This following probably wouldn't be officially defined now, but
my idea there is that if "next header=247", then the 3rd octet (or 3rd and
4th octet) of the extension header would further define which extension
header this is.

Also, we might want to make 246 (or 240-243) a special value to indicate
that this extension header "transforms" the rest of the packet in a way that
will make it impossible to meaningfully parse the header and what follows.
If it didn't already have a next header value, ESP would be an example of
this.  A mechanism like I suggested for 247 could make up for the fact that
this is a limited range.

Of course, the 3 ranges/subranges I mention could be different sizes than I
suggested and could be distinct ranges.

(Eventually you may have to deal with running out of values for upper layer
protocols, but I'm not going into that.)
--

Feel free to pick away...

-- Jim

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Mar 2008 17:46:50 -0400

> format as specified in the EH.

Hi Vishwas,

Remember that the motivation for this draft is firewalls.

So, if the firewall uses the EH Length field to hop down all unknown
headers, but in doing so it never reaches a known "next header" value,
presumably that firewall should discard the packet.

In other words, unkown upper layer protocols would be reason enough to
block such a packet.

Bert

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 17:53:13 -0400

Hi Markku,

> emendation to the existing drafts.

I am glad you are OK with this. This was neither implicit or specified. 
That is what this draft is trying to fix.

> header". But, if they recognize it, it is not *unknown* anymore. Seems

OK. I will think out loud on this one. This is how I feel it can be 
done. We allocate a single IP protocol number for IPv6 extension 
headers. Say 141 (Generic IPv6 extension header). All new extension 
headers need to use this in the first octet. The second octet contains a
specific extension header type (this identifies the actual extension 
header). The third octet contains the length. Everything else is 
type-specific.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Specific Type  | Hdr Ext Len |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                                                               .
    .                  Header Specific Data                         .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Next Header          8-bit selector.  Identifies the type of header
                         immediately following the Extension header.
                         Uses the same values as the IPv4 Protocol
                         field.
    Specific Type        8-bit unsigned integer. The actual IPv6
                         extension header type. This will be allocated
                         from a new IANA registry.
    Hdr Ext Len          8-bit unsigned integer.  Length of the
                         Extension header in 8-octet units, not
                         including the first 8 octets.
    Header Specific      Variable length. Fields specific to the
    Data                 extension header

At this point we can say that anything where the EH type is 141 and 
specific type not recognized is an unknown extension header. Anything 
else is an upper layer protocol (that does not follow the format).

Thanks
Suresh