RE: icmpv6-v3 comments

[Pekka Savola <[e-mail]>]

On Sun, 21 Mar 2004 [e-mail] wrote:
> > 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 ?

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.
 
> >     (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 ?  

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.)
 
> I think, all the implementations use the IP address of the egress 
> interface for the ICMP packet as the source address of the packet.

That is my perception as well.
 
> 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 !

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..

> >    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 ?

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.

?

> >   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.
> ====

Fine with me, at least.

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

> >    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 ??

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.

> >    [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.

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


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