Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05

[Eric Gray <[e-mail]>]

Zhenlong,

A few observations:

1) Even if you can respond to the sender - as expected for the
   unknown TLV case - you should exercise implementation caution
   to avoid banging the network with these responses if you keep
   getting the offending TLVs.  That turns some other vendor's
   problems into your problem.  This approach reduces security
   risks associated with a known sender that is behaving badly.
2) If you are relying on the TLV to give you the identity of the
   sender, how can you not know the TLV type?  On the other hand,
   if you know how to get a reply to the sender by some means,
   and you get one or more TLVs that you don't understand, then
   you should probably send an error code at least once, and you
   may determine from your own experience that you need to send
   additional replies periodically if it continues.
3) Specifying this sort of implementation detail is not part
   of what the IETF is not paying me to do.  :-)
4) Since this document refers to RFC 4379 extensively, it isn't
   necessary for this document to repeat the content of RFC 4379.
5) What we can do is point to the specific location in RFC 4379,
   since it is not easy to find.  That we will do.

--
Eric

-----Original Message-----
From: Zhenlong Cui [mailto:[e-mail]] 
Sent: Tuesday, July 26, 2011 5:04 PM
To: Eric Gray
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
Importance: High

Hi Eric,

I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem with
responding.
On the other hand, you say that you should send a reply when the request includes an unknown TLV.

I think if the responder receives a request it checks the type of the TLV before it checks the identifiers.

So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does the responder
have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it?


Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
1) Which return code to send when source/destination identifiers are wrong or drop the request.
2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.


Best,
Zhenlong

> -----Original Message-----
> From: Eric Gray [mailto:[e-mail]]
> Sent: Wednesday, July 27, 2011 12:56 AM
> To: Zhenlong Cui
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> 
> Zhenlong,
> 
> Q-1: See RFC 4379, where these registry entries are derived from.
>      RFC 4379 sets up a number of registries - including the TLV
>      registry - and defines explicitly how to handle unknown TLV
>      types in section 3, in two very obscure paragraphs on page
>      10, just before section 3.1.
> 
> Q-2: "ingress port" is not correct - thanks for spotting this
>      cut-and-paste duplication error.
> 
> --
> Eric
> 
> -----Original Message-----
> From: Zhenlong Cui [mailto:[e-mail]]
> Sent: Tuesday, July 12, 2011 5:20 AM
> To: [e-mail]; [e-mail]
> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> 
> Dear Authors,
> 
> Two questions regarding the idenfifiers TLV and DSMAP TLV.
> 
> Question 1:
> > > > Which return code to send when identifiers are wrong (Malformed echo
> > > > request received?) or drop the packet.
> > > >
> > > > EG > Drop the packet, probably log the error, possibly run off
> > > > EG > screaming into the night.  What does one do when one gets
> > > > EG > something either not recognizably intended for one, or not
> > > > EG > from a source that one recognizes?  From a security point
> > > > EG > of view, we cannot require an implementation to reply to
> > > > EG > the requester in this case (this is an attack vector for
> > > > EG > all kinds of hate and discontent).  Nor can we forbid it.
> > > >
> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One
> or
> more of the TLVs was not understood)? Can this way two answers be generated?
> 
> 
> Question 2:
> In section 2.1.1, Is below("ingress port") correct?
> 
>    Egress IF_Num identifies the ingress port on the target node.  A
>    value of 0 indicates that the port is not part of the identifier.
> 
> 
> Best,
> zhenlong
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Rolf Winter
> > Sent: Monday, June 27, 2011 8:04 PM
> > To: Eric Gray; [e-mail]; [e-mail]
> > Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
> >
> > I think that's OK, since the value is not beyond but within the TLV. Taken from 4379:
> >
> > Types are defined below; Length is the length of the Value field in
> > octets.  The Value field depends on the Type; it is zero padded to
> > align to a 4-octet boundary.
> >
> > That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is determined
> > by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your argument
> > why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information
> is
> > encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure
> of
> > each TLV to extract the value instead of applying the simple rule above.
> >
> >
> > Best,
> >
> > Rolf
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: Eric Gray [mailto:[e-mail]]
> > > Sent: Montag, 27. Juni 2011 12:42
> > > To: Rolf Winter; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > > [e-mail]
> > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > cv
> > >
> > > IMO, that would be a problem with RFC 4379.  Perhaps there is
> > > an errata?
> > >
> > > TLVs are meant to follow each other, where the beginning of the
> > > next TLV is determined by the length of the current TLV - hence
> > > it is not correct to specify any content as having any value at
> > > all if it is beyond the end of the TLV.
> > >
> > > -----Original Message-----
> > > From: Rolf Winter [mailto:[e-mail]]
> > > Sent: Monday, June 27, 2011 5:06 AM
> > > To: Eric Gray; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > > [e-mail]
> > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > cv
> > > Importance: High
> > >
> > > Hi Eric,
> > >
> > > just one more to follow up. You say:
> > >
> > > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long,
> > > > EG > even if the last two octets "Must be Zero").  The length of
> > > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made
> > > > EG > longer by the addition of the 2-word AGI.  Nice catch!
> > >
> > > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be
> > > included in the length of the sub-TLVs. Why are they included here?
> > >
> > > Best,
> > >
> > > Rolf
> > >
> > >
> > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > > London W3 6BL | Registered in England 2832014
> > >
> > >
> > > >
> > > > EG > Apparently.
> > > >
> > > > Which return code to send when identifiers are wrong (Malformed echo
> > > > request received?) or drop the packet.
> > > >
> > > > EG > Drop the packet, probably log the error, possibly run off
> > > > EG > screaming into the night.  What does one do when one gets
> > > > EG > something either not recognizably intended for one, or not
> > > > EG > from a source that one recognizes?  From a security point
> > > > EG > of view, we cannot require an implementation to reply to
> > > > EG > the requester in this case (this is an attack vector for
> > > > EG > all kinds of hate and discontent).  Nor can we forbid it.
> > > >
> > > > Using the per-interface model and say the DSMAP TLV did not match the
> > > > ingress IF identifier, then should this request frame be dropped?
> > > > Should we reply to the requestor? Can this way two answers be
> > > > generated?
> > > >
> > > > Nit (section 2.1): s/mpls/MPLS/
> > > >
> > > > EG > Thanks.
> > > >
> > > >
> > > > Best,
> > > >
> > > >
> > > >
> > > > Rolf
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > > > London W3 6BL | Registered in England 2832014
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > > Of
> > > > > Loa Andersson
> > > > > Sent: Donnerstag, 16. Juni 2011 22:01
> > > > > To: [e-mail]; [e-mail];
> > > > Ross
> > > > > Callon; George Swallow; MPLS-TP ad hoc team
> > > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > cv
> > > > >
> > > > > Working Group.
> > > > >
> > > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
> > > > > after wg last call and published version -04 of the document.
> > > > >
> > > > > A document detailing how the comments have been addressed will be
> > > > > found at:
> > > > > http://www.pi.nu/~loa/comments-on-03.xls
> > > > >
> > > > > This is to start a working group call to verify that all comments
> > > > > been adequately addressed. Please send your comments to the
> > > > > mpls working group mailing list before June 24th.
> > > > >
> > > > > Loa
> > > > > on behalf of the MPLS wg co-chairs
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > Loa Andersson                         email:
> > > > [e-mail]
> > > > > Sr Strategy and Standards Manager            [e-mail]
> > > > > Ericsson Inc                          phone: [phone]
> > > > >                                               [phone]
> > > > > _______________________________________________
> > > > > mpls mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/mpls
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls