Subject: RE: icmpv6-v3 comments

From: [email-masked]
Date: Sun, 21 Mar 2004 14:53:05 -0600

Pekka,

Sorry that I am replying to this mail so late ! and Thanks
for reviewing the draft thoroughly. Please see my comments
inline..

> Process issue: Draft Standard may not refer normatively to
> specifications of lower standardization status.  See
> draft-ymbk-downref-01.txt for a bit of discussion.  That is,
> IPv6-ADDR, PMTU and IPsec documents are unsuitable for normative
> references.  So, some wiggling around will be needed..

Well, the draft draft-ymbk-downref-01.txt says 
====
   In the case of protocols, a reference is normative if it refers to
   packet formats or other protocol mechanisms that are needed to fully
   implement the protocol in the current specification.  For example, if
   a protocol relies on IPsec to provide security, one cannot fully
   implement the protocol without the specification for IPsec also being
   available; hence, the reference would be normative.
====

As ICMPv6 proposes to use IPsec for security, according to the above
paragraph, IPsec documents should be normative.  So how do we resolve
this ?

> ==> should add IPR and copyright boilerplates at the end.

Will do in the next draft.

> 2.2 Message Source Address Determination
> 
>    A node that sends an ICMPv6 message has to determine both 
> the Source
>    and Destination IPv6 Addresses in the IPv6 header before 
> calculating
>    the checksum.  If the node has more than one unicast 
> address, it must
>    choose the Source Address of the message as follows:
> [...]
> 
> ==> should this "must" (and the following statements) be appropriately
> uppercased?

Yeah, I think so.  Will take care of this in the next draft too.

>     (c) If the message is a response to a message sent to an address
>         that does not belong to the node, the Source Address should be
>         that unicast address belonging to the node that will be most
>         helpful in diagnosing the error. For example, if the message is
>         a response to a packet forwarding action that cannot complete
>         successfully, the Source Address should be a unicast address
>         belonging to the interface on which the packet forwarding
>         failed.
> 
> ==> not sure if this has been implemented, so the usability 
> of this generic rule seems questionable.

Are you proposing to remove this ?  

I think, all the implementations use the IP address of the egress 
interface for the ICMP packet as the source address of the packet.

The above paragraph suggests to use the IP address of the interface
on which the packet was supposed to be forwarded.  Now if we are 
unable to forward the packet, how would we know which interface it
was supposed to go out on :-/  So which IP address should be used
in that case !

> 
>     (c) Every ICMPv6 error message (type < 128) includes as much of the
>         IPv6 offending (invoking) packet (the packet that caused the  
>         error) as will fit without making the error message packet  
>         exceed the minimum IPv6 MTU [IPv6].
> 
> ==> s/includes/MUST include/ ?

Will correct this..

>    If the reason for the failure to deliver can not be mapped 
> to any of
>    the specific codes listed above, the Code field is set to 3.  The
>    example of such cases are inability to resolve the IPv6 destination
>    address into a corresponding link address, or a 
> link-specific problem
>    of some sort.
> 
> ==> reasons with codes 4, 5, and 6 are below this sentence.  
> Maybe those
> paragraphs should be moved up, earlier in this section, or 
> the language here
> reworded?

Actually, I wanted to keep the description of the codes in the numerical
order.  If this description sounds confusing, could you suggest how to 
re-word it such that it is clearer without moving the descriptions of 
4, 5 and 6 before this ?

>   If the reason for the failure to deliver is that packet with this
>    source address is not allowed due to ingress or egress filtering
>    policies, the Code field is set to 5.
> 
>    If the reason for the failure to deliver is that the route to the
>    destination is a reject route, the Code field is set to 6.  This may
>    occur if the router has been configured to reject all the traffic for
>    a specific prefix.
> 
> ==> as has already been mentioned, these two rules are in fact a more
> specific, more informative subsets of code 1 -- 
> administratively prohibited. 
> I persnally don't see much of an objection for adding these 
> codes, but it
> would IMHO make useful to spell this out explicitly here.

Would it help to add the following text:
====
Codes 5 and 6 are more informative subsets of code 1.  Thus code 1
MAY be used in place of code 5 and 6.
====

>    It SHOULD be possible for the system administrator to configure a
>    node to ignore any ICMP messages that are not authenticated using
>    either the Authentication Header or Encapsulating Security Payload.
>    Such a switch SHOULD default to allowing unauthenticated messages.
> 
> ==> has this even been implemented anywhere?  could maybe be 
> deleted?  This is completely unpractical, e.g., just consider 
> PMTU packets -- there is no way you'll ever be able to set 
> up security associations with everyone in the Internet to be 
> able to accept the packets :)

I completely agree with you that this is unpractical but it does
make sense to a completely paranoid administrator.  Whoever turns
this option ON might not be interested in using PMTU.  I don't
see any harm in keeping it.  We can make it a MAY from SHOULD.

What say ??

>    [IPv6-ADDR]  Hinden, R., S. Deering, "IP Version 6 Addressing
>                 Architecture", RFC2373, July 1998.
> 
> ==> update.  Note that this is not Draft Standard yet.  As there is 
> nothing in IPv6-ADDR that's required by that spec, it could be 
> informative as well.

Makes sense.  I will move this to informative.

>    [PMTU]       McCann, J., S. Deering, J. Mogul, "Path MTU Discovery
>                 for IP version 6", RFC1981, August 1996.
> 
>    [IPv6-SA]    Kent, S., R. Atkinson, "Security Architecture for the
>                 Internet Protocol", RFC1825, November 1998.
> 
> ==> These, and IPsec RFCs are PS's at the moment -- can't refer.  
> IPsec ones are being revised though, if that helps any.

As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should
be normative.  So what should we do now ?

Also should we refer to the old IPsec RFCs or we should refer to the
updated ones ?  If we want to refer to updated ones, how do we refer
to them because they are still drafts.

> editorial
> ---------
> 
>    (f) Finally, in order to limit the bandwidth and forwarding costs  
>         incurred sending ICMPv6 error messages, an IPv6 node 
> MUST limit 
>  
> ==> s/incurred/incurred by/

Will take care of this in the next rev.

Thanks again for reviewing the draft.

Regards
Mukesh

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Mar 2004 14:45:45 +0200 (EET)

> paragraph, IPsec documents should be normative.  So how do we resolve

Well, if we conclude that those are required, maybe we have to use  
draft-ietf-ipsec-rfc2402bis instead -- that's already been at IESG 
evaluation so might not end up blocking the document.

PMTUD and Addr-arch would probably have to go on Informational
section, unless we conclude that they're too strong to be used here.
 
> Are you proposing to remove this ?  

Yes.

(But if people think mentioning some optional behaviour like this is a 
good idea, maybe it could be reworded/removed in the appendix as 
well.)
 
> interface for the ICMP packet as the source address of the packet.

That is my perception as well.
 
> was supposed to go out on :-/  So which IP address should be used

That's a real procedural problem, and maybe one of the main reasons 
why this was omitted.  In some cases, I think getting the IP address 
would be possible, but in general it would be rather challenging..

> > Maybe those paragraphs should be moved up, earlier in this
> > section, or the language here reworded?
> 

Maybe reword:

   If the reason for the failure to deliver can not be mapped to any of
   the specific codes listed above, the Code field is set to 3.

to:

   If the reason for the failure to deliver can not be mapped to any of
   other codes, the Code field is set to 3.

?

> > ==> as has already been mentioned, these two rules are in fact a
> > more specific, more informative subsets of code 1 --
> > administratively prohibited.  I persnally don't see much of an
> > objection for adding these codes, but it would IMHO make useful to
> > spell this out explicitly here.
> 

Fine with me, at least.

(I guess there could be some resistance to the second sentence, but if 
so, it could always be removed.)

> see any harm in keeping it.  We can make it a MAY from SHOULD.

OK -- I'm fine with putting it in as MAY, with some additional text to 
describe its inherent problems, e.g. like:

  Note that setting up Security Associations to deal with all the 
  required ICMP packets is a very difficult, if not even impossible, 
  task (e.g., consider the PMTUD packets) so typically this is does 
  not seem to be practical.

> to them because they are still drafts.

See above.  Referring to drafts is OK as long as they don't create a 
blockage when this work moves forward.  As the docs are already at 
IESG and this is not, this is (hopefully!) not a problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings